From msec-admin@securemulticast.org Wed Jun 4 10:47:25 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24355 for ; Wed, 4 Jun 2003 10:47:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4CA1253A29; Wed, 4 Jun 2003 10:46:45 -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 BA911537DE for ; Wed, 4 Jun 2003 10:44:21 -0400 (EDT) Received: (qmail 26980 invoked by uid 3269); 4 Jun 2003 14:44:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26977 invoked from network); 4 Jun 2003 14:44:21 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.al.sw.ericsson.se) (193.180.251.47) by klesh.pair.com with SMTP; 4 Jun 2003 14:44:21 -0000 Received: from esealnt610.al.sw.ericsson.se (alteon-nat3.sw.ericsson.se [153.88.254.120]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6a) with ESMTP id h54EiKT3008671 for ; Wed, 4 Jun 2003 16:44:20 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 4 Jun 2003 16:45:19 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D062EF65A@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (EAB)" To: "'msec@securemulticast.org'" Cc: "Fredrik Lindholm (EAB)" , "Karl Norrman (EAB)" , =?iso-8859-1?Q?Mats_N=E4slund_=28EAB=29?= , "Jari Arkko (LMF)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] DH mode in 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, 4 Jun 2003 16:28:46 +0200 Hi, MIKEY has been through AD review (by Russ). One question that was brought up was whether the DH key exchange was needed or not. We decided that such discussion should be brought to the list. Below is a very brief summary of the discussion so far. To avoid a too lengthly discussions, Ran and Thomas will issue a deadline for it. A summary of motivations for keeping the DH mode: - it is the only mode giving PFS. - Unlike RSA (and essentially all public key methods) DH can be instantiated VERY efficiently by selecting an appropriate group, e.g. elliptic curves. - There has been explicit interest for this mode (). - While MIKEY was designed to be useful in small groups, many use cases for DH will only be simple person-to-person calls (where DH indeed applies). Summary of the questioning of the DH mode: - Does it make sense to have yet-another DH based exchange in the IETF, and what added value does this protocol have over existing ones, e.g. IKE, TLS, SSH? - Without the DH mode, there will be a more unified model of the key establishment (which would be very helpful for the understanding of the protocol). - Does it make sense to have a two round, timestamp-based DH, rather than a 3 round nonce-based one (the benefits and the need for timestamps in the DH case are not as strong as in the other modes)? The authors recommendation has been to keep the DH mode, but - better clarify the difference between the DH mode and the other modes in the document - make the DH mode optional to implement. We would like to hear the opinion of the people in msec. Thanks, cheers /the authors _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 12 19:19:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01158 for ; Thu, 12 Jun 2003 19:19:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A6740535A2; Thu, 12 Jun 2003 19:15: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 3083353579 for ; Thu, 12 Jun 2003 19:13:51 -0400 (EDT) Received: (qmail 54356 invoked by uid 3269); 12 Jun 2003 23:13:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 54348 invoked from network); 12 Jun 2003 23:13:50 -0000 Received: from falcon.ericsson.se (HELO falcon.al.sw.ericsson.se) (193.180.251.52) by klesh.pair.com with SMTP; 12 Jun 2003 23:13:50 -0000 Received: from esealnt612.al.sw.ericsson.se (alteon-nat1.sw.ericsson.se [153.88.254.118]) by falcon.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5CNEZcv021293; Fri, 13 Jun 2003 01:14:35 +0200 Received: from researchypsmgn (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id LYGK4RGB; Fri, 13 Jun 2003 01:13:38 +0200 Message-ID: <001601c33137$d68468f0$ea233d0a@w2k.er.ki.sw.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Fredrik Lindholm" To: , , "canetti" Subject: Fw: [MSEC] DH mode in MIKEY 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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, 13 Jun 2003 01:10:36 +0200 Content-Transfer-Encoding: 7bit FYI (mail from Martin Euchner), Ran, Thomas, it seems like there are mails that do not turn up in the msec mail archives. I have received one mail from Martin and one mail from Mark which does not appear in the archives, though they are addressed to the group. Cheers, Fredrik ----- Original Message ----- From: "Euchner Martin" To: "'Elisabetta Carrara (EAB)'" ; ; "Euchner Martin" Cc: "Fredrik Lindholm (EAB)" ; "Karl Norrman (EAB)" ; "Mats Naslund (EAB)" ; "Jari Arkko (LMF)" Sent: Thursday, June 12, 2003 10:08 AM Subject: RE: [MSEC] DH mode in MIKEY > Dear all, > It is true that MIKEY features 3 key management protocol variants (key distribution with symmetric shared secrets, signed key distribution with RSA, and signed key agreement with the DH protocol). > > In the following I want to provide good arguments (also in support of the editor) why I believe the DH protocols are necessary for MIKEY and thus to keep DH within MIKEY. > > 1. DH provides an important security property "perfect forward secrecy" (PFS). None of the other MIKEY protocols is able to provide this security property and thus none of the other MIKEY protocols is able to substitute the DH-PFS property in that regard. > > > 2. It is exactly this crucial and nice PFS property of DH that made the DH protocol a core key management function in various other key management protocols including IKE (v1, v2), TLS, SecSH and many, many more. > > 3. DH protocol is a generic technique not only applicable to groups of prime or of characteristic 2. This is because of the fundamental mathematical assumption that the discrete logarithm problem is also a very hard one in general groups. This enables DH to be deployed also for GF(p)*, sub groups and for groups upon elliptic curves. RSA does not allow such generalization as the core mathematical problem is a different one (large integer factorization). > > 4. While RSA asymmetric keys tend to become increasingly lengthy (1536 bit and higher) and thus very computational intensive. Elliptic-curve DH (ECDH) allows to cut-down key lengths substantially (say 170 bit and higher) while maintaining at least the security level and providing even significant performance benefits in practice. Moreover, it is believed that elliptic curve techniques provide much better protection against side channel attacks due to the inherent redundancy in the projective coordinates. For all this, one may view elliptic-curve-based DH as being more "future-proof" than RSA. > > 5. Due to the fact the both entities (sender and receiver) contribute to the generation of the DH key, malicious cheating or using weak random generators of either side may be leveraged. One may view this as an additional distributed security measure increasing security robustness over the case where all the security depends just on the proper implementation of a single entity. > > 6. DH has proven feasible in praxis over many years and in many cases. MIKEY should thus inherit the security properties of DH such as PFS but also other beneficial properties of DH; e.g., like implementation ease. > > 7. The MIKEY key management protocol suite is optimized for the purpose of multimedia applications with real-time constraints. In particular, all MIKEY key management protocols terminate in at most one round-trip; making MIKEY perfectly suitable for integration into the two-way signaling handshake of SIP/SDP offer/answer or H.245 fast start. > > 8. MIKEY is able not only to agree or deliver new key material with this handshake, but also to negotiate a security policy with security capabilities and crypto algorithms as part of this handshake. No other key management protocol (IKE, TLS, SecSH) is able to accomplish this task in at most a single round trip. No wonder, none of those key management protocols for "data applications" ever had any real-time requirements in their design, why should they fulfil it? Therefore, IPSEC, TLS, or other lengthy key management protocols just cannot meet the specific time constraints of a multimedia key management protocol for real-time MM applications. > > 9. MIKEY is a rather generic MM-key management protocol with many potential applications. Let me report in my capacity as Q.G/16 Rapporteur, that ITU-T SG16 has figured out a use case (or call it applicability profile of MIKEY) in the H.323-multimedia environment; this is described within draft H.235 Annex G " Usage of the Secure Real Time Transport Protocol (SRTP) in conjunction with the MIKEY Key Management Protocol within H.235". This fairly stable draft specifies several deployments of MIKEY key management protocols including also DH-SIGN and DH-HMAC. For this reason, the MIKEY DH variants do have true applicability statements and this should underline the need of DH in MIKEY. > > 10. Perhaps it should be better clarified in the MIKEY ID, that MIKEY is not supposed to be yet another alternative to general key management protocols. Rather, MIKEY is applicable just for the purpose of a multimedia applications with according key management needs. > > 11. The question of timestamps and quasi synchronized time came up a couple of times in the discussion. While it may be difficult to argue about the general, abstract case, at least in H.235 Annex G enabled environments, the constraint of timestamps does not put a big burden; similar thoughts might hold for SIP too. > > 12. Avoiding timestamps in key management protocols and using nonces etc. would immediately add another half-round trip at least and thereby would break the "at-most one roundtrip" constraint given by the MM applications like SIP or H.323. However, in practice usage of time servers is not that out-of scope, as it might appear at first sight. Many environments have already such time servers available and thus such facilities could be used too. > > 13. It is true that DH as MIKEY defines it, is just applicable for a group of size 2 (i.e., plain P2P communication). There is no straight-forward generalization known that naturally extends DH key-agreement to true groups with several members that would fit into the basic MIKEY handshake protocol flow. Still, although DH is poor in terms of group-support, the simple, degenerated 2-entity group still plays a major and important role in practice. > > 14. Recognizing that DH plays a special role within MIKEY (in particular in terms of group-support), one may in fact consider making the DH variants of MIKEY an option. This may assist to describe more easily a unified group-key management approach of MIKEY. > > > As a conclusion, I should say that I see clear value-add in having the MIKEY-DH variants around. > > > With kind regards > > Martin Euchner. > ----------------------------------------------------------------------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > ----------------------------------------------------------------------- > > -----Original Message----- > From: Elisabetta Carrara (EAB) [mailto:Elisabetta.Carrara@era.ericsson.se] > Sent: Wednesday, June 04, 2003 4:29 PM > To: 'msec@securemulticast.org' > Cc: Fredrik Lindholm (EAB); Karl Norrman (EAB); Mats Naslund (EAB); Jari Arkko (LMF) > Subject: [MSEC] DH mode in MIKEY > > Hi, > > MIKEY has been through AD review (by Russ). One question > that was brought up was whether the DH key exchange was > needed or not. We decided that such discussion should be > brought to the list. > > Below is a very brief summary of the discussion so far. > To avoid a too lengthly discussions, Ran and Thomas will > issue a deadline for it. > > A summary of motivations for keeping the DH mode: > - it is the only mode giving PFS. > - Unlike RSA (and essentially all public key methods) DH > can be instantiated VERY efficiently by selecting an > appropriate group, e.g. elliptic curves. > - There has been explicit interest for this mode > (). > - While MIKEY was designed to be useful in small groups, > many use cases for DH will only be simple person-to-person > calls (where DH indeed applies). > > Summary of the questioning of the DH mode: > - Does it make sense to have yet-another DH based exchange > in the IETF, and what added value does this protocol > have over existing ones, e.g. IKE, TLS, SSH? > - Without the DH mode, there will be a more unified model > of the key establishment (which would be very helpful for > the understanding of the protocol). > - Does it make sense to have a two round, timestamp-based > DH, rather than a 3 round nonce-based one (the benefits > and the need for timestamps in the DH case are not as > strong as in the other modes)? > > The authors recommendation has been to keep the DH mode, but > - better clarify the difference between the DH mode and the other > modes in the document > - make the DH mode optional to implement. > > We would like to hear the opinion of the people in msec. > > Thanks, > cheers > > /the authors > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 12 19:23:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01224 for ; Thu, 12 Jun 2003 19:23:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 45C1453579; Thu, 12 Jun 2003 19:22: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 E0F0153579 for ; Thu, 12 Jun 2003 19:20:44 -0400 (EDT) Received: (qmail 55189 invoked by uid 3269); 12 Jun 2003 23:20:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55186 invoked from network); 12 Jun 2003 23:20:44 -0000 Received: from penguin-ext.wise.edt.ericsson.se (HELO penguin.al.sw.ericsson.se) (193.180.251.47) by klesh.pair.com with SMTP; 12 Jun 2003 23:20:44 -0000 Received: from esealnt613.al.sw.ericsson.se (alteon-nat8.sw.ericsson.se [153.88.254.125]) by penguin.al.sw.ericsson.se (8.12.9/8.12.9/WIREfire-1.6b) with ESMTP id h5CNKew2022811; Fri, 13 Jun 2003 01:20:40 +0200 (MEST) Received: from researchypsmgn (permit153.er.ki.sw.ericsson.se [147.214.97.153]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id MVP7ZPHB; Fri, 13 Jun 2003 01:20:42 +0200 Message-ID: <001d01c33138$cbedba30$ea233d0a@w2k.er.ki.sw.ericsson.se> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: "Fredrik Lindholm" To: "Mark Baugher" Cc: References: <5.1.1.5.2.20030611221210.05e10998@mira-sjc5-6.cisco.com> 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 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [MSEC] Re: "split" parameter for FEC order in 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: Fri, 13 Jun 2003 01:17:29 +0200 Content-Transfer-Encoding: 7bit Hi Mark, as this was taken from one of the previous versions of SRTP, I hoped you could have explained that to me ;-) I will look into this when I'm back at office, and maybe update this to match with the latest version of SRTP. Thanks for pointing it out. Fredrik ----- Original Message ----- From: "Mark Baugher" To: Cc: Sent: Thursday, June 12, 2003 7:16 AM Subject: "split" parameter for FEC order in MIKEY > Hello Fredrik > Would you or one of the other MIKEY authors explain to me what "split" > means for fec order on p. 36 of > http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.txt. I don't > understand why we would encrypt, compute the fec stream packet, and then > authenticate the original packet. I assume that this scheme works with > http://www.ietf.org/rfc/rfc2733.txt. > > thanks, Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 13 05:17:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26109 for ; Fri, 13 Jun 2003 05:17:21 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 586F853B4E; Fri, 13 Jun 2003 05:16: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 B718C53B52 for ; Fri, 13 Jun 2003 05:14:43 -0400 (EDT) Received: (qmail 78776 invoked by uid 3269); 13 Jun 2003 09:14:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78773 invoked from network); 13 Jun 2003 09:14:43 -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; 13 Jun 2003 09:14:43 -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.6b) with ESMTP id h5D9EZG5008977; Fri, 13 Jun 2003 11:14:35 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Fri, 13 Jun 2003 11:16:08 +0200 Message-ID: <4E85E49D1F0CBF4F96EA08E335750D7D062EF6E0@Esealnt877.al.sw.ericsson.se> From: "Elisabetta Carrara (EAB)" To: "Fredrik Lindholm (EAB)" , Mark Baugher Cc: msec@securemulticast.org Subject: RE: [MSEC] Re: "split" parameter for FEC order in 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, 13 Jun 2003 11:14:45 +0200 Hi yes, the "split" value in the FEC order is from a previous version (I think v3) of SRTP. And it is correct that the RFC for FEC is 2733. In that version of SRTP, we had a longer section on the FEC interaction than in the current version. The old text, if I remember correctly, said that the split (i.e., encr-fec-auth, at sender side) would be the optimal order, however we did not choose it as default in SRTP for the complications due to the splitting of the security processing. That old text was reflection of a discussion we had at that time on the avt mailing list, you can find it in the archive. In the current version of SRTP, we only define the default order, and say that any other order has to be signalled (by key mgnt). So, MIKEY should carry the values for the signalling. The only risk to have it there is that maybe the processing has to be defined (we did not look at it, so we don't know). But we keep this in mind for the next revision of MIKEY. Cheers /E > -----Original Message----- > From: Fredrik Lindholm (EAB) > Sent: den 13 juni 2003 01:17 > To: Mark Baugher > Cc: msec@securemulticast.org > Subject: [MSEC] Re: "split" parameter for FEC order in MIKEY > > > > Hi Mark, > > as this was taken from one of the previous versions of SRTP, > I hoped you > could have explained that to me ;-) I will look into this > when I'm back > at office, and maybe update this to match with the latest > version of SRTP. > Thanks for pointing it out. > > Fredrik > > > ----- Original Message ----- > From: "Mark Baugher" > To: > Cc: > Sent: Thursday, June 12, 2003 7:16 AM > Subject: "split" parameter for FEC order in MIKEY > > > > Hello Fredrik > > Would you or one of the other MIKEY authors explain to > me what "split" > > means for fec order on p. 36 of > > > http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-06.t xt. I don't > understand why we would encrypt, compute the fec stream packet, and then > authenticate the original packet. I assume that this scheme works with > http://www.ietf.org/rfc/rfc2733.txt. > > thanks, Mark > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 16 16:46:46 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01670 for ; Mon, 16 Jun 2003 16:46:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2290E5389C; Mon, 16 Jun 2003 16:45: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 9BC635355A for ; Mon, 16 Jun 2003 12:42:02 -0400 (EDT) Received: (qmail 81666 invoked by uid 3269); 16 Jun 2003 16:42:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81663 invoked from network); 16 Jun 2003 16:42:02 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 16 Jun 2003 16:42:02 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5GGg1h6002958; Mon, 16 Jun 2003 09:42:01 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (THARDJONO-LAP [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL9YARC; Mon, 16 Jun 2003 09:42:01 -0700 Message-Id: <5.2.1.1.2.20030616093852.022a4048@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Call for MSEC agenda items for IETF-57 Vienna 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, 16 Jun 2003 09:41:55 -0700 Folks, In the upcoming IETF-57, MSEC is going to meet tentatively on Monday evening (July 14) from 19:30pm to 22:00pm. Please send proposals for agenda items to Ran and myself. Best, Ran/Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 17 15:14:46 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05098 for ; Tue, 17 Jun 2003 15:14:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0A58753999; Tue, 17 Jun 2003 15:13: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 23F5553903 for ; Tue, 17 Jun 2003 15:10:56 -0400 (EDT) Received: (qmail 35802 invoked by uid 3269); 17 Jun 2003 19:10:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35799 invoked from network); 17 Jun 2003 19:10:56 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 17 Jun 2003 19:10:56 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5HJAS1121154 for ; Tue, 17 Jun 2003 15:10:28 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5HJAtj146690 for ; Tue, 17 Jun 2003 15:10:55 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) id PAA25496 for msec@securemulticast.org; Tue, 17 Jun 2003 15:10:54 -0400 From: Ran Canetti Message-Id: <200306171910.PAA25496@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: Re: [MSEC] DH mode in 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: Tue, 17 Jun 2003 15:10:54 -0400 Elizabetta, Martin, and all, [Cochair hat off] TO add some pepper to the discussion, let me present the following points questioning the utility of the DH mode in MIKEY. (The points cam up in several discussions between the authors, the chairs of msec and mmusic, and the respective ad's. Any thoughts are most welcome. All the other modes in MIKEY involve a single "downstream" message. This is great advantage, and in particular it mitigates the added complexity (and additional security threats) involved in using timestamps. The DH mode ddoes not enjoy these advantages, since it requires an upstream message. Thus the following questions arise: (a) If we're already having an upstream message, then why not have a three-message protocol that is based on nonces rather than timestamps? (nonces are easier to deal with, and they are not susceptible to "clock rewinding attacks"). (b) If we're already having a nonce-based DH exchange, then why not use an off-the-shelf protocol such as TLS/SSH/IKE etc., rather than doing things from scratch? (for instance, if we use IKEv2, we get a four message exchange that is already protectign against DOS, is relatively well analyzed, etc.) (c) MIKEY is directed at media and multimedia straming. Is PFS an important concern for such scenarios? is it worth the extra complexity? [Cchair hat on] We need to get to closure on this issue, in order to move forward with the mikey draft. So lets put a cap of a week on the dicsussion and try to reach closure by June 24th. Ran > > MIKEY has been through AD review (by Russ). One question > that was brought up was whether the DH key exchange was > needed or not. We decided that such discussion should be > brought to the list. > > Below is a very brief summary of the discussion so far. > To avoid a too lengthly discussions, Ran and Thomas will > issue a deadline for it. > > A summary of motivations for keeping the DH mode: > - it is the only mode giving PFS. > - Unlike RSA (and essentially all public key methods) DH > can be instantiated VERY efficiently by selecting an > appropriate group, e.g. elliptic curves. > - There has been explicit interest for this mode > (<draft-ietf-msec-mikey-dhhmac-01.txt>). > - While MIKEY was designed to be useful in small groups, > many use cases for DH will only be simple person-to-person > calls (where DH indeed applies). > > Summary of the questioning of the DH mode: > - Does it make sense to have yet-another DH based exchange > in the IETF, and what added value does this protocol > have over existing ones, e.g. IKE, TLS, SSH? > - Without the DH mode, there will be a more unified model > of the key establishment (which would be very helpful for > the understanding of the protocol). > - Does it make sense to have a two round, timestamp-based > DH, rather than a 3 round nonce-based one (the benefits > and the need for timestamps in the DH case are not as > strong as in the other modes)? > > The authors recommendation has been to keep the DH mode, but > - better clarify the difference between the DH mode and the other > modes in the document > - make the DH mode optional to implement. > > We would like to hear the opinion of the people in msec. > > Thanks, > cheers > > /the authors > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 09:44:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06725 for ; Wed, 18 Jun 2003 09:44:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D287539D3; Wed, 18 Jun 2003 09:43:48 -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 A5F0653579 for ; Wed, 18 Jun 2003 09:33:27 -0400 (EDT) Received: (qmail 73995 invoked by uid 3269); 18 Jun 2003 13:33:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73977 invoked from network); 18 Jun 2003 13:33:27 -0000 Received: from david.siemens.de (192.35.17.14) by klesh.pair.com with SMTP; 18 Jun 2003 13:33:27 -0000 Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by david.siemens.de (8.11.7/8.11.7) with ESMTP id h5IDXO929313; Wed, 18 Jun 2003 15:33:24 +0200 (MEST) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail2.siemens.de (8.11.7/8.11.7) with ESMTP id h5IDXOH07943; Wed, 18 Jun 2003 15:33:24 +0200 (MEST) Received: from mail-k.mchp.siemens.de (mail-k.mchp.siemens.de [139.23.202.237]) by mars.cert.siemens.de (8.12.9/8.12.9/$SiemensCERT: mail/cert.mc,v 1.46 2003/05/28 09:28:32 ust Exp $) with ESMTP id h5IDXNLH070709; Wed, 18 Jun 2003 15:33:23 +0200 (CEST) Received: from mhpaba5c (mhpaba5c [139.23.204.46]) by mail-k.mchp.siemens.de with ESMTP id h5IDXNfl010920; Wed, 18 Jun 2003 15:33:23 +0200 (MEST) From: "Steffen Fries" Organization: Siemens AG To: msec@securemulticast.org, Ran Canetti MIME-Version: 1.0 Subject: Re: [MSEC] DH mode in MIKEY Reply-To: steffen.fries@siemens.com Message-ID: <3EF0874C.18143.1987F7FA@localhost> Priority: normal In-reply-to: <200306171910.PAA25496@ornavella.watson.ibm.com> X-mailer: Pegasus Mail for Windows (v4.11) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 18 Jun 2003 15:37:48 +0200 Content-Transfer-Encoding: 7BIT Hi Ran, I made some inline comments. (a)If we're already having an upstream message, then why not have a > three-message protocol that is based on nonces rather than timestamps? > (nonces are easier to deal with, and they are not susceptible to > "clock rewinding attacks"). In multimedia sytems there are protocols used that just feature a two message exchange between the sender and the receiver. Here MIKEY can be applied. One example is the usage of Fast Start in H.323. Here only the SETUP message and the appropriate response message are sent. A three way protocol would add an extra message to Fast Start, which is not desired. Furthermore, MIKEY has already been considered by the ITU-T for usage in H.323 in combination with SRTP in Draft H.235 Annex G. Again, in multimedia environments MIKEY is intended to be incorporated into (existing) VoIP protocols using only a full handshake rather than be used standalone. Moreover, DH is useful in this case to have e.g. PFS (see also point c below). (b) If we're already having a nonce-based > DH exchange, then why not use an off-the-shelf protocol such as > TLS/SSH/IKE etc., rather than doing things from scratch? (for > instance, if we use IKEv2, we get a four message exchange that is > already protectign against DOS, is relatively well analyzed, etc.) MIKEY is defined in a way that it may be integrated into existing protocols as a key management container. This is for instance the case for SIP and H.323. Because of the few messages needed by MIKEY for key management and security policy negotiation it integrates nicely in protocols only using a full handshake to establish a session between two parties. Other key management approaches like the ones you mentioned require more messages to be exchanged. (c) > MIKEY is directed at media and multimedia straming. Is PFS an > important concern for such scenarios? is it worth the extra > complexity? MIKEY may be used in VoIP environments to provide means for media data protection. PFS may not be necessary in every case but PFS is a security property, which cannot be achieved in any other way. If this is worth the extra effort may be a scenario specific question. Nvertheless, PFS provides additional security, with the ensurance that the security may not be compromised in a backwards way. You might compare this additional security functionality with somebody who encrypts files on his PC despite the fact that the PC is protected against unauthorized access. Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 19:17:55 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05675 for ; Wed, 18 Jun 2003 19:17:54 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2876D536D1; Wed, 18 Jun 2003 19:17:23 -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 7E5DD5359C for ; Wed, 18 Jun 2003 19:13:27 -0400 (EDT) Received: (qmail 59976 invoked by uid 3269); 18 Jun 2003 23:13:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59973 invoked from network); 18 Jun 2003 23:13:27 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Jun 2003 23:13:27 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5INDPh6026814; Wed, 18 Jun 2003 16:13:25 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.25.161.20 [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL982M6; Wed, 18 Jun 2003 16:13:25 -0700 Message-Id: <5.2.1.1.2.20030618154949.02570658@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Starting Last Call for MSEC Architecture draft 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, 18 Jun 2003 16:13:19 -0700 Seeing that no further significant discussion on the MSEC Architecture draft has occurred on the mailing-list, its about time to do a Last Call for this draft (aimed for Standards Track). http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-01.txt The contents of this draft have been drawn from various documents in both SMuG and MSEC during the last few years, and thus its contents is relatively stable and known to many. This is one of the three architecture-level documents that the MSEC WG set out to deliver. I would like to invite people to do a final review of the draft, and send comments to the mailing list. Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 19:20:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05726 for ; Wed, 18 Jun 2003 19:20:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9899853702; Wed, 18 Jun 2003 19:19:46 -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 9C9D75359C for ; Wed, 18 Jun 2003 19:17:07 -0400 (EDT) Received: (qmail 60466 invoked by uid 3269); 18 Jun 2003 23:17:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 60463 invoked from network); 18 Jun 2003 23:17:07 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Jun 2003 23:17:07 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5INH6h6027375; Wed, 18 Jun 2003 16:17:06 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.25.161.20 [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL982SV; Wed, 18 Jun 2003 16:17:05 -0700 Message-Id: <5.2.1.1.2.20030618161518.02483d80@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Starting Last Call for GSAKMP-Classic draft for Experimental RFC 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, 18 Jun 2003 16:16:59 -0700 [I'm re-sending this as it did not make it to the mailing-list. TH.] Folks, One of the WG actions items from the last IETF56 meeting in San Francisco was to advance the GSAKMP-Classic draft to Experimental RFC (as suggested by Russ). Thus, I'd like to begin the Last Call for GSAKMP-Classic. If there are outstanding issues, please bring them up on the mailing-list. It would be good if we could finalize this WG item at the next IETF. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 19:48:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06758 for ; Wed, 18 Jun 2003 19:48:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D456053757; Wed, 18 Jun 2003 19:43:22 -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 A971B5360E for ; Wed, 18 Jun 2003 19:37:02 -0400 (EDT) Received: (qmail 63190 invoked by uid 3269); 18 Jun 2003 23:37:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63187 invoked from network); 18 Jun 2003 23:37:02 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Jun 2003 23:37:02 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5INb1h6000339 for ; Wed, 18 Jun 2003 16:37:01 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.25.161.20 [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL98JMD; Wed, 18 Jun 2003 16:37:01 -0700 Message-Id: <5.2.1.1.2.20030618163610.022abcb8@vhqpostal3.verisign.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-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, 18 Jun 2003 16:36:51 -0700 [I'm re-sending this as it did not make it to the mailing-list. TH.] >Subject: I-D ACTION:draft-duquer-fmke-00.txt >Date: Wed, 18 Jun 2003 07:52:40 -0400 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-00.txt > Pages : 30 > Date : 2003-6-17 > >This document presents a new group key management protocol called >FMKE (Flat Multicast Key Exchange). Its objective is to manage >securely group Security Associations (SA), i.e. establish and update >SAs in Group members. These members can be identified for instance >by a multicast IP address, a virtual LAN identifier, or a generic >group label. This protocol is based on a centralized management, >achieved by the GCKS (Group Controller and Key Server). It is >destined to be used by Data Security protocols which wish to secure >group communications. For the time being, the considered Data >Security protocol is a multicast version of the IPSEC ESP protocol, >but other Data Security protocols could be envisaged. The FMKE >protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key >Encryption Keys). The FMKE protocol is optimized for very large >groups with direct connections such as satellite systems, or wireless >systems such as WIFI. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 20:23:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08329 for ; Wed, 18 Jun 2003 20:23:49 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8128C539E8; Wed, 18 Jun 2003 20:21: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 A9C7F535B0 for ; Wed, 18 Jun 2003 13:08:21 -0400 (EDT) Received: (qmail 7371 invoked by uid 3269); 18 Jun 2003 17:08:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7366 invoked from network); 18 Jun 2003 17:08:21 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Jun 2003 17:08:21 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5IH8Kh6003332 for ; Wed, 18 Jun 2003 10:08:20 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.25.161.20 [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL97RH5; Wed, 18 Jun 2003 10:08:20 -0700 Message-Id: <5.2.1.1.2.20030618095706.022a4cd8@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Starting Last Call for GSAKMP-Classic draft for Experimental RFC 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, 18 Jun 2003 10:08:14 -0700 Folks, One of the WG actions items from the last IETF56 meeting in San Francisco was to advance the GSAKMP-Classic draft to Experimental RFC (as suggested by Russ). Thus, I'd like to begin the Last Call for GSAKMP-Classic. If there are outstanding issues, please bring them up on the mailing-list. It would be good if we could finalize this WG item at the next IETF. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 20:32:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08774 for ; Wed, 18 Jun 2003 20:32:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4D5CC53907; Wed, 18 Jun 2003 20:31:48 -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 70D0753656 for ; Wed, 18 Jun 2003 13:33:37 -0400 (EDT) Received: (qmail 10899 invoked by uid 3269); 18 Jun 2003 17:33:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 10896 invoked from network); 18 Jun 2003 17:33:36 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 18 Jun 2003 17:33:36 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5IHXZh6010254 for ; Wed, 18 Jun 2003 10:33:35 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.25.161.20 [10.25.161.20]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL97TD3; Wed, 18 Jun 2003 10:33:35 -0700 Message-Id: <5.2.1.1.2.20030618103238.022a4b90@vhqpostal3.verisign.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-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, 18 Jun 2003 10:33:29 -0700 >Subject: I-D ACTION:draft-duquer-fmke-00.txt >Date: Wed, 18 Jun 2003 07:52:40 -0400 >From: Internet-Drafts@ietf.org >Reply-To: Internet-Drafts@ietf.org >To: IETF-Announce: ; > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-00.txt > Pages : 30 > Date : 2003-6-17 > >This document presents a new group key management protocol called >FMKE (Flat Multicast Key Exchange). Its objective is to manage >securely group Security Associations (SA), i.e. establish and update >SAs in Group members. These members can be identified for instance >by a multicast IP address, a virtual LAN identifier, or a generic >group label. This protocol is based on a centralized management, >achieved by the GCKS (Group Controller and Key Server). It is >destined to be used by Data Security protocols which wish to secure >group communications. For the time being, the considered Data >Security protocol is a multicast version of the IPSEC ESP protocol, >but other Data Security protocols could be envisaged. The FMKE >protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key >Encryption Keys). The FMKE protocol is optimized for very large >groups with direct connections such as satellite systems, or wireless >systems such as WIFI. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 20:34:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08830 for ; Wed, 18 Jun 2003 20:34:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0A6C35366B; Wed, 18 Jun 2003 20:33: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 06E68535C9 for ; Wed, 18 Jun 2003 20:31:16 -0400 (EDT) Received: (qmail 69859 invoked by uid 3269); 19 Jun 2003 00:31:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69853 invoked from network); 19 Jun 2003 00:31:15 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 19 Jun 2003 00:31:15 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5J0VAm24658; Wed, 18 Jun 2003 17:31:10 -0700 (PDT) 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 NALGVXJ9; Wed, 18 Jun 2003 17:31:10 -0700 Received: from nortelnetworks.com (artpt5rd.us.nortel.com [47.140.52.164]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MGTS33LL; Wed, 18 Jun 2003 20:31:07 -0400 Message-ID: <3EF10413.5000907@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: Thomas Hardjono Cc: msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com Subject: Re: [MSEC] Starting Last Call for MSEC Architecture draft References: <5.2.1.1.2.20030618154949.02570658@pop.mail.yahoo.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, 18 Jun 2003 20:30:11 -0400 Content-Transfer-Encoding: 7bit I think this should be informational. Thomas said that that was his intent as well. regards, Lakshminath Thomas Hardjono wrote: > > Seeing that no further significant discussion on the MSEC Architecture > draft has occurred on the mailing-list, its about time to do a Last Call > for this draft (aimed for Standards Track). > > http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-01.txt > > The contents of this draft have been drawn from various documents in > both SMuG and MSEC during the last few years, and thus its contents is > relatively stable and known to many. > > This is one of the three architecture-level documents that the MSEC WG > set out to deliver. > > I would like to invite people to do a final review of the draft, and > send comments to the mailing list. > > > Thomas/Ran > ---------- > > > > _______________________________________________ > 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 Jun 18 21:18:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10271 for ; Wed, 18 Jun 2003 21:18:53 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8175253728; Wed, 18 Jun 2003 21:17:48 -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 CC5C353776 for ; Wed, 18 Jun 2003 14:12:47 -0400 (EDT) Received: (qmail 17543 invoked by uid 3269); 18 Jun 2003 18:12:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 17540 invoked from network); 18 Jun 2003 18:12:47 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 18 Jun 2003 18:12:47 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5IICjX17731 for ; Wed, 18 Jun 2003 14:12:45 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAFSJW95; Wed, 18 Jun 2003 14:12:44 -0400 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 MGTS3NZ8; Wed, 18 Jun 2003 14:12:44 -0400 Message-ID: <3EF0AB6A.8030607@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: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-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, 18 Jun 2003 14:11:54 -0400 Content-Transfer-Encoding: 7bit Hi all, I forwarded this new I-D announcement from IETF-Announce to a small group of MSEC regulars and no one was aware of it. Assuming that others haven't seen it either, here it is on Thomas's request. Could the authors (if they see this) please send their email addresses to the group (not in I-D)? I have some questions on the I-D. Thanks. regards, Lakshminath -------- Original Message -------- Subject: I-D ACTION:draft-duquer-fmke-00.txt Date: Wed, 18 Jun 2003 07:52:40 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Flat Multicast Key Exchange protocol Author(s) : L. Duquerroy, S. Josset Filename : draft-duquer-fmke-00.txt Pages : 30 Date : 2003-6-17 This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange). Its objective is to manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These members can be identified for instance by a multicast IP address, a virtual LAN identifier, or a generic group label. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols which wish to secure group communications. For the time being, the considered Data Security protocol is a multicast version of the IPSEC ESP protocol, but other Data Security protocols could be envisaged. The FMKE protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key Encryption Keys). The FMKE protocol is optimized for very large groups with direct connections such as satellite systems, or wireless systems such as WIFI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 18 22:14:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11600 for ; Wed, 18 Jun 2003 22:14:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 81B9C539ED; Wed, 18 Jun 2003 22:13:04 -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 DF9CA539A3 for ; Wed, 18 Jun 2003 22:11:36 -0400 (EDT) Received: (qmail 90366 invoked by uid 3269); 19 Jun 2003 02:11:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90363 invoked from network); 19 Jun 2003 02:11:36 -0000 Received: from smtp018.mail.yahoo.com (216.136.174.115) by klesh.pair.com with SMTP; 19 Jun 2003 02:11:36 -0000 Received: from dialup-67.30.96.162.dial1.sanjose1.level3.net (HELO THARDJONO-LAP.yahoo.com) (thardjono@67.30.96.162 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 19 Jun 2003 02:11:35 -0000 Message-Id: <5.2.1.1.2.20030618191016.022a5e60@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: Lakshminath Dondeti , Thomas Hardjono From: Thomas Hardjono Subject: Re: [MSEC] Starting Last Call for MSEC Architecture draft Cc: msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com In-Reply-To: <3EF10413.5000907@nortelnetworks.com> References: <5.2.1.1.2.20030618154949.02570658@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: Wed, 18 Jun 2003 19:11:31 -0700 Thanks for the correction, Lakshminath: yes, I meant Informational RFC. Apologies all for the confusion. thomas ------ At 6/18/2003||08:30 PM, Lakshminath Dondeti wrote: >I think this should be informational. Thomas said that that was his >intent as well. > >regards, >Lakshminath > >Thomas Hardjono wrote: >>Seeing that no further significant discussion on the MSEC Architecture >>draft has occurred on the mailing-list, its about time to do a Last Call >>for this draft (aimed for Standards Track). >>http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-01.txt >>The contents of this draft have been drawn from various documents in both >>SMuG and MSEC during the last few years, and thus its contents is >>relatively stable and known to many. >>This is one of the three architecture-level documents that the MSEC WG >>set out to deliver. >>I would like to invite people to do a final review of the draft, and send >>comments to the mailing list. >> >>Thomas/Ran >>---------- >> >>_______________________________________________ >>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 19 04:28:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA04872 for ; Thu, 19 Jun 2003 04:28:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6CD65537EA; Thu, 19 Jun 2003 04:28: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 AF7FE537D8 for ; Thu, 19 Jun 2003 04:26:08 -0400 (EDT) Received: (qmail 80358 invoked by uid 3269); 19 Jun 2003 08:26:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80355 invoked from network); 19 Jun 2003 08:26:08 -0000 Received: from na5.alcatel.fr (HELO smail3.alcatel.fr) (194.133.58.5) by klesh.pair.com with SMTP; 19 Jun 2003 08:26:08 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5J8Q1vi026522 for ; Thu, 19 Jun 2003 10:26:05 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D4A.002E1407 ; Thu, 19 Jun 2003 10:23:17 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: msec@securemulticast.org Cc: Sebastien.Josset@space.alcatel.fr Message-ID: Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=iSQAREGRtCW5mWGBkipQAL6mlFRJ9cc84Ni9lrQftIhLXJvce8j2HFnS" Content-Disposition: inline X-Virus-Scanned: by amavisd-new Subject: [MSEC] =?iso-8859-1?Q?R=E9f._:_[MSEC]_[Fwd:_I-D_ACTION:draft-duquer-fmke?= =?iso-8859-1?Q?-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: Thu, 19 Jun 2003 10:25:06 +0200 --0__=iSQAREGRtCW5mWGBkipQAL6mlFRJ9cc84Ni9lrQftIhLXJvce8j2HFnS Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, In the context of the SatIP6 IST project, Alcatel Space studies a mult= icast security scheme optimised to protect large multicast groups. Such a sch= eme is designed for IP over Satellite, Wifi or DVB systems; it is a security s= olution for the satellite segment. An implementation over DVB-S/RCS is planned = in the SatIP6 demonstrator. We have started to write an Internet Draft detailing our key exchange p= rotocol (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it c= ould be submitted to the MSEC Working Group (In fact, we thought it was too lat= e to submit it for the next IETF meeting.) We would be ready to present it to the next MSEC Working Group meeting = at IETF57 in Vienna. This solution is designed to provide a security solution optimized for = satellite systems. It is defined to be low ressource consuming in bandwidth, to p= rovide a reliable key distribution, to be used in one-to-many and many-to-many s= cenarios, and to be scalable in these scenarios... We hope that you will find interest in it, and thank you in advance for= your comments and questions. Our e-mail addresses are : laurence.duquerroy@space.alcatel.fr sebastien.josset@space.alcatel.fr Best regards, Laurence Duquerroy S=E9bastien Josset Lakshminath Dondeti on 18/06/2003 20:11:5= 4 Pour : msec@securemulticast.org cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] = --0__=iSQAREGRtCW5mWGBkipQAL6mlFRJ9cc84Ni9lrQftIhLXJvce8j2HFnS Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi all, I forwarded this new I-D announcement from IETF-Announce to a small group of MSEC regulars and no one was aware of it. Assuming that others haven't seen it either, here it is on Thomas's request. Could the authors (if they see this) please send their email addresses to the group (not in I-D)? I have some questions on the I-D. Thanks. regards, Lakshminath -------- Original Message -------- Subject: I-D ACTION:draft-duquer-fmke-00.txt Date: Wed, 18 Jun 2003 07:52:40 -0400 From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org To: IETF-Announce: ; A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The Flat Multicast Key Exchange protocol Author(s) : L. Duquerroy, S. Josset Filename : draft-duquer-fmke-00.txt Pages : 30 Date : 2003-6-17 This document presents a new group key management protocol called FMKE (Flat Multicast Key Exchange). Its objective is to manage securely group Security Associations (SA), i.e. establish and update SAs in Group members. These members can be identified for instance by a multicast IP address, a virtual LAN identifier, or a generic group label. This protocol is based on a centralized management, achieved by the GCKS (Group Controller and Key Server). It is destined to be used by Data Security protocols which wish to secure group communications. For the time being, the considered Data Security protocol is a multicast version of the IPSEC ESP protocol, but other Data Security protocols could be envisaged. The FMKE protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key Encryption Keys). The FMKE protocol is optimized for very large groups with direct connections such as satellite systems, or wireless systems such as WIFI. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr --0__=iSQAREGRtCW5mWGBkipQAL6mlFRJ9cc84Ni9lrQftIhLXJvce8j2HFnS-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 19 08:51:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15354 for ; Thu, 19 Jun 2003 08:51:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 219395380F; Thu, 19 Jun 2003 08:50:37 -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 BCB345353E for ; Thu, 19 Jun 2003 08:49:15 -0400 (EDT) Received: (qmail 12387 invoked by uid 3269); 19 Jun 2003 12:49:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12384 invoked from network); 19 Jun 2003 12:49:15 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 19 Jun 2003 12:49:15 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5JCn9Z11680; Thu, 19 Jun 2003 08:49:09 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAFSJ50J; Thu, 19 Jun 2003 08:49:08 -0400 Received: from nortelnetworks.com (artpt5tf.us.nortel.com [47.140.52.232]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MGTS33S5; Thu, 19 Jun 2003 08:49:08 -0400 Message-ID: <3EF1B110.7020005@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: Laurence.Duquerroy@space.alcatel.fr Cc: msec@securemulticast.org, Sebastien.Josset@space.alcatel.fr Subject: Re: [MSEC] =?ISO-8859-1?Q?R=E9f=2E_=3A_=5BMSEC=5D_=5BFwd=3A?= =?ISO-8859-1?Q?_I-D_ACTION=3Adraft-duquer-fmke-00=2Etxt=5D?= References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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, 19 Jun 2003 08:48:16 -0400 Content-Transfer-Encoding: 8bit Hi, Many thanks for your email. I was wondering about the motivation for yet another protocol for group key management. We have too many already. Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-classic, GSAKMP and MIKEY, and the requirements that motivate the need for FMKE? regards, Lakshminath Laurence.Duquerroy@space.alcatel.fr wrote: > > Hi all, > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast > security scheme optimised to protect large multicast groups. Such a scheme is > designed for IP over Satellite, Wifi or DVB systems; it is a security solution > for the satellite segment. An implementation over DVB-S/RCS is planned in the > SatIP6 demonstrator. > > We have started to write an Internet Draft detailing our key exchange protocol > (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it could be > submitted to the MSEC Working Group (In fact, we thought it was too late to > submit it for the next IETF meeting.) > > We would be ready to present it to the next MSEC Working Group meeting at IETF57 > in Vienna. > > This solution is designed to provide a security solution optimized for satellite > systems. It is defined to be low ressource consuming in bandwidth, to provide a > reliable key distribution, to be used in one-to-many and many-to-many scenarios, > and to be scalable in these scenarios... > > We hope that you will find interest in it, and thank you in advance for your > comments and questions. > > Our e-mail addresses are : > laurence.duquerroy@space.alcatel.fr > sebastien.josset@space.alcatel.fr > > > Best regards, > > Laurence Duquerroy > Sébastien Josset > > > > > > Lakshminath Dondeti on 18/06/2003 20:11:54 > > Pour : msec@securemulticast.org > cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) > Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > > > ------------------------------------------------------------------------ > > > Hi all, > > I forwarded this new I-D announcement from IETF-Announce to a small > group of MSEC regulars and no one was aware of it. Assuming that others > haven't seen it either, here it is on Thomas's request. > > Could the authors (if they see this) please send their email addresses > to the group (not in I-D)? I have some questions on the I-D. Thanks. > > regards, > Lakshminath > > -------- Original Message -------- > Subject: I-D ACTION:draft-duquer-fmke-00.txt > Date: Wed, 18 Jun 2003 07:52:40 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-00.txt > Pages : 30 > Date : 2003-6-17 > > This document presents a new group key management protocol called > FMKE (Flat Multicast Key Exchange). Its objective is to manage > securely group Security Associations (SA), i.e. establish and update > SAs in Group members. These members can be identified for instance > by a multicast IP address, a virtual LAN identifier, or a generic > group label. This protocol is based on a centralized management, > achieved by the GCKS (Group Controller and Key Server). It is > destined to be used by Data Security protocols which wish to secure > group communications. For the time being, the considered Data > Security protocol is a multicast version of the IPSEC ESP protocol, > but other Data Security protocols could be envisaged. The FMKE > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > Encryption Keys). The FMKE protocol is optimized for very large > groups with direct connections such as satellite systems, or wireless > systems such as WIFI. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > > > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 20 09:03:17 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04915 for ; Fri, 20 Jun 2003 09:03:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A83515379D; Fri, 20 Jun 2003 09:02:46 -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 F14DC536E4 for ; Fri, 20 Jun 2003 09:00:47 -0400 (EDT) Received: (qmail 71731 invoked by uid 3269); 20 Jun 2003 13:00:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71719 invoked from network); 20 Jun 2003 13:00:47 -0000 Received: from colt-na7.alcatel.fr (HELO smail3.alcatel.fr) (62.23.212.7) by klesh.pair.com with SMTP; 20 Jun 2003 13:00:47 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5KD0cvh026331; Fri, 20 Jun 2003 15:00:38 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D4B.0047374B ; Fri, 20 Jun 2003 14:57:51 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: Lakshminath Dondeti Cc: msec@securemulticast.org, Sebastien.Josset@space.alcatel.fr Message-ID: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Virus-Scanned: by amavisd-new Subject: [MSEC] =?iso-8859-1?Q?R=E9f._:_Re:_[MSEC]_R=E9f._:_[MSEC]_[Fwd:_I-D_ACTI?= =?iso-8859-1?Q?ON:draft-duquer-fmke-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: Fri, 20 Jun 2003 14:57:16 +0200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA04915 Hi, Thank you for your interest. FMKE can be seen as an extension of the group key management protocols defined in MSEC (and more precisely of GDOI), which aims at providing an optimized scheme for satellite systems. Indeed, satellite based systems have specific features which imply specific requirements : - bandwidth limitation, which implies overhead and signaling information volume minimization. - High transmission delays - A flat architecture with a high number of satellite terminals (senders and receivers) (for instance 60000 satellite terminals) - Need for reliable exchanges Thus, FMKE is designed to limit the number of messages exchanged between group members and GCKS. For instance the FMKE phase 2 is less resource consuming than the GDOI ?group key push?, as it requires less messages for an equal number of SAs to transmit. Moreover, on the contrary of the MSEC protocols, FMKE implements reliable key distribution exchanges (multicast and unicast). Besides the reliability mechanisms are optimized with regards to the bandwidth. Another difference is that in the context of satellite systems, satellite terminals (= group members) have to protect traffic that they do not generate themselves (they are generated by user equipment behind satellite terminals). So they know very few information about it. It is therefore more adapted that they receive directly data SAs from the GCKS for the traffic they have to protect, instead of requesting them. In FMKE they receive directly all the SAs they are authorized to get access to, belonging to one or several groups, without having to send a request. Don't hesitate to contact us if you want further clarification or information Best regards, Laurence Duquerroy Lakshminath Dondeti on 19/06/2003 14:48:16 Pour : Laurence.Duquerroy@space.alcatel.fr cc : msec@securemulticast.org Sebastien.Josset@space.alcatel.fr (ccc : Laurence Duquerroy/ALCATEL-SPACE) Objet : Re: [MSEC] Réf. : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] Hi, Many thanks for your email. I was wondering about the motivation for yet another protocol for group key management. We have too many already. Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-classic, GSAKMP and MIKEY, and the requirements that motivate the need for FMKE? regards, Lakshminath Laurence.Duquerroy@space.alcatel.fr wrote: > > Hi all, > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast > security scheme optimised to protect large multicast groups. Such a scheme is > designed for IP over Satellite, Wifi or DVB systems; it is a security solution > for the satellite segment. An implementation over DVB-S/RCS is planned in the > SatIP6 demonstrator. > > We have started to write an Internet Draft detailing our key exchange protocol > (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it could be > submitted to the MSEC Working Group (In fact, we thought it was too late to > submit it for the next IETF meeting.) > > We would be ready to present it to the next MSEC Working Group meeting at IETF57 > in Vienna. > > This solution is designed to provide a security solution optimized for satellite > systems. It is defined to be low ressource consuming in bandwidth, to provide a > reliable key distribution, to be used in one-to-many and many-to-many scenarios, > and to be scalable in these scenarios... > > We hope that you will find interest in it, and thank you in advance for your > comments and questions. > > Our e-mail addresses are : > laurence.duquerroy@space.alcatel.fr > sebastien.josset@space.alcatel.fr > > > Best regards, > > Laurence Duquerroy > Sébastien Josset > > > > > > Lakshminath Dondeti on 18/06/2003 20:11:54 > > Pour : msec@securemulticast.org > cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) > Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > > > ------------------------------------------------------------------------ > > > Hi all, > > I forwarded this new I-D announcement from IETF-Announce to a small > group of MSEC regulars and no one was aware of it. Assuming that others > haven't seen it either, here it is on Thomas's request. > > Could the authors (if they see this) please send their email addresses > to the group (not in I-D)? I have some questions on the I-D. Thanks. > > regards, > Lakshminath > > -------- Original Message -------- > Subject: I-D ACTION:draft-duquer-fmke-00.txt > Date: Wed, 18 Jun 2003 07:52:40 -0400 > From: Internet-Drafts@ietf.org > Reply-To: Internet-Drafts@ietf.org > To: IETF-Announce: ; > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The Flat Multicast Key Exchange protocol > Author(s) : L. Duquerroy, S. Josset > Filename : draft-duquer-fmke-00.txt > Pages : 30 > Date : 2003-6-17 > > This document presents a new group key management protocol called > FMKE (Flat Multicast Key Exchange). Its objective is to manage > securely group Security Associations (SA), i.e. establish and update > SAs in Group members. These members can be identified for instance > by a multicast IP address, a virtual LAN identifier, or a generic > group label. This protocol is based on a centralized management, > achieved by the GCKS (Group Controller and Key Server). It is > destined to be used by Data Security protocols which wish to secure > group communications. For the time being, the considered Data > Security protocol is a multicast version of the IPSEC ESP protocol, > but other Data Security protocols could be envisaged. The FMKE > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > Encryption Keys). The FMKE protocol is optimized for very large > groups with direct connections such as satellite systems, or wireless > systems such as WIFI. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > > > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 20 13:55:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20539 for ; Fri, 20 Jun 2003 13:55:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1D00553933; Fri, 20 Jun 2003 13:55: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 BADA853A82 for ; Fri, 20 Jun 2003 13:53:30 -0400 (EDT) Received: (qmail 19416 invoked by uid 3269); 20 Jun 2003 17:53:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19411 invoked from network); 20 Jun 2003 17:53:29 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 20 Jun 2003 17:53:29 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h5KHrLUN027586; Fri, 20 Jun 2003 12:53:23 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h5KHrE1L014788; Fri, 20 Jun 2003 12:53:17 -0500 Received: from sparta.com (dhcp-8.columbia.sparta.com [157.185.80.9]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA24413; Fri, 20 Jun 2003 13:53:12 -0400 (EDT) Subject: Re: [MSEC] Starting Last Call for GSAKMP-Classic draft for Experimental RFC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: msec@securemulticast.org To: Thomas Hardjono From: Hugh Harney In-Reply-To: <5.2.1.1.2.20030618095706.022a4cd8@pop.mail.yahoo.com> Message-Id: <0F5021C0-A348-11D7-8A80-000393DAD548@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 20 Jun 2003 13:53:12 -0400 Content-Transfer-Encoding: 7bit Thomas, I'd rather move the GSAKMP draft (previously know as Light) toward final call for a standard. GSAKMP has two other companies that have implemented GSAKMP implementations from the Internet Draft. We have updated the draft to reflect the comments we have received. There are a couple of projects, in the US and in Europe, that are looking at using GSAKMP in large systems. They want to see it move to a standard so that it can be contracted. I think we should take that step toward standardization. We are ready. While I'd like the GSAKMP-Classic draft (now called Tunneled GSAKMP) to eventually become an Experimental draft. I'd rather keep focused on the specification for standardization. Hugh On Wednesday, Jun 18, 2003, at 13:08 US/Eastern, Thomas Hardjono wrote: > > Folks, > > One of the WG actions items from the last IETF56 meeting in San > Francisco was to advance the GSAKMP-Classic draft to Experimental RFC > (as suggested by Russ). > > Thus, I'd like to begin the Last Call for GSAKMP-Classic. > > If there are outstanding issues, please bring them up on the > mailing-list. It would be good if we could finalize this WG item at > the next IETF. > > cheers, > > thomas > ------ > > > > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 20 15:22:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01938 for ; Fri, 20 Jun 2003 15:22:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1BBAE5386D; Fri, 20 Jun 2003 15:19: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 5FBB753866 for ; Fri, 20 Jun 2003 15:17:54 -0400 (EDT) Received: (qmail 31964 invoked by uid 3269); 20 Jun 2003 19:17:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31959 invoked from network); 20 Jun 2003 19:17:54 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 20 Jun 2003 19:17:54 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5KJHJm29802; Fri, 20 Jun 2003 12:17:19 -0700 (PDT) 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 NALGZC3D; Fri, 20 Jun 2003 12:17:19 -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 MGTS3Q4B; Fri, 20 Jun 2003 15:17:17 -0400 Message-ID: <3EF35D87.4060002@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: gsec@lists.tislabs.com Cc: msec@securemulticast.org, m.howarth@eim.surrey.ac.uk Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] [Fwd: 57th IETF: new GSEC I-D] 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, 20 Jun 2003 15:16:23 -0400 Content-Transfer-Encoding: 7bit Hi all, There is a new draft "draft-irtf-gsec-lifecycle-00.txt." Michael Howarth or someone from his team will be presenting the draft at GSEC in Vienna. best, Lakshminath PS: Michael, please post a *link to the I-D* to the group if you have one available. If not, we will wait until the I-D shows up in IETF-Announce. Thank you. +++++++++++++++ Life cycle key management costs in secure multicast ABSTRACT This Internet-Draft considers efficient key management for encrypted multicast traffic in large groups, where the group size and dynamics have a significant impact on the network load. We consider the life cycle key management costs of a multicast connection, and show for a Logical Key Hierarchy (LKH) how member pre-registration and periodic admission reduces the initialization cost, and how the optimum outdegree of a hierarchical tree varies with the expected member volatility and rekey factor. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 20 15:23:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02029 for ; Fri, 20 Jun 2003 15:23:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F1D58537AC; Fri, 20 Jun 2003 15:20:48 -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 3E30D536DF for ; Fri, 20 Jun 2003 15:19:27 -0400 (EDT) Received: (qmail 32358 invoked by uid 3269); 20 Jun 2003 19:19:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 32353 invoked from network); 20 Jun 2003 19:19:26 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 20 Jun 2003 19:19:26 -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 h5KJJJx06055; Fri, 20 Jun 2003 14:19:19 -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 NALGZCQ3; Fri, 20 Jun 2003 12:19:18 -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 MGTS3Q4F; Fri, 20 Jun 2003 15:19:17 -0400 Message-ID: <3EF35DFF.5010909@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: Hugh Harney Cc: Thomas Hardjono , msec@securemulticast.org Subject: Re: [MSEC] Starting Last Call for GSAKMP-Classic draft for Experimental RFC References: <0F5021C0-A348-11D7-8A80-000393DAD548@sparta.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: Fri, 20 Jun 2003 15:18:23 -0400 Content-Transfer-Encoding: 7bit Hugh, Has there been an update to the GSAKMP draft? Thanks. regards, Lakshminath Hugh Harney wrote: > Thomas, > > I'd rather move the GSAKMP draft (previously know as Light) toward final > call for a standard. GSAKMP has two other companies that have > implemented GSAKMP implementations from the Internet Draft. We have > updated the draft to reflect the comments we have received. > > There are a couple of projects, in the US and in Europe, that are > looking at using GSAKMP in large systems. They want to see it move to a > standard so that it can be contracted. I think we should take that step > toward standardization. We are ready. > > While I'd like the GSAKMP-Classic draft (now called Tunneled GSAKMP) to > eventually become an Experimental draft. I'd rather keep focused on the > specification for standardization. > > Hugh > > > > > On Wednesday, Jun 18, 2003, at 13:08 US/Eastern, Thomas Hardjono wrote: > >> >> Folks, >> >> One of the WG actions items from the last IETF56 meeting in San >> Francisco was to advance the GSAKMP-Classic draft to Experimental RFC >> (as suggested by Russ). >> >> Thus, I'd like to begin the Last Call for GSAKMP-Classic. >> >> If there are outstanding issues, please bring them up on the >> mailing-list. It would be good if we could finalize this WG item at >> the next IETF. >> >> cheers, >> >> thomas >> ------ >> >> >> >> >> >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec >> >> > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 > > > _______________________________________________ > 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 Fri Jun 20 16:04:59 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05849 for ; Fri, 20 Jun 2003 16:04:58 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BC9C953AA9; Fri, 20 Jun 2003 16:00:49 -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 3522953AA5 for ; Fri, 20 Jun 2003 15:59:23 -0400 (EDT) Received: (qmail 37676 invoked by uid 3269); 20 Jun 2003 19:59:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37673 invoked from network); 20 Jun 2003 19:59:22 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 20 Jun 2003 19:59:22 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M5.sparta.com (8.12.8/8.12.5) with ESMTP id h5KJx8UN032245; Fri, 20 Jun 2003 14:59:08 -0500 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.8/8.12.5) with ESMTP id h5KJx21L018664; Fri, 20 Jun 2003 14:59:05 -0500 Received: from sparta.com (dhcp-8.columbia.sparta.com [157.185.80.9]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA26474; Fri, 20 Jun 2003 15:59:00 -0400 (EDT) Subject: Re: [MSEC] Starting Last Call for GSAKMP-Classic draft for Experimental RFC Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Thomas Hardjono , msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3EF35DFF.5010909@nortelnetworks.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 20 Jun 2003 15:59:01 -0400 Content-Transfer-Encoding: 7bit We will be submitting an update for the Austria meeting. The changes are mainly editorial. On Friday, Jun 20, 2003, at 15:18 US/Eastern, Lakshminath Dondeti wrote: > Hugh, > > Has there been an update to the GSAKMP draft? Thanks. > > regards, > Lakshminath > > Hugh Harney wrote: >> Thomas, >> I'd rather move the GSAKMP draft (previously know as Light) toward >> final call for a standard. GSAKMP has two other companies that have >> implemented GSAKMP implementations from the Internet Draft. We have >> updated the draft to reflect the comments we have received. >> There are a couple of projects, in the US and in Europe, that are >> looking at using GSAKMP in large systems. They want to see it move to >> a standard so that it can be contracted. I think we should take that >> step toward standardization. We are ready. >> While I'd like the GSAKMP-Classic draft (now called Tunneled GSAKMP) >> to eventually become an Experimental draft. I'd rather keep focused >> on the specification for standardization. >> Hugh >> On Wednesday, Jun 18, 2003, at 13:08 US/Eastern, Thomas Hardjono >> wrote: >>> >>> Folks, >>> >>> One of the WG actions items from the last IETF56 meeting in San >>> Francisco was to advance the GSAKMP-Classic draft to Experimental >>> RFC (as suggested by Russ). >>> >>> Thus, I'd like to begin the Last Call for GSAKMP-Classic. >>> >>> If there are outstanding issues, please bring them up on the >>> mailing-list. It would be good if we could finalize this WG item at >>> the next IETF. >>> >>> cheers, >>> >>> thomas >>> ------ >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> msec mailing list >>> msec@securemulticast.org >>> http://www.pairlist.net/mailman/listinfo/msec >>> >>> >> Hugh Harney Sparta, Inc. >> hh@sparta.com 7075 Samuel Morse Drive >> (410) 872-1515 x203 Columbia, MD, 21046 >> _______________________________________________ >> 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 > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 11:06:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23807 for ; Mon, 23 Jun 2003 11:05:50 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EAFFC537F2; Mon, 23 Jun 2003 11:04:50 -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 3448853604 for ; Mon, 23 Jun 2003 11:03:48 -0400 (EDT) Received: (qmail 31477 invoked by uid 3269); 23 Jun 2003 15:03:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 31472 invoked from network); 23 Jun 2003 15:03:47 -0000 Received: from alpha.dante.org.uk (193.63.211.19) by klesh.pair.com with SMTP; 23 Jun 2003 15:03:47 -0000 Received: from [193.63.211.16] (helo=auckland.dante.org.uk) by alpha.dante.org.uk with esmtp (Exim 4.12) id 19USqK-0004sk-00 for msec@securemulticast.org; Mon, 23 Jun 2003 16:02:52 +0100 Message-Id: <4.3.1.2.20030623155943.03666270@mail.dante.org.uk> X-Sender: robert@mail.dante.org.uk X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 To: msec@securemulticast.org From: Rob Walton In-Reply-To: <3EF35DFF.5010909@nortelnetworks.com> References: <0F5021C0-A348-11D7-8A80-000393DAD548@sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Any MSEC'ers at FIRST conference 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, 23 Jun 2003 16:04:27 +0100 Hi, First let me introduce myself, my name is robert walton and i work at a company called DANTE, I am currently responsible for the security on the GEANT network and for my sins I have been forced to look into the murky world of multicast security. ;o) I've been a residual lurker on your mailing list for the last month or so and i'd like to thank everyone for the great info i have been able to acquire just from 'sniffing' your mails. I'm actually at the FIRST conference at the moment and i was wondering if any of you guys are here also as i would love the opportunity to grab one of you guys and drain your MSEC knowledge even more, so if any of you are here also please ping me back and i'll make sure to look out for you. many thanks, Rob Walton _________________________________________________________________ * * Rob Walton - Network Security Consultant * * DANCERT * Francis House Tel +44 1223 302 992 * 112 Hills Road Fax +44 1223 303 005 * Cambridge CB2 1PQ D A N T E United Kingdom _________________________________________________________________ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 12:03:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26421 for ; Mon, 23 Jun 2003 12:03:16 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6094C53786; Mon, 23 Jun 2003 12:02:47 -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 263A953653 for ; Mon, 23 Jun 2003 12:01:06 -0400 (EDT) Received: (qmail 40405 invoked by uid 3269); 23 Jun 2003 16:01:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40402 invoked from network); 23 Jun 2003 16:01:06 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 23 Jun 2003 16:01:06 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5NFrVm24835; Mon, 23 Jun 2003 08:53:33 -0700 (PDT) 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 NALG56BY; Mon, 23 Jun 2003 08:53:02 -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 MGTS3RZ3; Mon, 23 Jun 2003 11:53:00 -0400 Message-ID: <3EF72226.9000808@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: gsec@lists.tislabs.com Cc: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] FYI: draft-irtf-gsec-lifecycle-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: Mon, 23 Jun 2003 11:52:06 -0400 Content-Transfer-Encoding: 7bit ftp://ietf.org/internet-drafts/draft-irtf-gsec-lifecycle-00.txt -------- Original Message -------- Subject: Re: [MSEC] [Fwd: 57th IETF: new GSEC I-D] Date: Mon, 23 Jun 2003 07:30:58 -0400 (Eastern Daylight Time) From: Natalia Syracuse To: "Dondeti, Lakshminath [BL60:1A14:EXCH]" Already posted ftp://ietf.org/internet-drafts/draft-irtf-gsec-lifecycle-00.txt On Fri, 20 Jun 2003, Lakshminath Dondeti wrote: > Hi all, > > There is a new draft "draft-irtf-gsec-lifecycle-00.txt." Michael > Howarth or someone from his team will be presenting the draft at GSEC in > Vienna. > > best, > Lakshminath > > PS: Michael, please post a *link to the I-D* to the group if you have > one available. If not, we will wait until the I-D shows up in > IETF-Announce. Thank you. > > +++++++++++++++ > > Life cycle key management costs in secure multicast > > > > ABSTRACT > > This Internet-Draft considers efficient key management for > encrypted multicast traffic in large groups, where the group size > and dynamics have a significant impact on the network load. We > consider the life cycle key management costs of a multicast > connection, and show for a Logical Key Hierarchy (LKH) how member > pre-registration and periodic admission reduces the initialization > cost, and how the optimum outdegree of a hierarchical tree varies > with the expected member volatility and rekey factor. > > > > _______________________________________________ > 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 Mon Jun 23 15:23:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06367 for ; Mon, 23 Jun 2003 15:22:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3718553996; Mon, 23 Jun 2003 15:21: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 0E5F953897 for ; Mon, 23 Jun 2003 15:19:48 -0400 (EDT) Received: (qmail 73804 invoked by uid 3269); 23 Jun 2003 19:19:48 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73801 invoked from network); 23 Jun 2003 19:19:48 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 23 Jun 2003 19:19:48 -0000 Received: (qmail 97716 invoked from network); 23 Jun 2003 19:19:48 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 23 Jun 2003 19:19:48 -0000 Received: (qmail 73379 invoked from network); 23 Jun 2003 19:19:47 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.182) by mail.nac.net with SMTP; 23 Jun 2003 19:19:47 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5NHHud04194; Mon, 23 Jun 2003 13:17:56 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] MSEC v01 arch, comments on section 2 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, 23 Jun 2003 13:17:56 -0400 (EDT) Hi, I finally got around to reviewing the v01 MSEC architecture document now in last call. I had several comments. This e-mail is the first of several that will follow... As a general comment, I'd first like to say that this version is much improved over its predessor. It is more of a tutorial nature than requirements or architecture doc, as it has a dearth of "MUST" and "SHOULD". Is that the intent? If so, perhaps the intro should say so... Somewhere in the architecture document, perhaps in section 2, I would expect see a statement about MSEC architectural assumptions with respect to the following Internet properties/peer subsystems: 1 - For data traffic multicast, what error recovery procedure(s) are required to detect and avoid network congestion? acks/nacks? what about Explicit Congestion Notification (ECN)? 2 - how to assure the security of the IGMP, MLD, and the multicast routing protocol(s) like PIM? 3 - Should/do the group key management protocols assume an underlying reliable transport service? 4 - while this may be implied, you should indicate this architecture is independent of IP-v4 or IP-v6 and that the secure multicast protocols MUST operate with both. 5 - how does the secure multicast architecture interact with NAT? is it required to work across multiple NAT boundaries? (e.g. does group AH break?) 6 - does the architecture assume a single common PKI that spans all members of the group or shared secrets (which does not scale)? 7 - does the architecture have a particular profile on X.509 certificates that would assure interoperability (witness the discussions on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid that swamp?) 8 - what happens when the secure multicast architecture traverses an IPSEC gateway? It seems that implicitly you are defining transport mode multicast data security associations? or could they be in tunnel mode? if the latter, then mention that and how it works. br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 15:37:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07261 for ; Mon, 23 Jun 2003 15:37:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 010495398A; Mon, 23 Jun 2003 15:37: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 9056153882 for ; Mon, 23 Jun 2003 15:35:18 -0400 (EDT) Received: (qmail 76324 invoked by uid 3269); 23 Jun 2003 19:35:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76321 invoked from network); 23 Jun 2003 19:35:18 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 23 Jun 2003 19:35:18 -0000 Received: (qmail 35799 invoked from network); 23 Jun 2003 19:35:17 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 23 Jun 2003 19:35:17 -0000 Received: (qmail 98266 invoked from network); 23 Jun 2003 19:35:15 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.182) by mail.nac.net with SMTP; 23 Jun 2003 19:35:15 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5NHXOB04265; Mon, 23 Jun 2003 13:33:24 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] MSEC arch v01, comments on section 3.1 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Jun 2003 13:33:23 -0400 (EDT) Hi, my comments on the architecture section 3.1: Multicast data encrypted and/or authenticated by a sender should be gmg> would like to suggest here: s/should/MUST/ handled the same way by both centralized and distributed receivers, (as shown in Figure 1). The "Multicast Encapsulating Security Payload" [BCCR] provides the definition for Multicast ESP for data traffic. The "Multicast Source Authentication Transform Specification" [PCW] defines the use of the TESLA algorithm for source authentication in multicast. gmg> are you saying that TESLA source authentication is a MUST? SHOULD? MAY? gmg> how about mentioning asymmetric cipher digital signature as an alternative? br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 15:41:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07369 for ; Mon, 23 Jun 2003 15:41:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 957A653897; Mon, 23 Jun 2003 15:40:45 -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 4913B53882 for ; Mon, 23 Jun 2003 15:39:04 -0400 (EDT) Received: (qmail 76804 invoked by uid 3269); 23 Jun 2003 19:39:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 76800 invoked from network); 23 Jun 2003 19:39:04 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 23 Jun 2003 19:39:04 -0000 Received: (qmail 43624 invoked from network); 23 Jun 2003 19:39:02 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 23 Jun 2003 19:39:02 -0000 Received: (qmail 24571 invoked from network); 23 Jun 2003 19:39:02 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.182) by mail.nac.net with SMTP; 23 Jun 2003 19:39:02 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5NHbBv04274; Mon, 23 Jun 2003 13:37:11 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] MSEC arch, comments on section 4.1 Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Jun 2003 13:37:11 -0400 (EDT) Hi, A comment on the following passage in section 4.1: A security association is a commonly used term in cryptographic systems [RFC2401, RFC2409]. gmg> given that RFC2401bis and the ESPbis drafts are redefining SA selectors for the gmg> benefit of secure multicast, it seems timely to reference that work since it is gmg> what will be relevant in the foreseeable future. Or else indicate gmg> here what multicast SA selectors will be doing (since 2401 is gmg> misleading). br, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 15:49:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07660 for ; Mon, 23 Jun 2003 15:49:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8230C53882; Mon, 23 Jun 2003 15:49:04 -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 D3640539A8 for ; Mon, 23 Jun 2003 15:47:09 -0400 (EDT) Received: (qmail 78142 invoked by uid 3269); 23 Jun 2003 19:47:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78139 invoked from network); 23 Jun 2003 19:47:09 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 23 Jun 2003 19:47:09 -0000 Received: (qmail 67589 invoked from network); 23 Jun 2003 19:47:08 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 23 Jun 2003 19:47:08 -0000 Received: (qmail 66927 invoked from network); 23 Jun 2003 19:43:48 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.182) by mail.nac.net with SMTP; 23 Jun 2003 19:43:48 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5NHfuC04284; Mon, 23 Jun 2003 13:41:56 -0400 From: George Gross To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [MSEC] MSEC arch, comments on section 4.3 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, 23 Jun 2003 13:41:56 -0400 (EDT) Hi, I found the following text in section 4.3 confusing on my first read: 4.3 Structure of a GSA: Reasoning Figure 3 shows three categories of SAs that can be aggregated into a GSA. There is a need to maintain SAs between a Key Server and a group member (both a sender and a receiver) and among the members themselves. There are two SAs established between the GCKS and the members, and there is an SA established among the sending and receiving members. I would like to suggest the following rewording of the above text, (your discretion whether this intro is "better"). "Figure 3 shows the three categories of SA that together form a single GSA. These categories are: 1. Registration SA - A separate unicast SA between the GCKS and each group member, regardless of whether the group member is a sender or a receiver or both. 2. Rekey SA - A single multicast SA between the GCKS and all of the group members. 3. Data SA - A multicast SA between each multicast source speaker and the group's receivers. There are as many data SA as there are multicast sources allowed by the group's policy. hth, George _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 18:46:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14142 for ; Mon, 23 Jun 2003 18:46:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 32871535A3; Mon, 23 Jun 2003 18:45:09 -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 AD5DC535A2 for ; Mon, 23 Jun 2003 18:43:36 -0400 (EDT) Received: (qmail 7038 invoked by uid 3269); 23 Jun 2003 22:43:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7035 invoked from network); 23 Jun 2003 22:43:36 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 23 Jun 2003 22:43:36 -0000 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 15:46:43 -0800 Received: from cisco.com ([128.107.177.101]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h5NMhXgE022004; Mon, 23 Jun 2003 15:43:34 -0700 (PDT) Message-ID: <3EF78294.C85731CC@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: Laurence.Duquerroy@space.alcatel.fr Cc: Lakshminath Dondeti , msec@securemulticast.org, Sebastien.Josset@space.alcatel.fr Subject: Re: [MSEC] =?iso-8859-1?Q?R=E9f=2E?= : Re: [MSEC] =?iso-8859-1?Q?R=E9f=2E?= : [MSEC] [Fwd: I-D ACTION: draft-duquer-fmke-00.txt] References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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, 23 Jun 2003 15:43:32 -0700 Content-Transfer-Encoding: 8bit Hi Laurence, Thanks for explaining a little more about FMKE. I have some questions below. Laurence.Duquerroy@space.alcatel.fr wrote: > > Hi, > > Thank you for your interest. > > FMKE can be seen as an extension of the group key management protocols defined > in MSEC (and more precisely of GDOI), which aims at providing an optimized > scheme for satellite systems. Indeed, satellite based systems have specific > features which imply specific requirements : > - bandwidth limitation, which implies overhead and signaling > information volume minimization. > - High transmission delays > - A flat architecture with a high number of satellite terminals > (senders and receivers) (for instance 60000 satellite terminals) > - Need for reliable exchanges > > Thus, FMKE is designed to limit the number of messages exchanged between group > members and GCKS. For instance the FMKE phase 2 is less resource consuming than > the GDOI ?group key push?, as it requires less messages for an equal number of > SAs to transmit. > > Moreover, on the contrary of the MSEC protocols, FMKE implements reliable key > distribution exchanges (multicast and unicast). Besides the reliability > mechanisms are optimized with regards to the bandwidth. I'm wondering if the Phase 3 messages are distributed along with the data traffic? For example, if a satellite terminal realizes that it has missed a Phase 3 message, will it have time to request a retransmission (by sending a NACK) before it needs to use the keys? If so, do you expect that it will need to store them until the messages is retransmitted? I don't know much about satellite terminals, so I was wondering if they sufficient memory to store a lot of packets. Also, I wonder if the GCKS would be able to handle very large numbers of NACKs? For example, if there is a wide scale problem and a large group of satellite terminals discovered that they had missed one or more Phase 3 messages, they'd all send NACKs. If the GCKS has to spend a lot of time interpreting NACKs, the system won't be very efficient. > Another difference is that in the context of satellite systems, satellite > terminals (= group members) have to protect traffic that they do not generate > themselves (they are generated by user equipment behind satellite terminals). So > they know very few information about it. It is therefore more adapted that they > receive directly data SAs from the GCKS for the traffic they have to protect, > instead of requesting them. In FMKE they receive directly all the SAs they are > authorized to get access to, belonging to one or several groups, without having > to send a request. The GDOI protocol allows a wide variety of usage models. In the satellite setting, a GDOI group member can also directly receive data SAs from the GCKS for the traffic they have to protect. A satellite terminal would not need to know very much information -- only the "group" identifier that it sends in the GDOI registration ("Phase 2") protocol. In a satellite environment, I would expect the group identifier to represent a set of channels, or some other collection of services. This is used by the GDOI GCKS to check authorization of the group member, to ensure that it actually does belong to the group. Once authorized, the GCKS would return just the KEK for the group. The group member would then listen for multicasted rekey messages (what you call "Phase 3" messages) protected by that KEK. When it receives rekey messages, it then becomes aware of what traffic it needs to protect. In this manner, I believe that a GDOI group member can also directly receive data SAs from the GCKS for the traffic they have to protect. It occurs to me that the GCKS could choose to ignore the group ID if it has a different method of deciding to which group the satellite terminal belongs. The GCKS would send the appropriate KEK to the satellite terminal just as before, and the process would be exactly the same. But in this way the satellite terminal wouldn't have to know anything at all beforehand, and the registration messages would be relatively low-bandwidth messages. I hope this explanation makes sense. If not, please let me know. Thanks, Brian > Don't hesitate to contact us if you want further clarification or information > > Best regards, > > Laurence Duquerroy > > Lakshminath Dondeti on 19/06/2003 14:48:16 > > Pour : Laurence.Duquerroy@space.alcatel.fr > cc : msec@securemulticast.org > Sebastien.Josset@space.alcatel.fr (ccc : Laurence Duquerroy/ALCATEL-SPACE) > Objet : Re: [MSEC] Réf. : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > Hi, > > Many thanks for your email. I was wondering about the motivation for > yet another protocol for group key management. We have too many already. > > Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-classic, > GSAKMP and MIKEY, and the requirements that motivate the need for FMKE? > > regards, > Lakshminath > > Laurence.Duquerroy@space.alcatel.fr wrote: > > > > Hi all, > > > > In the context of the SatIP6 IST project, Alcatel Space studies a multicast > > security scheme optimised to protect large multicast groups. Such a scheme is > > designed for IP over Satellite, Wifi or DVB systems; it is a security solution > > for the satellite segment. An implementation over DVB-S/RCS is planned in the > > SatIP6 demonstrator. > > > > We have started to write an Internet Draft detailing our key exchange protocol > > (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it could be > > submitted to the MSEC Working Group (In fact, we thought it was too late to > > submit it for the next IETF meeting.) > > > > We would be ready to present it to the next MSEC Working Group meeting at > IETF57 > > in Vienna. > > > > This solution is designed to provide a security solution optimized for > satellite > > systems. It is defined to be low ressource consuming in bandwidth, to provide > a > > reliable key distribution, to be used in one-to-many and many-to-many > scenarios, > > and to be scalable in these scenarios... > > > > We hope that you will find interest in it, and thank you in advance for your > > comments and questions. > > > > Our e-mail addresses are : > > laurence.duquerroy@space.alcatel.fr > > sebastien.josset@space.alcatel.fr > > > > > > Best regards, > > > > Laurence Duquerroy > > Sébastien Josset > > > > > > > > > > > > Lakshminath Dondeti on 18/06/2003 20:11:54 > > > > Pour : msec@securemulticast.org > > cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) > > Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > > Hi all, > > > > I forwarded this new I-D announcement from IETF-Announce to a small > > group of MSEC regulars and no one was aware of it. Assuming that others > > haven't seen it either, here it is on Thomas's request. > > > > Could the authors (if they see this) please send their email addresses > > to the group (not in I-D)? I have some questions on the I-D. Thanks. > > > > regards, > > Lakshminath > > > > -------- Original Message -------- > > Subject: I-D ACTION:draft-duquer-fmke-00.txt > > Date: Wed, 18 Jun 2003 07:52:40 -0400 > > From: Internet-Drafts@ietf.org > > Reply-To: Internet-Drafts@ietf.org > > To: IETF-Announce: ; > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : The Flat Multicast Key Exchange protocol > > Author(s) : L. Duquerroy, S. Josset > > Filename : draft-duquer-fmke-00.txt > > Pages : 30 > > Date : 2003-6-17 > > > > This document presents a new group key management protocol called > > FMKE (Flat Multicast Key Exchange). Its objective is to manage > > securely group Security Associations (SA), i.e. establish and update > > SAs in Group members. These members can be identified for instance > > by a multicast IP address, a virtual LAN identifier, or a generic > > group label. This protocol is based on a centralized management, > > achieved by the GCKS (Group Controller and Key Server). It is > > destined to be used by Data Security protocols which wish to secure > > group communications. For the time being, the considered Data > > Security protocol is a multicast version of the IPSEC ESP protocol, > > but other Data Security protocols could be envisaged. The FMKE > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > > Encryption Keys). The FMKE protocol is optimized for very large > > groups with direct connections such as satellite systems, or wireless > > systems such as WIFI. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. > > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 22:30:23 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18771 for ; Mon, 23 Jun 2003 22:30:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EF05D537D9; Mon, 23 Jun 2003 22:29: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 04EE853579 for ; Mon, 23 Jun 2003 19:47:09 -0400 (EDT) Received: (qmail 16600 invoked by uid 3269); 23 Jun 2003 23:47:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16597 invoked from network); 23 Jun 2003 23:47:08 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 23 Jun 2003 23:47:08 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 23 Jun 2003 16:50:16 -0800 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NNl64v027964; Mon, 23 Jun 2003 16:47:06 -0700 (PDT) Message-ID: <3EF79179.91E81D9C@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: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] MSEC arch v01, comments on section 3.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Jun 2003 16:47:05 -0700 Content-Transfer-Encoding: 7bit Hi George, I'm not sure this document should have any MUSTs in it. As Thomas clarified recently, it is intended to be published as an Informational document rather than Standards-Track. The document is meant to define a framework for multicast security rather than define requirements for specific protocols or mechanisms. As such, we've avoided requirements keywords in the document. Thanks, Brian George Gross wrote: > > Hi, > > my comments on the architecture section 3.1: > > Multicast data encrypted and/or authenticated by a sender should be > > gmg> would like to suggest here: s/should/MUST/ > > handled the same way by both centralized and distributed receivers, > (as shown in Figure 1). > > The "Multicast Encapsulating Security Payload" [BCCR] provides the > definition for Multicast ESP for data traffic. The "Multicast Source > Authentication Transform Specification" [PCW] defines the use of the > TESLA algorithm for source authentication in multicast. > > gmg> are you saying that TESLA source authentication is a MUST? SHOULD? MAY? > gmg> how about mentioning asymmetric cipher digital signature as an alternative? > > br, > George > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 23 22:48:11 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19092 for ; Mon, 23 Jun 2003 22:48:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 21FEE53812; Mon, 23 Jun 2003 22:17:44 -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 789C053579 for ; Mon, 23 Jun 2003 19:34:27 -0400 (EDT) Received: (qmail 15000 invoked by uid 3269); 23 Jun 2003 23:34:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14997 invoked from network); 23 Jun 2003 23:34:27 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 23 Jun 2003 23:34:27 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 Jun 2003 16:36:16 -0800 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5NNYO4v018924; Mon, 23 Jun 2003 16:34:25 -0700 (PDT) Message-ID: <3EF78E7F.165C8CD2@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: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] MSEC arch, comments on section 4.3 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 23 Jun 2003 16:34:23 -0700 Content-Transfer-Encoding: 7bit Hi George, Thanks for the feedback about the text being confusing. I've adopted your text (tweaked a bit) for the next version of the document. Thanks! Brian George Gross wrote: > > Hi, > > I found the following text in section 4.3 confusing on my first > read: > > 4.3 Structure of a GSA: Reasoning > > Figure 3 shows three categories of SAs that can be aggregated into a > GSA. There is a need to maintain SAs between a Key Server and a group > member (both a sender and a receiver) and among the members > themselves. There are two SAs established between the GCKS and the > members, and there is an SA established among the sending and > receiving members. > > I would like to suggest the following rewording of the above text, (your > discretion whether this intro is "better"). > > "Figure 3 shows the three categories of SA that together form a single > GSA. These categories are: > > 1. Registration SA - A separate unicast SA between the GCKS and each > group member, regardless of whether the group member is a sender or a > receiver or both. > > 2. Rekey SA - A single multicast SA between the GCKS and all of the group > members. > > 3. Data SA - A multicast SA between each multicast source speaker and the > group's receivers. There are as many data SA as there are multicast > sources allowed by the group's policy. > > hth, > George > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 24 11:10:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19683 for ; Tue, 24 Jun 2003 11:10:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D0B1F53A17; Tue, 24 Jun 2003 10:30:44 -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 2EDB0535AD for ; Tue, 24 Jun 2003 10:29:04 -0400 (EDT) Received: (qmail 99531 invoked by uid 3269); 24 Jun 2003 14:29:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99528 invoked from network); 24 Jun 2003 14:29:04 -0000 Received: from dsl093-000-226.det1.dsl.speakeasy.net (HELO kade.ash.st) (66.93.0.226) by klesh.pair.com with SMTP; 24 Jun 2003 14:29:04 -0000 Received: from localhost (localhost [127.0.0.1]) by kade.ash.st (Postfix) with ESMTP id 77ED8AB67A for ; Tue, 24 Jun 2003 10:29:03 -0400 (EDT) Received: from kade.ash.st (localhost [127.0.0.1]) by localhost (VaMailArmor-2.0.1.11) id 13762-441EFCFF; Tue, 24 Jun 2003 10:29:03 -0400 Received: from 192.168.0.251 (unknown [192.168.0.251]) by kade.ash.st (Postfix) with ESMTP id 431CEAB67A for ; Tue, 24 Jun 2003 10:29:03 -0400 (EDT) From: "Amy A." To: msec@securemulticast.org User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306241029.02905.list@ash.st> X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.11; VAE: 6.20.0.1; VDF: 6.20.0.16; host: kade.ash.st) Subject: [MSEC] pam_timestamp 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, 24 Jun 2003 10:29:02 -0400 Content-Transfer-Encoding: 7bit Hello All, My logs are filled with ...... Jun 24 09:50:38 kade pam_timestamp_check: pam_timestamp: `/var/run/' owner GID != 0 and != 4 Jun 24 09:50:53 kade last message repeated 3 times I believe it has to do with msec, but I am not sure.....does anyone have any ideas??? Thank you very much for any help, I very much appreciate it!!! Amy A. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jun 24 21:40:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02155 for ; Tue, 24 Jun 2003 21:40:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 545595393A; Tue, 24 Jun 2003 21:12:51 -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 AA35853775 for ; Tue, 24 Jun 2003 21:11:19 -0400 (EDT) Received: (qmail 3297 invoked by uid 3269); 25 Jun 2003 01:11:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3294 invoked from network); 25 Jun 2003 01:11:19 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 25 Jun 2003 01:11:19 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 24 Jun 2003 18:14:30 -0800 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5P1BDMO007727; Tue, 24 Jun 2003 18:11:15 -0700 (PDT) Message-ID: <3EF8F6B0.395E7C83@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: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] MSEC arch, comments on section 4.1 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 24 Jun 2003 18:11:12 -0700 Content-Transfer-Encoding: 7bit Hi George, This text doesn't mean to define a security association to be exactly that in RFC2401, etc., but as a more general concept. I'll try to make that more clear. Still, it's a good idea to reference the newer documents as you suggest. Thanks, Brian George Gross wrote: > > Hi, > > A comment on the following passage in section 4.1: > > A security association is a commonly used term in cryptographic > systems [RFC2401, RFC2409]. > > gmg> given that RFC2401bis and the ESPbis drafts are redefining SA selectors for the > gmg> benefit of secure multicast, it seems timely to reference that work since it is > gmg> what will be relevant in the foreseeable future. Or else indicate > gmg> here what multicast SA selectors will be doing (since 2401 is > gmg> misleading). > > br, > George > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 08:31:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07956 for ; Wed, 25 Jun 2003 08:31:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9F1C6538FA; Wed, 25 Jun 2003 08:00: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 93C1153822 for ; Wed, 25 Jun 2003 07:58:23 -0400 (EDT) Received: (qmail 44628 invoked by uid 3269); 25 Jun 2003 11:58:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 44625 invoked from network); 25 Jun 2003 11:58:23 -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; 25 Jun 2003 11:58:23 -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.6b) with ESMTP id h5PBwLG5017672; Wed, 25 Jun 2003 13:58:22 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Wed, 25 Jun 2003 13:58:24 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4C69@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (EAB)" To: msec@securemulticast.org, Ran Canetti Cc: "'steffen.fries@siemens.com'" Subject: RE: [MSEC] DH mode in 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: Wed, 25 Jun 2003 13:57:28 +0200 To wrap up the discussion, from the mails we have seen, it seems as there is support for the DH-mode. The fact that H.323 uses MIKEY with DH in its specs gives also an extra motivation to keep the DH-mode. We would therefore like to suggest that our initial recommendation is followed, i.e. to keep the DH mode, but - better clarify the difference between the DH mode and the other modes in the document, and - make the DH mode optional to implement. Fredrik > -----Original Message----- > From: Steffen Fries [mailto:steffen.fries@siemens.com] > Sent: den 18 juni 2003 15:38 > To: msec@securemulticast.org; Ran Canetti > Subject: Re: [MSEC] DH mode in MIKEY > > > Hi Ran, > > I made some inline comments. > > (a)If we're already having an upstream message, then why not have a > > three-message protocol that is based on nonces rather than > timestamps? > > (nonces are easier to deal with, and they are not susceptible to > > "clock rewinding attacks"). > In multimedia sytems there are protocols used that just feature > a two message exchange between the sender and the receiver. > Here MIKEY can be applied. One example is the usage of Fast > Start in H.323. Here only the SETUP message and the appropriate > response message are sent. A three way protocol would add an > extra message to Fast Start, which is not desired. Furthermore, > MIKEY has already been considered by the ITU-T for usage in > H.323 in combination with SRTP in Draft H.235 Annex G. > Again, in multimedia environments MIKEY is intended to be > incorporated into (existing) VoIP protocols using only a full > handshake rather than be used standalone. > Moreover, DH is useful in this case to have e.g. PFS (see also > point c below). > > (b) If we're already having a nonce-based > > DH exchange, then why not use an off-the-shelf protocol such as > > TLS/SSH/IKE etc., rather than doing things from scratch? (for > > instance, if we use IKEv2, we get a four message exchange that is > > already protectign against DOS, is relatively well analyzed, etc.) > MIKEY is defined in a way that it may be integrated into > existing protocols as a key management container. This is for > instance the case for SIP and H.323. Because of the few > messages needed by MIKEY for key management and security policy > negotiation it integrates nicely in protocols only using a full > handshake to establish a session between two parties. Other key > management approaches like the ones you mentioned require more > messages to be exchanged. > > (c) > > MIKEY is directed at media and multimedia straming. Is PFS an > > important concern for such scenarios? is it worth the extra > > complexity? > MIKEY may be used in VoIP environments to provide means for > media data protection. PFS may not be necessary in every case > but PFS is a security property, which cannot be achieved in any > other way. If this is worth the extra effort may be a scenario > specific question. Nvertheless, PFS provides additional > security, with the ensurance that the security may not be > compromised in a backwards way. > You might compare this additional security functionality with > somebody who encrypts files on his PC despite the fact that the > PC is protected against unauthorized access. > > Steffen > > > > > > _______________________________________________ > 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 Jun 25 09:24:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08673 for ; Wed, 25 Jun 2003 09:24:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C1D295380A; Wed, 25 Jun 2003 09:22:47 -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 A36C7536D0 for ; Wed, 25 Jun 2003 09:20:41 -0400 (EDT) Received: (qmail 63266 invoked by uid 3269); 25 Jun 2003 13:20:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63263 invoked from network); 25 Jun 2003 13:20:41 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 25 Jun 2003 13:20:41 -0000 Received: (qmail 30018 invoked from network); 25 Jun 2003 13:20:40 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 25 Jun 2003 13:20:40 -0000 Received: (qmail 6000 invoked from network); 25 Jun 2003 13:20:39 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.172) by mail.nac.net with SMTP; 25 Jun 2003 13:20:39 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5PBIRo09519; Wed, 25 Jun 2003 07:18:27 -0400 From: George Gross To: Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 25 Jun 2003 07:18:26 -0400 (EDT) Hi, With Mounir's permission, I'm forwarding an exchange we had wrt/ securing IGMP/MLD/PIM as part of MSEC... George ---------- Forwarded message ---------- Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) From: George Gross To: mounir.kellil@hds.utc.fr Cc: George Gross Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 Hi Mounir, My goal with the section 2 questions was to tease out some of the unspoken assumptions that lurk in the architecture if one were to actually deploy MSEC. While Brian and Tom have yet to weigh in on this topic, I imagine that adding refs to the GSEC RG work is a beginning, but not all that needs to be said in the arch doc wrt/ to this comment. I think the architecture doc has to describe, and the MSEC protocols have to define an extensible mechanism(s) to encapsulate an opaque IGMP/MLD authorization/authentication information payload within the {GSAKMP, GDOI, whatever} key management protocol to each group member. With this coupling, I think that the multicast session becomes far more secure. securing PIM or the multicast routing protocol du jour is another interface to MSEC that needs to be mentioned in the arch doc, and perhaps ultimately standardized... br, George On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > Hi George, > > I think that you asked very intersting questions with respect to section 2. > > For your follwong questions: > > 2 - how to assure the security of the IGMP, MLD, and the multicast > > routing protocol(s) like PIM? > > > > I think Group Membership (MLD, IGMP) security issues as well as multicast > routing porotocols security issues are adressed (exclusively) in GSEC RG. For > the security issues in multicast routing protocols, it seems that there is a > specific solution for each protocol. > > May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > both propose extending GDOI to secure respectively IGMP and PIM-SM. > > However, I think that securing Group membership and multicast protocol > protocols basing on GkmArch may not be a good thing as it makes the securty > solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at > least partially) GkMArch form the other two issues can ensure a multi- > (independent)level security need. > > > Mounir > > ------------------------------------------------- > Laboratoire Heudiasyc. UMR CNRS 6599 > http://www.hds.utc.fr > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 09:43:12 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09393 for ; Wed, 25 Jun 2003 09:43:11 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B6790539E1; Wed, 25 Jun 2003 09:42:42 -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 D97D0537D7 for ; Wed, 25 Jun 2003 09:40:00 -0400 (EDT) Received: (qmail 66274 invoked by uid 3269); 25 Jun 2003 13:40:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66266 invoked from network); 25 Jun 2003 13:40:00 -0000 Received: from diabolo.hds.utc.fr (195.83.157.26) by klesh.pair.com with SMTP; 25 Jun 2003 13:40:00 -0000 Received: from localhost (diabolo.gi.utc [172.17.1.26]) by diabolo.hds.utc.fr (Postfix) with ESMTP id EC1EA6E8B; Wed, 25 Jun 2003 15:44:00 +0200 (MEST) Received: from wwwgate111.motorola.com (wwwgate111.motorola.com [212.234.3.190]) by mail.hds.utc.fr (IMP) with HTTP for ; Wed, 25 Jun 2003 15:44:00 +0200 Message-ID: <1056548640.3ef9a720d474d@mail.hds.utc.fr> From: mounir.kellil@hds.utc.fr To: George Gross Cc: msec@securemulticast.org Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2 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, 25 Jun 2003 15:44:00 +0200 Content-Transfer-Encoding: 8bit Hi all, Hi George, It may be an intersting idea. However, the GCKSs are not MLD/IGMP-capable. Group membership managment (MLD/IGMP) process is typically performed by multicast routers. The drafts I mentioned in the previous e-mail suggest enxtending GSA to multicast routers...Why not.. Mounir Selon George Gross : > Hi, > With Mounir's permission, I'm forwarding an exchange we had wrt/ > securing IGMP/MLD/PIM as part of MSEC... > > George > > ---------- Forwarded message ---------- > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > From: George Gross > To: mounir.kellil@hds.utc.fr > Cc: George Gross > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > Hi Mounir, > > My goal with the section 2 questions was to tease out some of the > unspoken assumptions that lurk in the architecture if one were to actually > deploy MSEC. > > While Brian and Tom have yet to weigh in on this topic, I imagine > that adding refs to the GSEC RG work is a beginning, but not all that > needs to be said in the arch doc wrt/ to this comment. I think the > architecture doc has to describe, and the MSEC protocols have to define an > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > authorization/authentication information payload within the {GSAKMP, GDOI, > whatever} key management protocol to each group member. With this > coupling, I think that the multicast session becomes far more secure. > > securing PIM or the multicast routing protocol du jour is another > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > ultimately standardized... > > br, > George > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > Hi George, > > > > I think that you asked very intersting questions with respect to section > 2. > > > > For your follwong questions: > > > 2 - how to assure the security of the IGMP, MLD, and the multicast > > > routing protocol(s) like PIM? > > > > > > > I think Group Membership (MLD, IGMP) security issues as well as multicast > > routing porotocols security issues are adressed (exclusively) in GSEC RG. > For > > the security issues in multicast routing protocols, it seems that there is > a > > specific solution for each protocol. > > > > May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > > security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as > they > > both propose extending GDOI to secure respectively IGMP and PIM-SM. > > > > However, I think that securing Group membership and multicast protocol > > protocols basing on GkmArch may not be a good thing as it makes the > securty > > solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling > (at > > least partially) GkMArch form the other two issues can ensure a multi- > > (independent)level security need. > > > > > > Mounir > > > > ------------------------------------------------- > > Laboratoire Heudiasyc. UMR CNRS 6599 > > http://www.hds.utc.fr > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > ------------------------------------------------- Laboratoire Heudiasyc. UMR CNRS 6599 http://www.hds.utc.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 09:47:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09616 for ; Wed, 25 Jun 2003 09:47:46 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 11DE153A12; Wed, 25 Jun 2003 09:47: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 2F184537D7 for ; Wed, 25 Jun 2003 09:41:31 -0400 (EDT) Received: (qmail 66553 invoked by uid 3269); 25 Jun 2003 13:41:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66550 invoked from network); 25 Jun 2003 13:41:31 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 25 Jun 2003 13:41:31 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5PDfQC03338; Wed, 25 Jun 2003 06:41:26 -0700 (PDT) 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 NALG9V1L; Wed, 25 Jun 2003 06:41:26 -0700 Received: from nortelnetworks.com (artpt60v.us.nortel.com [47.140.53.222]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MGTS34DK; Wed, 25 Jun 2003 09:41:24 -0400 Message-ID: <3EF9A772.1010807@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: George Gross Cc: msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: 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, 25 Jun 2003 09:45:22 -0400 Content-Transfer-Encoding: 7bit There are several old expired drafts that discussed IGMP and PIM security. Most of the folks in MSEC are aware of that work, yet decided to not include protocol security in the charter. It may belong in a separate WG IMO (e.g., IPSEC WG designs protocols for data protection and RPSEC discusses routing protocol protection). You are welcome to bring any new ideas (or revise old I-Ds and bring them for discussion) to the GSEC meeting; most MSEC regulars will show up and the RG might decide how to proceed . I think the MSEC architecture I-D should proceed with its current scope. regards, Lakshminath George Gross wrote: > Hi, > With Mounir's permission, I'm forwarding an exchange we had wrt/ > securing IGMP/MLD/PIM as part of MSEC... > > George > > ---------- Forwarded message ---------- > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > From: George Gross > To: mounir.kellil@hds.utc.fr > Cc: George Gross > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > Hi Mounir, > > My goal with the section 2 questions was to tease out some of the > unspoken assumptions that lurk in the architecture if one were to actually > deploy MSEC. > > While Brian and Tom have yet to weigh in on this topic, I imagine > that adding refs to the GSEC RG work is a beginning, but not all that > needs to be said in the arch doc wrt/ to this comment. I think the > architecture doc has to describe, and the MSEC protocols have to define an > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > authorization/authentication information payload within the {GSAKMP, GDOI, > whatever} key management protocol to each group member. With this > coupling, I think that the multicast session becomes far more secure. > > securing PIM or the multicast routing protocol du jour is another > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > ultimately standardized... > > br, > George > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > >>Hi George, >> >>I think that you asked very intersting questions with respect to section 2. >> >>For your follwong questions: >> >>> 2 - how to assure the security of the IGMP, MLD, and the multicast >>>routing protocol(s) like PIM? >>> >> >>I think Group Membership (MLD, IGMP) security issues as well as multicast >>routing porotocols security issues are adressed (exclusively) in GSEC RG. For >>the security issues in multicast routing protocols, it seems that there is a >>specific solution for each protocol. >> >>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- >>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they >>both propose extending GDOI to secure respectively IGMP and PIM-SM. >> >>However, I think that securing Group membership and multicast protocol >>protocols basing on GkmArch may not be a good thing as it makes the securty >>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at >>least partially) GkMArch form the other two issues can ensure a multi- >>(independent)level security need. >> >> >>Mounir >> >>------------------------------------------------- >>Laboratoire Heudiasyc. UMR CNRS 6599 >>http://www.hds.utc.fr >> > > > > _______________________________________________ > 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 Jun 25 09:51:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09743 for ; Wed, 25 Jun 2003 09:51:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 727775384E; Wed, 25 Jun 2003 09:50: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 642D2537D7 for ; Wed, 25 Jun 2003 09:49:34 -0400 (EDT) Received: (qmail 68123 invoked by uid 3269); 25 Jun 2003 13:49:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68120 invoked from network); 25 Jun 2003 13:49:34 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 25 Jun 2003 13:49:34 -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 h5PDnQL26396; Wed, 25 Jun 2003 08:49:27 -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 NALG9VXR; Wed, 25 Jun 2003 06:49:27 -0700 Received: from nortelnetworks.com (artpt60v.us.nortel.com [47.140.53.222]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id MGTS341G; Wed, 25 Jun 2003 09:49:24 -0400 Message-ID: <3EF9A952.7080201@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: mounir.kellil@hds.utc.fr Cc: George Gross , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: <1056548640.3ef9a720d474d@mail.hds.utc.fr> Content-Type: text/plain; charset=ISO-8859-15; 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, 25 Jun 2003 09:53:22 -0400 Content-Transfer-Encoding: 7bit Mounir, I assume you are talking about a separate GSA for routing protocol protection. Lakshminath mounir.kellil@hds.utc.fr wrote: > Hi all, > Hi George, > It may be an intersting idea. However, the GCKSs are not MLD/IGMP-capable. > Group membership managment (MLD/IGMP) process is typically performed by > multicast routers. The drafts I mentioned in the previous e-mail suggest > enxtending GSA to multicast routers...Why not.. > > Mounir > Selon George Gross : > > >>Hi, >> With Mounir's permission, I'm forwarding an exchange we had wrt/ >>securing IGMP/MLD/PIM as part of MSEC... >> >> George >> >>---------- Forwarded message ---------- >>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) >>From: George Gross >>To: mounir.kellil@hds.utc.fr >>Cc: George Gross >>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 >> >>Hi Mounir, >> >> My goal with the section 2 questions was to tease out some of the >>unspoken assumptions that lurk in the architecture if one were to actually >>deploy MSEC. >> >> While Brian and Tom have yet to weigh in on this topic, I imagine >>that adding refs to the GSEC RG work is a beginning, but not all that >>needs to be said in the arch doc wrt/ to this comment. I think the >>architecture doc has to describe, and the MSEC protocols have to define an >>extensible mechanism(s) to encapsulate an opaque IGMP/MLD >>authorization/authentication information payload within the {GSAKMP, GDOI, >>whatever} key management protocol to each group member. With this >>coupling, I think that the multicast session becomes far more secure. >> >>securing PIM or the multicast routing protocol du jour is another >>interface to MSEC that needs to be mentioned in the arch doc, and perhaps >>ultimately standardized... >> >>br, >> George >> >>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: >> >> >>>Hi George, >>> >>>I think that you asked very intersting questions with respect to section >> >>2. >> >>>For your follwong questions: >>> >>>> 2 - how to assure the security of the IGMP, MLD, and the multicast >>>>routing protocol(s) like PIM? >>>> >>> >>>I think Group Membership (MLD, IGMP) security issues as well as multicast >>>routing porotocols security issues are adressed (exclusively) in GSEC RG. >> >>For >> >>>the security issues in multicast routing protocols, it seems that there is >> >>a >> >>>specific solution for each protocol. >>> >>>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- >>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as >> >>they >> >>>both propose extending GDOI to secure respectively IGMP and PIM-SM. >>> >>>However, I think that securing Group membership and multicast protocol >>>protocols basing on GkmArch may not be a good thing as it makes the >> >>securty >> >>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling >> >>(at >> >>>least partially) GkMArch form the other two issues can ensure a multi- >>>(independent)level security need. >>> >>> >>>Mounir >>> >>>------------------------------------------------- >>>Laboratoire Heudiasyc. UMR CNRS 6599 >>>http://www.hds.utc.fr >>> >> >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec >> > > > > > > ------------------------------------------------- > Laboratoire Heudiasyc. UMR CNRS 6599 > http://www.hds.utc.fr > > > _______________________________________________ > 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 Jun 25 09:59:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09988 for ; Wed, 25 Jun 2003 09:59:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1DD2253858; Wed, 25 Jun 2003 09:58:39 -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 48623535DA for ; Wed, 25 Jun 2003 09:57:59 -0400 (EDT) Received: (qmail 69536 invoked by uid 3269); 25 Jun 2003 13:57:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 69528 invoked from network); 25 Jun 2003 13:57:58 -0000 Received: from diabolo.hds.utc.fr (195.83.157.26) by klesh.pair.com with SMTP; 25 Jun 2003 13:57:58 -0000 Received: from localhost (diabolo.gi.utc [172.17.1.26]) by diabolo.hds.utc.fr (Postfix) with ESMTP id D0ABF6E8B; Wed, 25 Jun 2003 16:01:59 +0200 (MEST) Received: from wwwgate111.motorola.com (wwwgate111.motorola.com [212.234.3.190]) by mail.hds.utc.fr (IMP) with HTTP for ; Wed, 25 Jun 2003 16:01:59 +0200 Message-ID: <1056549719.3ef9ab57afdaf@mail.hds.utc.fr> From: mounir.kellil@hds.utc.fr To: Lakshminath Dondeti Cc: George Gross , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: <1056548640.3ef9a720d474d@mail.hds.utc.fr> <3EF9A952.7080201@nortelnetworks.com> In-Reply-To: <3EF9A952.7080201@nortelnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2 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, 25 Jun 2003 16:01:59 +0200 Content-Transfer-Encoding: 8bit Lakshminath Yes, you are right to mention it. Multicast routers do not get TEK and KEKs ( they are not trusted in the viewpoint of data secrecy in particular) Mounir Selon Lakshminath Dondeti : > Mounir, > > I assume you are talking about a separate GSA for routing protocol > protection. > > Lakshminath > > mounir.kellil@hds.utc.fr wrote: > > Hi all, > > Hi George, > > It may be an intersting idea. However, the GCKSs are not MLD/IGMP-capable. > > > Group membership managment (MLD/IGMP) process is typically performed by > > multicast routers. The drafts I mentioned in the previous e-mail suggest > > enxtending GSA to multicast routers...Why not.. > > > > Mounir > > Selon George Gross : > > > > > >>Hi, > >> With Mounir's permission, I'm forwarding an exchange we had wrt/ > >>securing IGMP/MLD/PIM as part of MSEC... > >> > >> George > >> > >>---------- Forwarded message ---------- > >>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > >>From: George Gross > >>To: mounir.kellil@hds.utc.fr > >>Cc: George Gross > >>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > >> > >>Hi Mounir, > >> > >> My goal with the section 2 questions was to tease out some of the > >>unspoken assumptions that lurk in the architecture if one were to actually > >>deploy MSEC. > >> > >> While Brian and Tom have yet to weigh in on this topic, I imagine > >>that adding refs to the GSEC RG work is a beginning, but not all that > >>needs to be said in the arch doc wrt/ to this comment. I think the > >>architecture doc has to describe, and the MSEC protocols have to define an > >>extensible mechanism(s) to encapsulate an opaque IGMP/MLD > >>authorization/authentication information payload within the {GSAKMP, GDOI, > >>whatever} key management protocol to each group member. With this > >>coupling, I think that the multicast session becomes far more secure. > >> > >>securing PIM or the multicast routing protocol du jour is another > >>interface to MSEC that needs to be mentioned in the arch doc, and perhaps > >>ultimately standardized... > >> > >>br, > >> George > >> > >>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > >> > >> > >>>Hi George, > >>> > >>>I think that you asked very intersting questions with respect to section > >> > >>2. > >> > >>>For your follwong questions: > >>> > >>>> 2 - how to assure the security of the IGMP, MLD, and the multicast > >>>>routing protocol(s) like PIM? > >>>> > >>> > >>>I think Group Membership (MLD, IGMP) security issues as well as multicast > >>>routing porotocols security issues are adressed (exclusively) in GSEC RG. > >> > >>For > >> > >>>the security issues in multicast routing protocols, it seems that there > is > >> > >>a > >> > >>>specific solution for each protocol. > >>> > >>>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > >>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as > >> > >>they > >> > >>>both propose extending GDOI to secure respectively IGMP and PIM-SM. > >>> > >>>However, I think that securing Group membership and multicast protocol > >>>protocols basing on GkmArch may not be a good thing as it makes the > >> > >>securty > >> > >>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . > Decoupling > >> > >>(at > >> > >>>least partially) GkMArch form the other two issues can ensure a multi- > >>>(independent)level security need. > >>> > >>> > >>>Mounir > >>> > >>>------------------------------------------------- > >>>Laboratoire Heudiasyc. UMR CNRS 6599 > >>>http://www.hds.utc.fr > >>> > >> > >> > >>_______________________________________________ > >>msec mailing list > >>msec@securemulticast.org > >>http://www.pairlist.net/mailman/listinfo/msec > >> > > > > > > > > > > > > ------------------------------------------------- > > Laboratoire Heudiasyc. UMR CNRS 6599 > > http://www.hds.utc.fr > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > ------------------------------------------------- Laboratoire Heudiasyc. UMR CNRS 6599 http://www.hds.utc.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 10:32:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12001 for ; Wed, 25 Jun 2003 10:32:20 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9CFAC53A4C; Wed, 25 Jun 2003 10:28:04 -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 0F7D75399B for ; Wed, 25 Jun 2003 10:27:14 -0400 (EDT) Received: (qmail 75553 invoked by uid 3269); 25 Jun 2003 14:27:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75550 invoked from network); 25 Jun 2003 14:27:13 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 25 Jun 2003 14:27:13 -0000 Received: (qmail 59664 invoked from network); 25 Jun 2003 14:27:13 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 25 Jun 2003 14:27:13 -0000 Received: (qmail 95038 invoked from network); 25 Jun 2003 14:25:14 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.172) by mail.nac.net with SMTP; 25 Jun 2003 14:25:14 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5PCMpb09632; Wed, 25 Jun 2003 08:22:51 -0400 From: George Gross To: Lakshminath Dondeti Cc: George Gross , , Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) In-Reply-To: <3EF9A772.1010807@nortelnetworks.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 25 Jun 2003 08:22:51 -0400 (EDT) Hi Lakshminath, inline below... br, George On Wed, 25 Jun 2003, Lakshminath Dondeti wrote: > There are several old expired drafts that discussed IGMP and PIM > security. Most of the folks in MSEC are aware of that work, yet decided > to not include protocol security in the charter. It may belong in a > separate WG IMO (e.g., IPSEC WG designs protocols for data protection > and RPSEC discusses routing protocol protection). > > You are welcome to bring any new ideas (or > revise old I-Ds and bring them for discussion) to the GSEC meeting; most > MSEC regulars will show up and the RG might decide how to proceed co-chair hat off>. regretably, I won't be in Vienna, ;o( no doubt it would be great place to visit please let me know what comes out of those discussions... > > I think the MSEC architecture I-D should proceed with its current scope. I am not asking that the MSEC architecture expand its scope; rather it should be _completed_ to describe the requirement to have a mechanism/hook through which this type of information can be included/tunneled in the MSEC protocols without defining its structure or semantics (i.e. it is opaque and to be defined). In the short term, this is likely to be as simple as reserving a TLV payload type for this future use. In the arch ID, the text should simply acknowledge that there is a set of entities, multicast routers, that must participate in the group membership's multicast data distribution and they do so securely under the direction of the GKCS. Unlike point to point IPSEC which is independent of the routing infrastructure, in MSEC there is a concept of group membership that has a direct relationship with the multicast routing tables. The text could be written in very general terms. The text should allow the flexibility of allowing either the multicast router or the group member securely initiating the group join/leave routing table update. > > regards, > Lakshminath > > George Gross wrote: > > Hi, > > With Mounir's permission, I'm forwarding an exchange we had wrt/ > > securing IGMP/MLD/PIM as part of MSEC... > > > > George > > > > ---------- Forwarded message ---------- > > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > > From: George Gross > > To: mounir.kellil@hds.utc.fr > > Cc: George Gross > > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > > > Hi Mounir, > > > > My goal with the section 2 questions was to tease out some of the > > unspoken assumptions that lurk in the architecture if one were to actually > > deploy MSEC. > > > > While Brian and Tom have yet to weigh in on this topic, I imagine > > that adding refs to the GSEC RG work is a beginning, but not all that > > needs to be said in the arch doc wrt/ to this comment. I think the > > architecture doc has to describe, and the MSEC protocols have to define an > > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > > authorization/authentication information payload within the {GSAKMP, GDOI, > > whatever} key management protocol to each group member. With this > > coupling, I think that the multicast session becomes far more secure. > > > > securing PIM or the multicast routing protocol du jour is another > > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > > ultimately standardized... > > > > br, > > George > > > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > > > >>Hi George, > >> > >>I think that you asked very intersting questions with respect to section 2. > >> > >>For your follwong questions: > >> > >>> 2 - how to assure the security of the IGMP, MLD, and the multicast > >>>routing protocol(s) like PIM? > >>> > >> > >>I think Group Membership (MLD, IGMP) security issues as well as multicast > >>routing porotocols security issues are adressed (exclusively) in GSEC RG. For > >>the security issues in multicast routing protocols, it seems that there is a > >>specific solution for each protocol. > >> > >>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > >>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > >>both propose extending GDOI to secure respectively IGMP and PIM-SM. > >> > >>However, I think that securing Group membership and multicast protocol > >>protocols basing on GkmArch may not be a good thing as it makes the securty > >>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at > >>least partially) GkMArch form the other two issues can ensure a multi- > >>(independent)level security need. > >> > >> > >>Mounir > >> > >>------------------------------------------------- > >>Laboratoire Heudiasyc. UMR CNRS 6599 > >>http://www.hds.utc.fr > >> > > > > > > > > _______________________________________________ > > 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 Jun 25 10:42:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12223 for ; Wed, 25 Jun 2003 10:42:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 507E9536E2; Wed, 25 Jun 2003 10:42:04 -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 23650536F4 for ; Wed, 25 Jun 2003 10:40:02 -0400 (EDT) Received: (qmail 77712 invoked by uid 3269); 25 Jun 2003 14:40:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77707 invoked from network); 25 Jun 2003 14:40:02 -0000 Received: from diabolo.hds.utc.fr (195.83.157.26) by klesh.pair.com with SMTP; 25 Jun 2003 14:40:02 -0000 Received: from localhost (diabolo.gi.utc [172.17.1.26]) by diabolo.hds.utc.fr (Postfix) with ESMTP id 253986E8B; Wed, 25 Jun 2003 16:44:03 +0200 (MEST) Received: from wwwgate111.motorola.com (wwwgate111.motorola.com [212.234.3.190]) by mail.hds.utc.fr (IMP) with HTTP for ; Wed, 25 Jun 2003 16:44:02 +0200 Message-ID: <1056552242.3ef9b53304f9e@mail.hds.utc.fr> From: mounir.kellil@hds.utc.fr To: mounir.kellil@hds.utc.fr Cc: Lakshminath Dondeti , George Gross , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: <1056548640.3ef9a720d474d@mail.hds.utc.fr> <3EF9A952.7080201@nortelnetworks.com> <1056549719.3ef9ab57afdaf@mail.hds.utc.fr> In-Reply-To: <1056549719.3ef9ab57afdaf@mail.hds.utc.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2 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, 25 Jun 2003 16:44:03 +0200 Content-Transfer-Encoding: 8bit George, Just a little remark, The concept of group membership in the view point of MsecArch is different from that of MLD/IGMP. I think this was explicitly mentioned in the last draft of GKMArch Mounir Selon mounir.kellil@hds.utc.fr: > Lakshminath > Yes, you are right to mention it. Multicast routers do not get TEK and KEKs ( > > they are not trusted in the viewpoint of data secrecy in particular) > > > > Mounir > Selon Lakshminath Dondeti : > > > Mounir, > > > > I assume you are talking about a separate GSA for routing protocol > > protection. > > > > Lakshminath > > > > mounir.kellil@hds.utc.fr wrote: > > > Hi all, > > > Hi George, > > > It may be an intersting idea. However, the GCKSs are not > MLD/IGMP-capable. > > > > > Group membership managment (MLD/IGMP) process is typically performed by > > > multicast routers. The drafts I mentioned in the previous e-mail suggest > > > > enxtending GSA to multicast routers...Why not.. > > > > > > Mounir > > > Selon George Gross : > > > > > > > > >>Hi, > > >> With Mounir's permission, I'm forwarding an exchange we had wrt/ > > >>securing IGMP/MLD/PIM as part of MSEC... > > >> > > >> George > > >> > > >>---------- Forwarded message ---------- > > >>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > > >>From: George Gross > > >>To: mounir.kellil@hds.utc.fr > > >>Cc: George Gross > > >>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > >> > > >>Hi Mounir, > > >> > > >> My goal with the section 2 questions was to tease out some of the > > >>unspoken assumptions that lurk in the architecture if one were to > actually > > >>deploy MSEC. > > >> > > >> While Brian and Tom have yet to weigh in on this topic, I imagine > > >>that adding refs to the GSEC RG work is a beginning, but not all that > > >>needs to be said in the arch doc wrt/ to this comment. I think the > > >>architecture doc has to describe, and the MSEC protocols have to define > an > > >>extensible mechanism(s) to encapsulate an opaque IGMP/MLD > > >>authorization/authentication information payload within the {GSAKMP, > GDOI, > > >>whatever} key management protocol to each group member. With this > > >>coupling, I think that the multicast session becomes far more secure. > > >> > > >>securing PIM or the multicast routing protocol du jour is another > > >>interface to MSEC that needs to be mentioned in the arch doc, and > perhaps > > >>ultimately standardized... > > >> > > >>br, > > >> George > > >> > > >>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > >> > > >> > > >>>Hi George, > > >>> > > >>>I think that you asked very intersting questions with respect to > section > > >> > > >>2. > > >> > > >>>For your follwong questions: > > >>> > > >>>> 2 - how to assure the security of the IGMP, MLD, and the multicast > > >>>>routing protocol(s) like PIM? > > >>>> > > >>> > > >>>I think Group Membership (MLD, IGMP) security issues as well as > multicast > > >>>routing porotocols security issues are adressed (exclusively) in GSEC > RG. > > >> > > >>For > > >> > > >>>the security issues in multicast routing protocols, it seems that there > > is > > >> > > >>a > > >> > > >>>specific solution for each protocol. > > >>> > > >>>May be next GKarch draft can mention the drafts > "draft-irtf-gsec-igmpv3- > > >>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as > > >> > > >>they > > >> > > >>>both propose extending GDOI to secure respectively IGMP and PIM-SM. > > >>> > > >>>However, I think that securing Group membership and multicast protocol > > >>>protocols basing on GkmArch may not be a good thing as it makes the > > >> > > >>securty > > >> > > >>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . > > Decoupling > > >> > > >>(at > > >> > > >>>least partially) GkMArch form the other two issues can ensure a multi- > > >>>(independent)level security need. > > >>> > > >>> > > >>>Mounir > > >>> > > >>>------------------------------------------------- > > >>>Laboratoire Heudiasyc. UMR CNRS 6599 > > >>>http://www.hds.utc.fr > > >>> > > >> > > >> > > >>_______________________________________________ > > >>msec mailing list > > >>msec@securemulticast.org > > >>http://www.pairlist.net/mailman/listinfo/msec > > >> > > > > > > > > > > > > > > > > > > ------------------------------------------------- > > > Laboratoire Heudiasyc. UMR CNRS 6599 > > > http://www.hds.utc.fr > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > > > ------------------------------------------------- > Laboratoire Heudiasyc. UMR CNRS 6599 > http://www.hds.utc.fr > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > ------------------------------------------------- Laboratoire Heudiasyc. UMR CNRS 6599 http://www.hds.utc.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 10:57:48 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13446 for ; Wed, 25 Jun 2003 10:57:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5794A53A49; Wed, 25 Jun 2003 10:57:16 -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 D9A7C53A1A for ; Wed, 25 Jun 2003 10:55:11 -0400 (EDT) Received: (qmail 80282 invoked by uid 3269); 25 Jun 2003 14:55:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80279 invoked from network); 25 Jun 2003 14:55:11 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 25 Jun 2003 14:55:11 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13227; Wed, 25 Jun 2003 10:54:38 -0400 (EDT) Message-Id: <200306251454.KAA13227@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-secure-feedback-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, 25 Jun 2003 10:54:38 -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 : Securing Feedback Messages: Secure and Scalable Many-to-one Communication Author(s) : L. Dondeti, T. Hardjono Filename : draft-ietf-msec-secure-feedback-00.txt Pages : 7 Date : 2003-6-24 Members in a secure group may need to communicate to the GCKS to Deregister from the group, for SA resynchronization, or to request retransmission of a Rekey message. A simple solution is to keep the registration SA around, but that comes at the expense of O(n) SA maintenance, and storage at the GCKS. Each member is also responsible for maintaining an extra SA. We propose an efficient method for mem- bers to securely send messages to the GCKS, using the Rekey SA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-secure-feedback-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-secure-feedback-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-secure-feedback-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-6-25103628.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-secure-feedback-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-secure-feedback-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-25103628.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 Jun 25 10:58:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13480 for ; Wed, 25 Jun 2003 10:58:13 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AE1FB53A58; Wed, 25 Jun 2003 10:57: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 7FCFF53A0F for ; Wed, 25 Jun 2003 10:55:50 -0400 (EDT) Received: (qmail 80414 invoked by uid 3269); 25 Jun 2003 14:55:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 80411 invoked from network); 25 Jun 2003 14:55:50 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 25 Jun 2003 14:55:50 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PEtlch004073; Wed, 25 Jun 2003 07:55:47 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.14 [10.26.128.14]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL0MDV5; Wed, 25 Jun 2003 07:55:47 -0700 Message-Id: <5.2.1.1.2.20030625104340.022a9098@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: housley@vigilsec.com, smb@research.att.com, canetti@watson.ibm.com, thardjono@yahoo.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] re-Charter of MSEC and milestones 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, 25 Jun 2003 10:55:37 -0400 [ps. Some housekeeping details for MSEC WG. (TH)] Folks, Below is the re-Charter of MSEC (which was discussed at the last IETF) and the revised milestones. The main text of the re-Charter is unmodified (as from the last IETF) and has been approved by the ADs. However, some of items on the milestone have been pushed further out, in order to provide authors with ample time. We are still waiting AD approval for these few modifications to the milestone, but they should be ok. Hint to authors: just because a draft's milestone has been pushed further out, it does not mean that it can/should not be completed earlier (and thus go to Last Call earlier). cheers, thomas ------ -------------------------------------------------------------------- MSEC CHARTER The purpose of the MSEC WG is to standardize protocols for securing group communication over internets, and in particular over the global Internet. Initial efforts will focus on scalable solutions for groups with a single source and a very large number of recipients. Additional emphasis will be put on groups where the data is transmitted via IP-layer multicast routing protocols (with or without guaranteed reliability). The developed standard will assume that each group has a single trusted entity (the Group Controller) that sets the security policy and controls the group membership. The standard will strive to provide at least the following basic security guarantees: + Only legitimate group members will have access to current group communication. This includes groups with highly dynamic membership. + Legitimate group members will be able to authenticate the source and contents of the group communication. This includes cases where group members do not trust each other. An additional goal of the standard will be to protect against denial-of-service attacks, whenever possible. Due to the large number of one-to-many multicast applications and the sometimes conflicting requirements these applications exhibit, it is believed that a single protocol will be unable to meet the requirements of all applications. Therefore, the WG will first specify a general Reference Framework that includes a number of functional building blocks. Each such building block will be instantiated by one or more protocols that will be interchangable. The Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. In addition, as a secondary goal the MSEC WG will also focus on distributed architectures for group key management and group policy management, where for scalability purposes multiple trusted entities (such as Key Distributors) are deployed in a distributed fashion. For this purpose, the Reference Framework will not only describe one-to-many multicast, but also many-to-many multicast. MSEC will generate at least the following documents, which could be considered as base documents: 1. An RFC describing the security requirements of multicast security and an RFC describing the MSEC Architecture. 2. An RFC describing the Group Key Management Architecture and an RFC describing Group Policy Management Architecture in MSEC. 3. Several RFCs describing specifications for protocols that implement source authentication, group key management and group policy management. As multicast security covers a broad range of issues, and therefore touches other Working Groups in the IETF, the MSEC WG will work closely with other security-related Working Groups (e.g. IPsec, IPSP), as well as other Working Groups which maybe considered a "consumer" of the technologies produced in the MSEC WG (e.g. AVT, MMUSIC) or which may have a multicast focus (e.g. PIM, RMT, IDRM, MAGMA). With this in mind, the MSEC WG is open to receiving new work items, whenever it is considered appropriate to be homed in the MSEC WG. Such drafts will be matured in conjunction with the MSEC base documents. GOALS AND MILESTONES DONE Working Group Last Call on GDOI Protocol. DONE Working Group Last Call on MIKEY Protocol. Sep 03 WG Last Call on Group Key Management Architecture draft. Sep 03 WG Last Call on MSEC Architecture draft. Sep 03 WG Last Call on DHHMAC for MIKEY. Sep 03 WG Last Call on Data Security Architecture draft. Sep 03 WG Last Call on GSAKMP protocol. Dec 03 WG Last Call on Security Requirements draft. Mar 04 WG Last Call on Group Security Policy Architecture draft Mar 04 WG Last Call on MESP (Multicast ESP) draft. Mar 04 WG Last call on MESP-TESLA draft. Jul 04 WG re-charter for other work items (or disband). -------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 11:06:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14170 for ; Wed, 25 Jun 2003 11:06:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7C87A535C6; Wed, 25 Jun 2003 11:06: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 BB21353541 for ; Wed, 25 Jun 2003 11:04:43 -0400 (EDT) Received: (qmail 81907 invoked by uid 3269); 25 Jun 2003 15:04:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81904 invoked from network); 25 Jun 2003 15:04:43 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 25 Jun 2003 15:04:43 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PF4fch005998; Wed, 25 Jun 2003 08:04:41 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.14 [10.26.128.14]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL0M1KB; Wed, 25 Jun 2003 08:04:41 -0700 Message-Id: <5.2.1.1.2.20030625105824.022a92f0@vhqpostal3.verisign.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: George Gross , From: Thomas Hardjono Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) In-Reply-To: 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, 25 Jun 2003 11:04:34 -0400 I think the model underlying the GCKS was that it *could* be the key server for routers (in PIM or IGMP), though it would use a different instance of the GSA. However, I do agree that an architecture-level document such as this could benefit from some explanation with respect to Group Membership Management security. Specifically on GDOI, if GDOI was used for router-entities (vs. hosts/humans), then it would be interesting to see if the Policy Token could carry the opaque "IGMP/MLD authorization/authentication information payload". In general, there is still this open problem (I think) about the best way to communicate authorization information to multicast-routers, both an the core and edge of the network. thomas ------ At 6/25/2003||07:18 AM, George Gross wrote: >Hi, > With Mounir's permission, I'm forwarding an exchange we had wrt/ >securing IGMP/MLD/PIM as part of MSEC... > > George > >---------- Forwarded message ---------- >Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) >From: George Gross >To: mounir.kellil@hds.utc.fr >Cc: George Gross >Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > >Hi Mounir, > > My goal with the section 2 questions was to tease out some of the >unspoken assumptions that lurk in the architecture if one were to actually >deploy MSEC. > > While Brian and Tom have yet to weigh in on this topic, I imagine >that adding refs to the GSEC RG work is a beginning, but not all that >needs to be said in the arch doc wrt/ to this comment. I think the >architecture doc has to describe, and the MSEC protocols have to define an >extensible mechanism(s) to encapsulate an opaque IGMP/MLD >authorization/authentication information payload within the {GSAKMP, GDOI, >whatever} key management protocol to each group member. With this >coupling, I think that the multicast session becomes far more secure. > >securing PIM or the multicast routing protocol du jour is another >interface to MSEC that needs to be mentioned in the arch doc, and perhaps >ultimately standardized... > >br, > George > >On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > Hi George, > > > > I think that you asked very intersting questions with respect to section 2. > > > > For your follwong questions: > > > 2 - how to assure the security of the IGMP, MLD, and the multicast > > > routing protocol(s) like PIM? > > > > > > > I think Group Membership (MLD, IGMP) security issues as well as multicast > > routing porotocols security issues are adressed (exclusively) in GSEC > RG. For > > the security issues in multicast routing protocols, it seems that there > is a > > specific solution for each protocol. > > > > May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > > security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > > both propose extending GDOI to secure respectively IGMP and PIM-SM. > > > > However, I think that securing Group membership and multicast protocol > > protocols basing on GkmArch may not be a good thing as it makes the securty > > solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . > Decoupling (at > > least partially) GkMArch form the other two issues can ensure a multi- > > (independent)level security need. > > > > > > Mounir > > > > ------------------------------------------------- > > Laboratoire Heudiasyc. UMR CNRS 6599 > > http://www.hds.utc.fr > > > > >_______________________________________________ >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 Jun 25 13:30:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22135 for ; Wed, 25 Jun 2003 13:29:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 38F8E536D0; Wed, 25 Jun 2003 13:28:46 -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 13452536D0 for ; Wed, 25 Jun 2003 13:27:52 -0400 (EDT) Received: (qmail 8426 invoked by uid 3269); 25 Jun 2003 17:27:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8423 invoked from network); 25 Jun 2003 17:27:50 -0000 Received: from sj-iport-1-in.cisco.com (HELO sj-iport-1.cisco.com) (171.71.176.70) by klesh.pair.com with SMTP; 25 Jun 2003 17:27:50 -0000 Received: from cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 25 Jun 2003 10:29:38 -0800 Received: from cscoamera13263.cisco.com (sjc-vpn1-776.cisco.com [10.21.99.8]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h5PHRlRK005754; Wed, 25 Jun 2003 10:27:47 -0700 (PDT) Message-Id: <5.1.1.5.2.20030625102646.08283a60@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Thomas Hardjono From: Mark Baugher Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) Cc: George Gross , In-Reply-To: <5.2.1.1.2.20030625105824.022a92f0@vhqpostal3.verisign.com> References: 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, 25 Jun 2003 10:27:46 -0700 hi Pardon my lateness in responding, I've been out of the office. At 11:04 AM 6/25/2003 -0400, Thomas Hardjono wrote: >I think the model underlying the GCKS was that it *could* be the key >server for routers (in PIM or IGMP), though it would use a different >instance of the GSA. > >However, I do agree that an architecture-level document such as this could >benefit from some explanation with respect to Group Membership Management >security. > >Specifically on GDOI, if GDOI was used for router-entities (vs. >hosts/humans), then it would be interesting to see if the Policy Token >could carry the opaque "IGMP/MLD authorization/authentication information >payload". There is no IGMP security work going on inside any IETF working group to my knowledge, is there? Mark >In general, there is still this open problem (I think) about the best way >to communicate authorization information to multicast-routers, both an the >core and edge of the network. > >thomas >------ > >At 6/25/2003||07:18 AM, George Gross wrote: >>Hi, >> With Mounir's permission, I'm forwarding an exchange we had wrt/ >>securing IGMP/MLD/PIM as part of MSEC... >> >> George >> >>---------- Forwarded message ---------- >>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) >>From: George Gross >>To: mounir.kellil@hds.utc.fr >>Cc: George Gross >>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 >> >>Hi Mounir, >> >> My goal with the section 2 questions was to tease out some of the >>unspoken assumptions that lurk in the architecture if one were to actually >>deploy MSEC. >> >> While Brian and Tom have yet to weigh in on this topic, I imagine >>that adding refs to the GSEC RG work is a beginning, but not all that >>needs to be said in the arch doc wrt/ to this comment. I think the >>architecture doc has to describe, and the MSEC protocols have to define an >>extensible mechanism(s) to encapsulate an opaque IGMP/MLD >>authorization/authentication information payload within the {GSAKMP, GDOI, >>whatever} key management protocol to each group member. With this >>coupling, I think that the multicast session becomes far more secure. >> >>securing PIM or the multicast routing protocol du jour is another >>interface to MSEC that needs to be mentioned in the arch doc, and perhaps >>ultimately standardized... >> >>br, >> George >> >>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: >> >> > Hi George, >> > >> > I think that you asked very intersting questions with respect to >> section 2. >> > >> > For your follwong questions: >> > > 2 - how to assure the security of the IGMP, MLD, and the multicast >> > > routing protocol(s) like PIM? >> > > >> > >> > I think Group Membership (MLD, IGMP) security issues as well as multicast >> > routing porotocols security issues are adressed (exclusively) in GSEC >> RG. For >> > the security issues in multicast routing protocols, it seems that >> there is a >> > specific solution for each protocol. >> > >> > May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- >> > security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as >> they >> > both propose extending GDOI to secure respectively IGMP and PIM-SM. >> > >> > However, I think that securing Group membership and multicast protocol >> > protocols basing on GkmArch may not be a good thing as it makes the >> securty >> > solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . >> Decoupling (at >> > least partially) GkMArch form the other two issues can ensure a multi- >> > (independent)level security need. >> > >> > >> > Mounir >> > >> > ------------------------------------------------- >> > Laboratoire Heudiasyc. UMR CNRS 6599 >> > http://www.hds.utc.fr >> > >> >> >>_______________________________________________ >>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 13:34:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22311 for ; Wed, 25 Jun 2003 13:34:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2AA6C53592; Wed, 25 Jun 2003 13:34: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 E2F4E5375A for ; Wed, 25 Jun 2003 13:32:04 -0400 (EDT) Received: (qmail 8939 invoked by uid 3269); 25 Jun 2003 17:32:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8934 invoked from network); 25 Jun 2003 17:32:04 -0000 Received: from sj-iport-3-in.cisco.com (HELO sj-iport-3.cisco.com) (171.71.176.72) by klesh.pair.com with SMTP; 25 Jun 2003 17:32:04 -0000 Received: from mbaugher.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 25 Jun 2003 10:35:18 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h5PHVuMO006533; Wed, 25 Jun 2003 10:31:59 -0700 (PDT) Received: from cscoamera13263.mbaugher.com (sjc-vpn1-776.cisco.com [10.21.99.8]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.3-GR) with ESMTP id AFL08358; Wed, 25 Jun 2003 10:31:55 -0700 (PDT) Message-Id: <5.1.1.5.2.20030625102814.082c8540@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) Cc: George Gross , msec@securemulticast.org, gsec@lists.tislabs.com In-Reply-To: <3EF9A772.1010807@nortelnetworks.com> References: 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, 25 Jun 2003 10:31:54 -0700 Lakshminath, At 09:45 AM 6/25/2003 -0400, Lakshminath Dondeti wrote: >There are several old expired drafts that discussed IGMP and PIM >security. Most of the folks in MSEC are aware of that work, yet decided >to not include protocol security in the charter. It may belong in a >separate WG IMO (e.g., IPSEC WG designs protocols for data protection and >RPSEC discusses routing protocol protection). > > You are welcome to bring any new ideas (or revise >old I-Ds and bring them for discussion) to the GSEC meeting; most MSEC >regulars will show up and the RG might decide how to proceed co-chair hat off>. Thanks. I should add that the issue of IGMP security has been raised at least twice and rejected as a work item by the IETF. That does not mean that it should not be considered, but it should be considered in GSEC (and informed by the previous discussions in GSEC and MAGMA), not in msec. Mark >I think the MSEC architecture I-D should proceed with its current scope. > >regards, >Lakshminath > >George Gross wrote: >>Hi, >> With Mounir's permission, I'm forwarding an exchange we had wrt/ >>securing IGMP/MLD/PIM as part of MSEC... >> George >>---------- Forwarded message ---------- >>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) >>From: George Gross >>To: mounir.kellil@hds.utc.fr >>Cc: George Gross >>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 >>Hi Mounir, >> My goal with the section 2 questions was to tease out some of the >>unspoken assumptions that lurk in the architecture if one were to actually >>deploy MSEC. >> While Brian and Tom have yet to weigh in on this topic, I imagine >>that adding refs to the GSEC RG work is a beginning, but not all that >>needs to be said in the arch doc wrt/ to this comment. I think the >>architecture doc has to describe, and the MSEC protocols have to define an >>extensible mechanism(s) to encapsulate an opaque IGMP/MLD >>authorization/authentication information payload within the {GSAKMP, GDOI, >>whatever} key management protocol to each group member. With this >>coupling, I think that the multicast session becomes far more secure. >>securing PIM or the multicast routing protocol du jour is another >>interface to MSEC that needs to be mentioned in the arch doc, and perhaps >>ultimately standardized... >>br, >> George >>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: >> >>>Hi George, >>> >>>I think that you asked very intersting questions with respect to section 2. >>> >>>For your follwong questions: >>> >>>> 2 - how to assure the security of the IGMP, MLD, and the multicast >>>>routing protocol(s) like PIM? >>> >>>I think Group Membership (MLD, IGMP) security issues as well as multicast >>>routing porotocols security issues are adressed (exclusively) in GSEC >>>RG. For >>>the security issues in multicast routing protocols, it seems that there is a >>>specific solution for each protocol. >>> >>>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- >>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they >>>both propose extending GDOI to secure respectively IGMP and PIM-SM. >>> >>>However, I think that securing Group membership and multicast protocol >>>protocols basing on GkmArch may not be a good thing as it makes the securty >>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . >>>Decoupling (at >>>least partially) GkMArch form the other two issues can ensure a multi- >>>(independent)level security need. >>> >>> >>>Mounir >>> >>>------------------------------------------------- >>>Laboratoire Heudiasyc. UMR CNRS 6599 >>>http://www.hds.utc.fr >> >>_______________________________________________ >>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jun 25 15:42:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28152 for ; Wed, 25 Jun 2003 15:42:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A1DDC5374A; Wed, 25 Jun 2003 15:12:17 -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 2AD145390F for ; Wed, 25 Jun 2003 15:11:04 -0400 (EDT) Received: (qmail 25410 invoked by uid 3269); 25 Jun 2003 19:11:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25407 invoked from network); 25 Jun 2003 19:11:03 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 25 Jun 2003 19:11:03 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h5PJB2ch005486; Wed, 25 Jun 2003 12:11:02 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.14 [10.26.128.14]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL0M4K8; Wed, 25 Jun 2003 12:11:02 -0700 Message-Id: <5.2.1.1.2.20030625150050.022a8d20@pop.mail.yahoo.com> X-Sender: thardjono@vhqpostal3.verisign.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Tentative MSEC Agenda + Call for agenda-items for IETF-57/Vienna 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, 25 Jun 2003 15:10:48 -0400 Folks, Here is the tentative Agenda, as of today, for the MSEC WG meeting at IETF-57 in Vienna in July 2003. Please email Ran/Thomas for corrections/additions. MSEC WG Agenda: --------------- - Review of WG status (T. Hardjono/R. Canetti) - GSAKMP Update (H. Harney) - MIKEY Update (F. Lindholm) - FMKE (S. Josset) - - Note that at the moment MSEC will meet on: MONDAY, July 14, 2003 1930-2200 Evening Sessions <-- bring your beer! Regards Thomas/Ran ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jun 26 18:30:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25540 for ; Thu, 26 Jun 2003 18:30:08 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4F3335365F; Thu, 26 Jun 2003 18:29: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 C0BF853631 for ; Thu, 26 Jun 2003 18:27:11 -0400 (EDT) Received: (qmail 52139 invoked by uid 3269); 26 Jun 2003 22:27:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52134 invoked from network); 26 Jun 2003 22:27:11 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 26 Jun 2003 22:27:11 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5QMQRq75294; Thu, 26 Jun 2003 18:26:27 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5QMR9880554; Thu, 26 Jun 2003 18:27:09 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) with ESMTP id SAA31510; Thu, 26 Jun 2003 18:27:08 -0400 From: canetti To: "Fredrik Lindholm (EAB)" Cc: msec@securemulticast.org, "'steffen.fries@siemens.com'" , housley@mail.binhost.com Subject: RE: [MSEC] DH mode in MIKEY In-Reply-To: <1F55F6582266314A85A55F6241509B6707EF4C69@Esealnt863.al.sw.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 26 Jun 2003 18:27:07 -0400 (EDT) Frederik, Steffan, Yes, I tend to agree with your reading of the situation. The reasoning below sounds convincing enough to me, and no other objection was made on the list. So, Frederik, I sounds like you should go ahead and submit a revised version that keeps the DH mode as optional, and clarifies its role and rationale. Thanks, Ran On Wed, 25 Jun 2003, Fredrik Lindholm (EAB) wrote: > > > To wrap up the discussion, from the mails we have seen, > it seems as there is support for the DH-mode. The fact that > H.323 uses MIKEY with DH in its specs gives also an extra > motivation to keep the DH-mode. We would therefore like to > suggest that our initial recommendation is followed, i.e. > to keep the DH mode, but > - better clarify the difference between the DH mode and the other > modes in the document, and > - make the DH mode optional to implement. > > Fredrik > > > > -----Original Message----- > > From: Steffen Fries [mailto:steffen.fries@siemens.com] > > Sent: den 18 juni 2003 15:38 > > To: msec@securemulticast.org; Ran Canetti > > Subject: Re: [MSEC] DH mode in MIKEY > > > > > > Hi Ran, > > > > I made some inline comments. > > > > (a)If we're already having an upstream message, then why not have a > > > three-message protocol that is based on nonces rather than > > timestamps? > > > (nonces are easier to deal with, and they are not susceptible to > > > "clock rewinding attacks"). > > In multimedia sytems there are protocols used that just feature > > a two message exchange between the sender and the receiver. > > Here MIKEY can be applied. One example is the usage of Fast > > Start in H.323. Here only the SETUP message and the appropriate > > response message are sent. A three way protocol would add an > > extra message to Fast Start, which is not desired. Furthermore, > > MIKEY has already been considered by the ITU-T for usage in > > H.323 in combination with SRTP in Draft H.235 Annex G. > > Again, in multimedia environments MIKEY is intended to be > > incorporated into (existing) VoIP protocols using only a full > > handshake rather than be used standalone. > > Moreover, DH is useful in this case to have e.g. PFS (see also > > point c below). > > > > (b) If we're already having a nonce-based > > > DH exchange, then why not use an off-the-shelf protocol such as > > > TLS/SSH/IKE etc., rather than doing things from scratch? (for > > > instance, if we use IKEv2, we get a four message exchange that is > > > already protectign against DOS, is relatively well analyzed, etc.) > > MIKEY is defined in a way that it may be integrated into > > existing protocols as a key management container. This is for > > instance the case for SIP and H.323. Because of the few > > messages needed by MIKEY for key management and security policy > > negotiation it integrates nicely in protocols only using a full > > handshake to establish a session between two parties. Other key > > management approaches like the ones you mentioned require more > > messages to be exchanged. > > > > (c) > > > MIKEY is directed at media and multimedia straming. Is PFS an > > > important concern for such scenarios? is it worth the extra > > > complexity? > > MIKEY may be used in VoIP environments to provide means for > > media data protection. PFS may not be necessary in every case > > but PFS is a security property, which cannot be achieved in any > > other way. If this is worth the extra effort may be a scenario > > specific question. Nvertheless, PFS provides additional > > security, with the ensurance that the security may not be > > compromised in a backwards way. > > You might compare this additional security functionality with > > somebody who encrypts files on his PC despite the fact that the > > PC is protected against unauthorized access. > > > > Steffen > > > > > > > > > > > > _______________________________________________ > > 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 Fri Jun 27 01:53:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06139 for ; Fri, 27 Jun 2003 01:52:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 51F1C53859; Fri, 27 Jun 2003 01:51: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 7295853793 for ; Fri, 27 Jun 2003 01:48:39 -0400 (EDT) Received: (qmail 52028 invoked by uid 3269); 27 Jun 2003 05:48:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52025 invoked from network); 27 Jun 2003 05:48:39 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 27 Jun 2003 05:48:39 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5R5loq127480; Fri, 27 Jun 2003 01:47:50 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5R5mX8101638; Fri, 27 Jun 2003 01:48:33 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) with ESMTP id BAA29682; Fri, 27 Jun 2003 01:48:32 -0400 From: canetti To: George Gross Cc: Lakshminath Dondeti , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 27 Jun 2003 01:48:31 -0400 (EDT) George, Sorry for jumping into the discussion late. I'm very glad you brought up this point. One of the main design principles of msec (coming from smug) is that the security we provide should be end-to-end, and furthermore should be as indepenent as possible from the underlying routing mechanism. Protecting the routing mechanism provides "only" protection against DoS (ie, it is not needed for guaranteeing secrecy or authenticity of thedata). While this is a very important concern, the feeling was that this should be dealt with on a different level than the basic msec goals of guaranteeing secrecy and authenticity of the data. So, in other words, the lack of discussion of the routing mechanisms and their protection is intentional. I'd suggest that some text clarifying this point be added to the document. (The point will be elaborated on in the upcoming requirements document; still it may be good to refer to it also in the architecture document.) Hope this clarifies. Ran On Wed, 25 Jun 2003, George Gross wrote: > Hi Lakshminath, > > inline below... > > br, > George > > On Wed, 25 Jun 2003, Lakshminath Dondeti wrote: > > > There are several old expired drafts that discussed IGMP and PIM > > security. Most of the folks in MSEC are aware of that work, yet decided > > to not include protocol security in the charter. It may belong in a > > separate WG IMO (e.g., IPSEC WG designs protocols for data protection > > and RPSEC discusses routing protocol protection). > > > > You are welcome to bring any new ideas (or > > revise old I-Ds and bring them for discussion) to the GSEC meeting; most > > MSEC regulars will show up and the RG might decide how to proceed > co-chair hat off>. > > regretably, I won't be in Vienna, ;o( no doubt it would be great place to > visit > > please let me know what comes out of those discussions... > > > > > I think the MSEC architecture I-D should proceed with its current scope. > > I am not asking that the MSEC architecture expand its scope; rather it > should be _completed_ to describe the requirement to have a mechanism/hook > through which this type of information can be included/tunneled in the > MSEC protocols without defining its structure or semantics (i.e. it is > opaque and to be defined). In the short term, this is likely to be as > simple as reserving a TLV payload type for this future use. > > In the arch ID, the text should simply acknowledge that there is a > set of entities, multicast routers, that must participate in the group > membership's multicast data distribution and they do so securely under the > direction of the GKCS. Unlike point to point IPSEC which is independent of > the routing infrastructure, in MSEC there is a concept of group membership > that has a direct relationship with the multicast routing tables. The text > could be written in very general terms. The text should allow the > flexibility of allowing either the multicast router or the group member > securely initiating the group join/leave routing table update. > > > > > > regards, > > Lakshminath > > > > George Gross wrote: > > > Hi, > > > With Mounir's permission, I'm forwarding an exchange we had wrt/ > > > securing IGMP/MLD/PIM as part of MSEC... > > > > > > George > > > > > > ---------- Forwarded message ---------- > > > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > > > From: George Gross > > > To: mounir.kellil@hds.utc.fr > > > Cc: George Gross > > > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > > > > > Hi Mounir, > > > > > > My goal with the section 2 questions was to tease out some of the > > > unspoken assumptions that lurk in the architecture if one were to actually > > > deploy MSEC. > > > > > > While Brian and Tom have yet to weigh in on this topic, I imagine > > > that adding refs to the GSEC RG work is a beginning, but not all that > > > needs to be said in the arch doc wrt/ to this comment. I think the > > > architecture doc has to describe, and the MSEC protocols have to define an > > > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > > > authorization/authentication information payload within the {GSAKMP, GDOI, > > > whatever} key management protocol to each group member. With this > > > coupling, I think that the multicast session becomes far more secure. > > > > > > securing PIM or the multicast routing protocol du jour is another > > > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > > > ultimately standardized... > > > > > > br, > > > George > > > > > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > > > > > > >>Hi George, > > >> > > >>I think that you asked very intersting questions with respect to section 2. > > >> > > >>For your follwong questions: > > >> > > >>> 2 - how to assure the security of the IGMP, MLD, and the multicast > > >>>routing protocol(s) like PIM? > > >>> > > >> > > >>I think Group Membership (MLD, IGMP) security issues as well as multicast > > >>routing porotocols security issues are adressed (exclusively) in GSEC RG. For > > >>the security issues in multicast routing protocols, it seems that there is a > > >>specific solution for each protocol. > > >> > > >>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > > >>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > > >>both propose extending GDOI to secure respectively IGMP and PIM-SM. > > >> > > >>However, I think that securing Group membership and multicast protocol > > >>protocols basing on GkmArch may not be a good thing as it makes the securty > > >>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at > > >>least partially) GkMArch form the other two issues can ensure a multi- > > >>(independent)level security need. > > >> > > >> > > >>Mounir > > >> > > >>------------------------------------------------- > > >>Laboratoire Heudiasyc. UMR CNRS 6599 > > >>http://www.hds.utc.fr > > >> > > > > > > > > > > > > _______________________________________________ > > > 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 > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 27 02:11:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA17722 for ; Fri, 27 Jun 2003 02:11:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 3742D536A7; Fri, 27 Jun 2003 02:09: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 4CAA3535B4 for ; Fri, 27 Jun 2003 02:03:35 -0400 (EDT) Received: (qmail 53908 invoked by uid 3269); 27 Jun 2003 06:03:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53905 invoked from network); 27 Jun 2003 06:03:31 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 27 Jun 2003 06:03:31 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5R62Vq146942; Fri, 27 Jun 2003 02:02:31 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5R63E8152908; Fri, 27 Jun 2003 02:03:14 -0400 Received: from localhost (canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) with ESMTP id CAA31254; Fri, 27 Jun 2003 02:03:13 -0400 From: canetti To: Brian Weis Cc: Laurence.Duquerroy@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org, Sebastien.Josset@space.alcatel.fr Subject: Re: [MSEC] =?iso-8859-1?Q?R=E9f=2E?= : Re: [MSEC] =?iso-8859-1?Q?R=E9f=2E?= : [MSEC] [Fwd: I-D ACTION: draft-duquer-fmke-00.txt] In-Reply-To: <3EF78294.C85731CC@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE 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, 27 Jun 2003 02:03:12 -0400 (EDT) Content-Transfer-Encoding: QUOTED-PRINTABLE Laurence, It would be *very* nice if we could avoid having yet another key=20 management protocol in addition to the ones we have (GDOI,MIKEY,GSAKMP). One way to try to do that is to get involved in the design of GDOIv2=20 (the new version of GDOI that will be based on IKEv2) and make sure that the end product satisfies your needs. This effort is under way, or at least so I understand; Brian Weis is a good contact. =20 Best, Ran On Mon, 23 Jun 2003, Brian Weis wrote: > Hi Laurence, >=20 > Thanks for explaining a little more about FMKE. I have some questions > below. >=20 > Laurence.Duquerroy@space.alcatel.fr wrote: > >=20 > > Hi, > >=20 > > Thank you for your interest. > >=20 > > FMKE can be seen as an extension of the group key management protocols = defined > > in MSEC (and more precisely of GDOI), which aims at providing an optim= ized > > scheme for satellite systems. Indeed, satellite based systems have spec= ific > > features which imply specific requirements : > > - bandwidth limitation, which implies overhead and signaling > > information volume minimization. > > - High transmission delays > > - A flat architecture with a high number of satellite termina= ls > > (senders and receivers) (for instance 60000 satellite terminals) > > - Need for reliable exchanges > >=20 > > Thus, FMKE is designed to limit the number of messages exchanged betwee= n group > > members and GCKS. For instance the FMKE phase 2 is less resource consum= ing than > > the GDOI ?group key push?, as it requires less messages for an equal nu= mber of > > SAs to transmit. > >=20 > > Moreover, on the contrary of the MSEC protocols, FMKE implements reliab= le key > > distribution exchanges (multicast and unicast). Besides the reliability > > mechanisms are optimized with regards to the bandwidth. >=20 >=20 > I'm wondering if the Phase 3 messages are distributed along with the > data traffic? For example, if a satellite terminal realizes that it has > missed a Phase 3 message, will it have time to request a retransmission > (by sending a NACK) before it needs to use the keys? If so, do you > expect that it will need to store them until the messages is > retransmitted? I don't know much about satellite terminals, so I was > wondering if they sufficient memory to store a lot of packets. >=20 > Also, I wonder if the GCKS would be able to handle very large numbers of > NACKs? For example, if there is a wide scale problem and a large group > of satellite terminals discovered that they had missed one or more Phase > 3 messages, they'd all send NACKs. If the GCKS has to spend a lot of > time interpreting NACKs, the system won't be very efficient. >=20 >=20 > > Another difference is that in the context of satellite systems, satelli= te > > terminals (=3D group members) have to protect traffic that they do not = generate > > themselves (they are generated by user equipment behind satellite termi= nals). So > > they know very few information about it. It is therefore more adapted t= hat they > > receive directly data SAs from the GCKS for the traffic they have to pr= otect, > > instead of requesting them. In FMKE they receive directly all the SAs t= hey are > > authorized to get access to, belonging to one or several groups, withou= t having > > to send a request. >=20 >=20 > The GDOI protocol allows a wide variety of usage models. In the > satellite setting, a GDOI group member can also directly receive data > SAs from the GCKS for the traffic they have to protect. A satellite > terminal would not need to know very much information -- only the > "group" identifier that it sends in the GDOI registration ("Phase 2") > protocol. In a satellite environment, I would expect the group > identifier to represent a set of channels, or some other collection of > services. This is used by the GDOI GCKS to check authorization of the > group member, to ensure that it actually does belong to the group. Once > authorized, the GCKS would return just the KEK for the group. The group > member would then listen for multicasted rekey messages (what you call > "Phase 3" messages) protected by that KEK. When it receives rekey > messages, it then becomes aware of what traffic it needs to protect. In > this manner, I believe that a GDOI group member can also directly > receive data SAs from the GCKS for the traffic they have to protect. >=20 > It occurs to me that the GCKS could choose to ignore the group ID if it > has a different method of deciding to which group the satellite terminal > belongs. The GCKS would send the appropriate KEK to the satellite > terminal just as before, and the process would be exactly the same. But > in this way the satellite terminal wouldn't have to know anything at all > beforehand, and the registration messages would be relatively > low-bandwidth messages. >=20 > I hope this explanation makes sense. If not, please let me know. >=20 > Thanks, > Brian >=20 >=20 > > Don't hesitate to contact us if you want further clarification or infor= mation > >=20 > > Best regards, > >=20 > > Laurence Duquerroy > >=20 > > Lakshminath Dondeti on 19/06/2003 14:48:1= 6 > >=20 > > Pour : Laurence.Duquerroy@space.alcatel.fr > > cc : msec@securemulticast.org > > Sebastien.Josset@space.alcatel.fr (ccc : Laurence Duquerroy/ALCAT= EL-SPACE) > > Objet : Re: [MSEC] R=E9f. : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke= -00.txt] > >=20 > > Hi, > >=20 > > Many thanks for your email. I was wondering about the motivation for > > yet another protocol for group key management. We have too many alread= y. > >=20 > > Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-classic= , > > GSAKMP and MIKEY, and the requirements that motivate the need for FMKE? > >=20 > > regards, > > Lakshminath > >=20 > > Laurence.Duquerroy@space.alcatel.fr wrote: > > > > > > Hi all, > > > > > > In the context of the SatIP6 IST project, Alcatel Space studies a mu= lticast > > > security scheme optimised to protect large multicast groups. Such a s= cheme is > > > designed for IP over Satellite, Wifi or DVB systems; it is a security= solution > > > for the satellite segment. An implementation over DVB-S/RCS is planne= d in the > > > SatIP6 demonstrator. > > > > > > We have started to write an Internet Draft detailing our key exchange= protocol > > > (called "Flat Multicast Key Exchange (FMKE)"), and we thought that it= could be > > > submitted to the MSEC Working Group (In fact, we thought it was too l= ate to > > > submit it for the next IETF meeting.) > > > > > > We would be ready to present it to the next MSEC Working Group meetin= g at > > IETF57 > > > in Vienna. > > > > > > This solution is designed to provide a security solution optimized fo= r > > satellite > > > systems. It is defined to be low ressource consuming in bandwidth, to= provide > > a > > > reliable key distribution, to be used in one-to-many and many-to-many > > scenarios, > > > and to be scalable in these scenarios... > > > > > > We hope that you will find interest in it, and thank you in advance f= or your > > > comments and questions. > > > > > > Our e-mail addresses are : > > > laurence.duquerroy@space.alcatel.fr > > > sebastien.josset@space.alcatel.fr > > > > > > > > > Best regards, > > > > > > Laurence Duquerroy > > > S=E9bastien Josset > > > > > > > > > > > > > > > > > > Lakshminath Dondeti on 18/06/2003 20:11= :54 > > > > > > Pour : msec@securemulticast.org > > > cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) > > > Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= --- > > > > > > > > > Hi all, > > > > > > I forwarded this new I-D announcement from IETF-Announce to a small > > > group of MSEC regulars and no one was aware of it. Assuming that oth= ers > > > haven't seen it either, here it is on Thomas's request. > > > > > > Could the authors (if they see this) please send their email addresse= s > > > to the group (not in I-D)? I have some questions on the I-D. Thanks. > > > > > > regards, > > > Lakshminath > > > > > > -------- Original Message -------- > > > Subject: I-D ACTION:draft-duquer-fmke-00.txt > > > Date: Wed, 18 Jun 2003 07:52:40 -0400 > > > From: Internet-Drafts@ietf.org > > > Reply-To: Internet-Drafts@ietf.org > > > To: IETF-Announce: ; > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : The Flat Multicast Key Exchange protocol > > > Author(s) : L. Duquerroy, S. Josset > > > Filename : draft-duquer-fmke-00.txt > > > Pages : 30 > > > Date : 2003-6-17 > > > > > > This document presents a new group key management protocol called > > > FMKE (Flat Multicast Key Exchange). Its objective is to manage > > > securely group Security Associations (SA), i.e. establish and update > > > SAs in Group members. These members can be identified for instance > > > by a multicast IP address, a virtual LAN identifier, or a generic > > > group label. This protocol is based on a centralized management, > > > achieved by the GCKS (Group Controller and Key Server). It is > > > destined to be used by Data Security protocols which wish to secure > > > group communications. For the time being, the considered Data > > > Security protocol is a multicast version of the IPSEC ESP protocol, > > > but other Data Security protocols could be envisaged. The FMKE > > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > > > Encryption Keys). The FMKE protocol is optimized for very large > > > groups with direct connections such as satellite systems, or wireless > > > systems such as WIFI. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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 me= ssage. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with the u= sername > > > "anonymous" and a password of your e-mail address. After logging in, > > > type "cd internet-drafts" and then > > > "get draft-duquer-fmke-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-duquer-fmke-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 rea= ders > > > exhibit different behavior, especially when dealing with > > > "multipart" MIME messages (i.e. documents which have been split > > > up into multiple messages), so check your local documentation on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the > > > Internet-Draft. > > > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > > > > > > ALCATEL SPACE > > > RT/ST > > > Research Department / Advanced Telecom Satellite Systems > > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > > E-Mail : laurence.duquerroy@space.alcatel.fr > >=20 > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >=20 > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > >=20 > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec >=20 > --=20 > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com >=20 > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec >=20 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 27 10:01:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28074 for ; Fri, 27 Jun 2003 10:01:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B332D536FD; Fri, 27 Jun 2003 10:00:25 -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 54CF7535BC for ; Fri, 27 Jun 2003 09:58:37 -0400 (EDT) Received: (qmail 40959 invoked by uid 3269); 27 Jun 2003 13:58:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40956 invoked from network); 27 Jun 2003 13:58:36 -0000 Received: from gc-na5.alcatel.fr (HELO smail3.alcatel.fr) (64.208.49.5) by klesh.pair.com with SMTP; 27 Jun 2003 13:58:36 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5RDvvvn000995; Fri, 27 Jun 2003 15:58:18 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D52.004C7177 ; Fri, 27 Jun 2003 15:54:57 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: Brian Weis Cc: Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org Message-ID: Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline X-Virus-Scanned: by amavisd-new Subject: [MSEC] =?iso-8859-1?Q?R=E9f._:_Re:_[MSEC]_R=E9f._:_Re:_[MSEC]_?= R =?iso-8859-1?Q?=E9f._:_[MSEC]_[Fwd:_I-D_ACTION:_draft-duquer-fmke-?= =?iso-8859-1?Q?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: Fri, 27 Jun 2003 15:56:22 +0200 Hi Brian, Thanks a lot for your very interesting comments. You will find below the answers to your questions. Best regards, Laurence - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >Hi Laurence, >Thanks for explaining a little more about FMKE. I have some questions >below. >Laurence.Duquerroy@space.alcatel.fr wrote: >> >> Hi, >> >> Thank you for your interest. >> >> FMKE can be seen as an extension of the group key management protocols defined >> in MSEC (and more precisely of GDOI), which aims at providing an optimized >> scheme for satellite systems. Indeed, satellite based systems have specific >> features which imply specific requirements : >> - bandwidth limitation, which implies overhead and signaling >> information volume minimization. >> - High transmission delays >> - A flat architecture with a high number of satellite terminals >> (senders and receivers) (for instance 60000 satellite terminals) >> - Need for reliable exchanges >> >> Thus, FMKE is designed to limit the number of messages exchanged between group >> members and GCKS. For instance the FMKE phase 2 is less resource consuming than >> the GDOI ?group key push?, as it requires less messages for an equal number of >> SAs to transmit. >> >> Moreover, on the contrary of the MSEC protocols, FMKE implements reliable key >> distribution exchanges (multicast and unicast). Besides the reliability >> mechanisms are optimized with regards to the bandwidth. >I'm wondering if the Phase 3 messages are distributed along with the >data traffic? For example, if a satellite terminal realizes that it has >missed a Phase 3 message, will it have time to request a retransmission >(by sending a NACK) before it needs to use the keys? If so, do you >expect that it will need to store them until the messages is >retransmitted? I don't know much about satellite terminals, so I was >wondering if they sufficient memory to store a lot of packets. Phase 3 messages are indeed distributed along with the data traffic. In fact, when a new key has to be transmitted, the GCKS has to plan to send a phase 3 message containing the key sufficiently early so that several retransmissions can be realised (requested by group members) before group members need the key (for instance before the old key expires). Thanks to these retransmissions, all satellite terminals should receive the key in time. >Also, I wonder if the GCKS would be able to handle very large numbers of >NACKs? For example, if there is a wide scale problem and a large group >of satellite terminals discovered that they had missed one or more Phase >3 messages, they'd all send NACKs. If the GCKS has to spend a lot of >time interpreting NACKs, the system won't be very efficient. The GCKS should not handle very large numbers of NACKs. Indeed, when a satellite terminal determines that one message is missing, it waits a pre-determined time before sending its NACK. The waiting time varies for each satellite terminal, and follows a pre-calculated distribution, based on link budgets and physical satellite terminal location, optimised to avoid massive NACK emission in case of packet loss, and congestion at GCKS side : thus few satellite terminals will be authorised to send a NACK at the beginning, and it is expected that these messages will be sufficient so that all satellite terminals receive the GCKS messages. We avoid therefore that all Group members which have not received a message send a NACK message. The figure below represents a possible distribution of the waiting time. | % of group members 100| . . . | . | . | . | . | . | . | . . . . 0|________________________________________________ waiting time >> Another difference is that in the context of satellite systems, satellite >> terminals (= group members) have to protect traffic that they do not generate >> themselves (they are generated by user equipment behind satellite terminals). So >> they know very few information about it. It is therefore more adapted that they >> receive directly data SAs from the GCKS for the traffic they have to protect, >> instead of requesting them. In FMKE they receive directly all the SAs they are >> authorized to get access to, belonging to one or several groups, without having >> to send a request. >The GDOI protocol allows a wide variety of usage models. In the >satellite setting, a GDOI group member can also directly receive data >SAs from the GCKS for the traffic they have to protect. A satellite >terminal would not need to know very much information -- only the >"group" identifier that it sends in the GDOI registration ("Phase 2") >protocol. In a satellite environment, I would expect the group >identifier to represent a set of channels, or some other collection of >services. This is used by the GDOI GCKS to check authorization of the >group member, to ensure that it actually does belong to the group. Once >authorized, the GCKS would return just the KEK for the group. The group >member would then listen for multicasted rekey messages (what you call >"Phase 3" messages) protected by that KEK. When it receives rekey >messages, it then becomes aware of what traffic it needs to protect. In >this manner, I believe that a GDOI group member can also directly >receive data SAs from the GCKS for the traffic they have to protect. >It occurs to me that the GCKS could choose to ignore the group ID if it >has a different method of deciding to which group the satellite terminal >belongs. The GCKS would send the appropriate KEK to the satellite >terminal just as before, and the process would be exactly the same. But >in this way the satellite terminal wouldn't have to know anything at all >beforehand, and the registration messages would be relatively >low-bandwidth messages. >I hope this explanation makes sense. If not, please let me know. >Thanks, >Brian I agree with your explanation. Your scenario indeed implies low bandwidth messages, and as explained in your mail, the knowledge of the Group ID by satellite terminal is no more an issue. In fact FMKE can be seen as a use case (and as an extension) of GDOI, particularly for this scenario where FMKE provides similar message exchanges. The only main difference between FMKE and GDOI is the reliability of the FMKE Phase 3 ( = the GDOI "Group key push"). The scenario where the satellite terminal is entirely configured in unicast , that is to say where it directly receives all Data-SAs and Re-key SA during the FMKE phase 2, could also be requested for some cases (the phase 3 would then be used only to update the security configurations of the satellite terminals). In that case FMKE is more optimized with regards to the bandwidth consumption. >> Don't hesitate to contact us if you want further clarification or information >> Best regards, >> >> Laurence Duquerroy > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : The Flat Multicast Key Exchange protocol > > Author(s) : L. Duquerroy, S. Josset > > Filename : draft-duquer-fmke-00.txt > > Pages : 30 > > Date : 2003-6-17 > > > > This document presents a new group key management protocol called > > FMKE (Flat Multicast Key Exchange). Its objective is to manage > > securely group Security Associations (SA), i.e. establish and update > > SAs in Group members. These members can be identified for instance > > by a multicast IP address, a virtual LAN identifier, or a generic > > group label. This protocol is based on a centralized management, > > achieved by the GCKS (Group Controller and Key Server). It is > > destined to be used by Data Security protocols which wish to secure > > group communications. For the time being, the considered Data > > Security protocol is a multicast version of the IPSEC ESP protocol, > > but other Data Security protocols could be envisaged. The FMKE > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > > Encryption Keys). The FMKE protocol is optimized for very large > > groups with direct connections such as satellite systems, or wireless > > systems such as WIFI. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. > > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > ALCATEL SPACE > RT/ST > Research Department / Advanced Telecom Satellite Systems > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > E-Mail : laurence.duquerroy@space.alcatel.fr > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 27 10:06:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28154 for ; Fri, 27 Jun 2003 10:06:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5E2965365C; Fri, 27 Jun 2003 10:06:04 -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 59BEA5362F for ; Fri, 27 Jun 2003 10:04:13 -0400 (EDT) Received: (qmail 41815 invoked by uid 3269); 27 Jun 2003 14:04:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 41812 invoked from network); 27 Jun 2003 14:04:12 -0000 Received: from colt-na7.alcatel.fr (HELO smail3.alcatel.fr) (62.23.212.7) by klesh.pair.com with SMTP; 27 Jun 2003 14:04:12 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h5RE3svh005047; Fri, 27 Jun 2003 16:03:55 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D52.004CFFA7 ; Fri, 27 Jun 2003 16:01:01 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: canetti Cc: Sebastien.Josset@space.alcatel.fr, Brian Weis , Lakshminath Dondeti , msec@securemulticast.org Message-ID: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable X-Virus-Scanned: by amavisd-new Subject: [MSEC] =?iso-8859-1?Q?R=E9f._:_Re:_[MSEC]_R=E9f._:_Re:_[MSEC]_R=E9f._:_[?= =?iso-8859-1?Q?MSEC]_[Fwd:_I-D_ACTION:_draft-duquer-fmke-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: Fri, 27 Jun 2003 16:00:57 +0200 Content-Transfer-Encoding: quoted-printable Hi Ran, Indeed it could be a good idea. As explained in my last mail to the MSE= C mailing list, FMKE could be considered as a use case or an extension of GDOI , = with some additional features. We are going to precisely identify these additional features, and maybe= we can discuss this at the next MSEC meeting . Best regards, Laurence Duquerroy canetti on 27/06/2003 08:03:12 Pour : Brian Weis cc : Laurence.Duquerroy@space.alcatel.fr Lakshminath Dondeti msec@securemulticast.org Sebastien.Josset@space.alcatel.fr (ccc : Laurence Duquerroy/ALCAT= EL-SPACE) Objet : Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : [MSEC] [Fwd: I-D ACT= ION: draft-duquer-fmke-00.txt] = Laurence, It would be *very* nice if we could avoid having yet another key management protocol in addition to the ones we have (GDOI,MIKEY,GSAKMP)= . One way to try to do that is to get involved in the design of GDOIv2 (the new version of GDOI that will be based on IKEv2) and make sure tha= t the end product satisfies your needs. This effort is under way, or at least so I understand; Brian Weis is a good contact. Best, Ran On Mon, 23 Jun 2003, Brian Weis wrote: > Hi Laurence, > > Thanks for explaining a little more about FMKE. I have some questions= > below. > > Laurence.Duquerroy@space.alcatel.fr wrote: > > > > Hi, > > > > Thank you for your interest. > > > > FMKE can be seen as an extension of the group key management protoc= ols defined > > in MSEC (and more precisely of GDOI), which aims at providing an o= ptimized > > scheme for satellite systems. Indeed, satellite based systems have = specific > > features which imply specific requirements : > > - bandwidth limitation, which implies overhead and signal= ing > > information volume minimization. > > - High transmission delays > > - A flat architecture with a high number of satellite ter= minals > > (senders and receivers) (for instance 60000 satellite terminals) > > - Need for reliable exchanges > > > > Thus, FMKE is designed to limit the number of messages exchanged be= tween group > > members and GCKS. For instance the FMKE phase 2 is less resource co= nsuming than > > the GDOI ?group key push?, as it requires less messages for an equa= l number of > > SAs to transmit. > > > > Moreover, on the contrary of the MSEC protocols, FMKE implements re= liable key > > distribution exchanges (multicast and unicast). Besides the reliabi= lity > > mechanisms are optimized with regards to the bandwidth. > > > I'm wondering if the Phase 3 messages are distributed along with the > data traffic? For example, if a satellite terminal realizes that it h= as > missed a Phase 3 message, will it have time to request a retransmissi= on > (by sending a NACK) before it needs to use the keys? If so, do you > expect that it will need to store them until the messages is > retransmitted? I don't know much about satellite terminals, so I was > wondering if they sufficient memory to store a lot of packets. > > Also, I wonder if the GCKS would be able to handle very large numbers= of > NACKs? For example, if there is a wide scale problem and a large grou= p > of satellite terminals discovered that they had missed one or more Ph= ase > 3 messages, they'd all send NACKs. If the GCKS has to spend a lot of > time interpreting NACKs, the system won't be very efficient. > > > > Another difference is that in the context of satellite systems, sat= ellite > > terminals (=3D group members) have to protect traffic that they do = not generate > > themselves (they are generated by user equipment behind satellite terminals). So > > they know very few information about it. It is therefore more adapt= ed that they > > receive directly data SAs from the GCKS for the traffic they have t= o protect, > > instead of requesting them. In FMKE they receive directly all the S= As they are > > authorized to get access to, belonging to one or several groups, wi= thout having > > to send a request. > > > The GDOI protocol allows a wide variety of usage models. In the > satellite setting, a GDOI group member can also directly receive data= > SAs from the GCKS for the traffic they have to protect. A satellite > terminal would not need to know very much information -- only the > "group" identifier that it sends in the GDOI registration ("Phase 2")= > protocol. In a satellite environment, I would expect the group > identifier to represent a set of channels, or some other collection o= f > services. This is used by the GDOI GCKS to check authorization of the= > group member, to ensure that it actually does belong to the group. On= ce > authorized, the GCKS would return just the KEK for the group. The gro= up > member would then listen for multicasted rekey messages (what you cal= l > "Phase 3" messages) protected by that KEK. When it receives rekey > messages, it then becomes aware of what traffic it needs to protect. = In > this manner, I believe that a GDOI group member can also directly > receive data SAs from the GCKS for the traffic they have to protect. > > It occurs to me that the GCKS could choose to ignore the group ID if = it > has a different method of deciding to which group the satellite termi= nal > belongs. The GCKS would send the appropriate KEK to the satellite > terminal just as before, and the process would be exactly the same. B= ut > in this way the satellite terminal wouldn't have to know anything at = all > beforehand, and the registration messages would be relatively > low-bandwidth messages. > > I hope this explanation makes sense. If not, please let me know. > > Thanks, > Brian > > > > Don't hesitate to contact us if you want further clarification or information > > > > Best regards, > > > > Laurence Duquerroy > > > > Lakshminath Dondeti on 19/06/2003 14:= 48:16 > > > > Pour : Laurence.Duquerroy@space.alcatel.fr > > cc : msec@securemulticast.org > > Sebastien.Josset@space.alcatel.fr (ccc : Laurence Duquerroy/ALCATEL-SPACE) > > Objet : Re: [MSEC] R=E9f. : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > Hi, > > > > Many thanks for your email. I was wondering about the motivation f= or > > yet another protocol for group key management. We have too many al= ready. > > > > Could you explain how FMKE is different from GDOI, GKMP, GSAKMP-cla= ssic, > > GSAKMP and MIKEY, and the requirements that motivate the need for F= MKE? > > > > regards, > > Lakshminath > > > > Laurence.Duquerroy@space.alcatel.fr wrote: > > > > > > Hi all, > > > > > > In the context of the SatIP6 IST project, Alcatel Space studies = a multicast > > > security scheme optimised to protect large multicast groups. Such= a scheme is > > > designed for IP over Satellite, Wifi or DVB systems; it is a secu= rity solution > > > for the satellite segment. An implementation over DVB-S/RCS is pl= anned in the > > > SatIP6 demonstrator. > > > > > > We have started to write an Internet Draft detailing our key exch= ange protocol > > > (called "Flat Multicast Key Exchange (FMKE)"), and we thought tha= t it could be > > > submitted to the MSEC Working Group (In fact, we thought it was t= oo late to > > > submit it for the next IETF meeting.) > > > > > > We would be ready to present it to the next MSEC Working Group me= eting at > > IETF57 > > > in Vienna. > > > > > > This solution is designed to provide a security solution optimize= d for > > satellite > > > systems. It is defined to be low ressource consuming in bandwidth= , to provide > > a > > > reliable key distribution, to be used in one-to-many and many-to-= many > > scenarios, > > > and to be scalable in these scenarios... > > > > > > We hope that you will find interest in it, and thank you in advan= ce for your > > > comments and questions. > > > > > > Our e-mail addresses are : > > > laurence.duquerroy@space.alcatel.fr > > > sebastien.josset@space.alcatel.fr > > > > > > > > > Best regards, > > > > > > Laurence Duquerroy > > > S=E9bastien Josset > > > > > > > > > > > > > > > > > > Lakshminath Dondeti on 18/06/2003 2= 0:11:54 > > > > > > Pour : msec@securemulticast.org > > > cc : (ccc : Laurence Duquerroy/ALCATEL-SPACE) > > > Objet : [MSEC] [Fwd: I-D ACTION:draft-duquer-fmke-00.txt] > > > > > > > > > > > > > > > > > > -----------------------------------------------------------------= ------- > > > > > > > > > Hi all, > > > > > > I forwarded this new I-D announcement from IETF-Announce to a sma= ll > > > group of MSEC regulars and no one was aware of it. Assuming that= others > > > haven't seen it either, here it is on Thomas's request. > > > > > > Could the authors (if they see this) please send their email addr= esses > > > to the group (not in I-D)? I have some questions on the I-D. Tha= nks. > > > > > > regards, > > > Lakshminath > > > > > > -------- Original Message -------- > > > Subject: I-D ACTION:draft-duquer-fmke-00.txt > > > Date: Wed, 18 Jun 2003 07:52:40 -0400 > > > From: Internet-Drafts@ietf.org > > > Reply-To: Internet-Drafts@ietf.org > > > To: IETF-Announce: ; > > > > > > A New Internet-Draft is available from the on-line Internet-Draft= s > > > directories. > > > > > > > > > Title : The Flat Multicast Key Exchange protocol > > > Author(s) : L. Duquerroy, S. Josset > > > Filename : draft-duquer-fmke-00.txt > > > Pages : 30 > > > Date : 2003-6-17 > > > > > > This document presents a new group key management protocol called= > > > FMKE (Flat Multicast Key Exchange). Its objective is to manage > > > securely group Security Associations (SA), i.e. establish and upd= ate > > > SAs in Group members. These members can be identified for instanc= e > > > by a multicast IP address, a virtual LAN identifier, or a generic= > > > group label. This protocol is based on a centralized management, > > > achieved by the GCKS (Group Controller and Key Server). It is > > > destined to be used by Data Security protocols which wish to secu= re > > > group communications. For the time being, the considered Data > > > Security protocol is a multicast version of the IPSEC ESP protoco= l, > > > but other Data Security protocols could be envisaged. The FMKE > > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > > > Encryption Keys). The FMKE protocol is optimized for very large > > > groups with direct connections such as satellite systems, or wire= less > > > systems such as WIFI. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-00.txt > > > > > > To remove yourself from the IETF Announcement list, send a messag= e to > > > ietf-announce-request with the word unsubscribe in the body of th= e message. > > > > > > Internet-Drafts are also available by anonymous FTP. Login with t= he username > > > "anonymous" and a password of your e-mail address. After logging = in, > > > type "cd internet-drafts" and then > > > "get draft-duquer-fmke-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-duquer-fmke-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 sp= lit > > > up into multiple messages), so check your local documentatio= n on > > > how to manipulate these messages. > > > > > > > > > Below is the data which will enable a MIME compliant mail reader > > > implementation to automatically retrieve the ASCII version of the= > > > Internet-Draft. > > > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > > > > > > ALCATEL SPACE > > > RT/ST > > > Research Department / Advanced Telecom Satellite Systems > > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > -- > Brian Weis > Strategic Cryptographic Development, ITD, Cisco Systems > Telephone: +1 408 526 4796 > Email: bew@cisco.com > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > ALCATEL SPACE RT/ST Research Department / Advanced Telecom Satellite Systems Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 E-Mail : laurence.duquerroy@space.alcatel.fr = _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jun 27 11:16:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03644 for ; Fri, 27 Jun 2003 11:16:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B824B538DB; Fri, 27 Jun 2003 11:14: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 71BF453751 for ; Fri, 27 Jun 2003 11:13:44 -0400 (EDT) Received: (qmail 53571 invoked by uid 3269); 27 Jun 2003 15:13:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 53562 invoked from network); 27 Jun 2003 15:13:44 -0000 Received: from sj-core-3.cisco.com (171.68.223.137) by klesh.pair.com with SMTP; 27 Jun 2003 15:13:44 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-693.cisco.com [10.21.66.181]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h5RFDZve022304; Fri, 27 Jun 2003 08:13:35 -0700 (PDT) Message-Id: <5.1.1.5.2.20030627080316.08871020@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Laurence.Duquerroy@space.alcatel.fr From: Mark Baugher Cc: Brian Weis , Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] =?iso-8859-1?Q?Re:_[MSEC]_R=E9f._:_Re:_[MSEC]_R=E9f._:_Re:_[?= MSEC] R =?iso-8859-1?Q?_=E9f._:_[MSEC]_[Fwd:_I-D_ACTION:_?= draft-duquer-fmke- 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: Fri, 27 Jun 2003 08:13:35 -0700 Laurence, We discussed putting reliability mechanisms into GDOI about three years ago. The decision of the secure multicast research group (SMuG) at that time was to use the mechanisms that are being developed by another group, the reliable multicast group, rather than develop our own. MSEC has also taken this approach. So, before we incorporate reliable multicast into an MSEC key management protocol, we need to revisit this decision and discuss the pro's and con's of having an ACK or NAK mechanism built into key management versus using a separate layer. The advantage that I see of using a separate layer is what one generally gets from design modularity: We can choose among the best mechanisms for a particular application. As new reliable multicast protocols and algorithms are developed, these can be used by the key management protocol without the need to change the specification of the key management protocol. Now, what are the advantages to mixing up reliable multicast with key establishment? Finally, I don't see any difference between your Phase 3 and the MSEC Rekey protocol (called "groupkey push" in GDOI). Are there significant differences? I think the similarities in the protocols favor Ran's suggestion of including this work with the GDOIv2 effort that MSEC is likely to begin. Mark At 03:56 PM 6/27/2003 +0200, Laurence.Duquerroy@space.alcatel.fr wrote: >Hi Brian, > >Thanks a lot for your very interesting comments. You will find below the >answers >to your questions. > >Best regards, > >Laurence >- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - > > > >Hi Laurence, > > >Thanks for explaining a little more about FMKE. I have some questions > >below. > > >Laurence.Duquerroy@space.alcatel.fr wrote: > >> > >> Hi, > >> > >> Thank you for your interest. > >> > >> FMKE can be seen as an extension of the group key management protocols >defined > >> in MSEC (and more precisely of GDOI), which aims at providing an > optimized > >> scheme for satellite systems. Indeed, satellite based systems have > specific > >> features which imply specific requirements : > >> - bandwidth limitation, which implies overhead and signaling > >> information volume minimization. > >> - High transmission delays > >> - A flat architecture with a high number of satellite terminals > >> (senders and receivers) (for instance 60000 satellite terminals) > >> - Need for reliable exchanges > >> > >> Thus, FMKE is designed to limit the number of messages exchanged between >group > >> members and GCKS. For instance the FMKE phase 2 is less resource consuming >than > >> the GDOI ?group key push?, as it requires less messages for an equal > number >of > >> SAs to transmit. > >> > >> Moreover, on the contrary of the MSEC protocols, FMKE implements > reliable key > >> distribution exchanges (multicast and unicast). Besides the reliability > >> mechanisms are optimized with regards to the bandwidth. > > > >I'm wondering if the Phase 3 messages are distributed along with the > >data traffic? For example, if a satellite terminal realizes that it has > >missed a Phase 3 message, will it have time to request a retransmission > >(by sending a NACK) before it needs to use the keys? If so, do you > >expect that it will need to store them until the messages is > >retransmitted? I don't know much about satellite terminals, so I was > >wondering if they sufficient memory to store a lot of packets. > > > >Phase 3 messages are indeed distributed along with the data traffic. >In fact, when a new key has to be transmitted, the GCKS has to plan to send a >phase 3 message containing the key sufficiently early so that several >retransmissions can be realised (requested by group members) before group >members need the key (for instance before the old key expires). Thanks to >these >retransmissions, all satellite terminals should receive the key in time. > > > >Also, I wonder if the GCKS would be able to handle very large numbers of > >NACKs? For example, if there is a wide scale problem and a large group > >of satellite terminals discovered that they had missed one or more Phase > >3 messages, they'd all send NACKs. If the GCKS has to spend a lot of > >time interpreting NACKs, the system won't be very efficient. > > > >The GCKS should not handle very large numbers of NACKs. Indeed, when a >satellite >terminal determines that one message is missing, it waits a pre-determined >time >before sending its NACK. The waiting time varies for each satellite terminal, >and follows a pre-calculated distribution, based on link budgets and physical >satellite terminal location, optimised to avoid massive NACK emission in >case of >packet loss, and congestion at GCKS side : thus few satellite terminals >will be >authorised to send a NACK at the beginning, and it is expected that these >messages will be sufficient so that all satellite terminals receive the GCKS >messages. We avoid therefore that all Group members which have not received a >message send a NACK message. >The figure below represents a possible distribution of the waiting time. > > | % of group members > 100| . . . > | . > | . > | . > | . > | . > | . > | . . . . > 0|________________________________________________ > waiting time > > > > > > > >> Another difference is that in the context of satellite systems, satellite > >> terminals (= group members) have to protect traffic that they do not > generate > >> themselves (they are generated by user equipment behind satellite > terminals). >So > >> they know very few information about it. It is therefore more adapted that >they > >> receive directly data SAs from the GCKS for the traffic they have to > protect, > >> instead of requesting them. In FMKE they receive directly all the SAs they >are > >> authorized to get access to, belonging to one or several groups, without >having > >> to send a request. > > > >The GDOI protocol allows a wide variety of usage models. In the > >satellite setting, a GDOI group member can also directly receive data > >SAs from the GCKS for the traffic they have to protect. A satellite > >terminal would not need to know very much information -- only the > >"group" identifier that it sends in the GDOI registration ("Phase 2") > >protocol. In a satellite environment, I would expect the group > >identifier to represent a set of channels, or some other collection of > >services. This is used by the GDOI GCKS to check authorization of the > >group member, to ensure that it actually does belong to the group. Once > >authorized, the GCKS would return just the KEK for the group. The group > >member would then listen for multicasted rekey messages (what you call > >"Phase 3" messages) protected by that KEK. When it receives rekey > >messages, it then becomes aware of what traffic it needs to protect. In > >this manner, I believe that a GDOI group member can also directly > >receive data SAs from the GCKS for the traffic they have to protect. > > >It occurs to me that the GCKS could choose to ignore the group ID if it > >has a different method of deciding to which group the satellite terminal > >belongs. The GCKS would send the appropriate KEK to the satellite > >terminal just as before, and the process would be exactly the same. But > >in this way the satellite terminal wouldn't have to know anything at all > >beforehand, and the registration messages would be relatively > >low-bandwidth messages. > > >I hope this explanation makes sense. If not, please let me know. > > >Thanks, > >Brian > >I agree with your explanation. Your scenario indeed implies low bandwidth >messages, and as explained in your mail, the knowledge of the Group ID by >satellite terminal is no more an issue. In fact FMKE can be seen as a use case >(and as an extension) of GDOI, particularly for this scenario where FMKE >provides similar message exchanges. The only main difference between FMKE and >GDOI is the reliability of the FMKE Phase 3 ( = the GDOI "Group key push"). >The scenario where the satellite terminal is entirely configured in unicast , >that is to say where it directly receives all Data-SAs and Re-key SA >during the >FMKE phase 2, could also be requested for some cases (the phase 3 would >then be >used only to update the security configurations of the satellite terminals). >In that case FMKE is more optimized with regards to the bandwidth consumption. > > > > >> Don't hesitate to contact us if you want further clarification or > information > >> Best regards, > >> > >> Laurence Duquerroy > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : The Flat Multicast Key Exchange protocol > > > Author(s) : L. Duquerroy, S. Josset > > > Filename : draft-duquer-fmke-00.txt > > > Pages : 30 > > > Date : 2003-6-17 > > > > > > This document presents a new group key management protocol called > > > FMKE (Flat Multicast Key Exchange). Its objective is to manage > > > securely group Security Associations (SA), i.e. establish and update > > > SAs in Group members. These members can be identified for instance > > > by a multicast IP address, a virtual LAN identifier, or a generic > > > group label. This protocol is based on a centralized management, > > > achieved by the GCKS (Group Controller and Key Server). It is > > > destined to be used by Data Security protocols which wish to secure > > > group communications. For the time being, the considered Data > > > Security protocol is a multicast version of the IPSEC ESP protocol, > > > but other Data Security protocols could be envisaged. The FMKE > > > protocol exchanges TEKs (Traffic Encryption Keys) and KEKs (Key > > > Encryption Keys). The FMKE protocol is optimized for very large > > > groups with direct connections such as satellite systems, or wireless > > > systems such as WIFI. > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-duquer-fmke-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-duquer-fmke-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-duquer-fmke-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. > > > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > > > > > > > > > > ALCATEL SPACE > > > RT/ST > > > Research Department / Advanced Telecom Satellite Systems > > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > ALCATEL SPACE > > RT/ST > > Research Department / Advanced Telecom Satellite Systems > > Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 > > E-Mail : laurence.duquerroy@space.alcatel.fr > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > >-- >Brian Weis >Strategic Cryptographic Development, ITD, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com > > > >ALCATEL SPACE >RT/ST >Research Department / Advanced Telecom Satellite Systems >Tel : 33 (0)5-34-35-63-06 / Fax : 33 (0)5-34-35-55-60 >E-Mail : laurence.duquerroy@space.alcatel.fr > > > >_______________________________________________ >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 Fri Jun 27 16:55:43 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20366 for ; Fri, 27 Jun 2003 16:55:42 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 637065364A; Fri, 27 Jun 2003 16:25: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 C7DE853910 for ; Fri, 27 Jun 2003 16:23:28 -0400 (EDT) Received: (qmail 8916 invoked by uid 3269); 27 Jun 2003 20:23:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 8913 invoked from network); 27 Jun 2003 20:23:28 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 27 Jun 2003 20:23:28 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5RKNK006045; Fri, 27 Jun 2003 16:23:21 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAFSLL24; Fri, 27 Jun 2003 16:23:20 -0400 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 MGTS3W9L; Fri, 27 Jun 2003 16:23:18 -0400 Message-ID: <3EFCA89D.1090005@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: George Gross Cc: canetti , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: 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: Fri, 27 Jun 2003 16:27:09 -0400 Content-Transfer-Encoding: 7bit Good questions. We sort of went away from them, didn't we? I will take up some. In my mind, stuff like NAT, IPv6 should be part of protocol support, and I believe GDOI has that benefit as it is based on IKEv1 (I am not supposed to say that; so let that be a secret between, oh the hundreds of people who follow this group :-) ), which has some NAT support and IPv6 support. I believe GSAKMP would work with IPv6, not sure about NATs though! I haven't thought about group AH though. In my mind the reliable transport issue has been fluid. It ranges from 'assume underlying reliable transport' to 'use rudimentary FEC.' We have some discussion on that topic in GKMarch (I think :-) ). Some GKMAs have builtin support for reliability and I think that's the best way to go. We may have to add some support for sending feedback though (hence the I-D on feedback protection, admittedly it needs some work). Multicast SAs use transport mode IPsec AFAIK. With 2401bis there should not be any ambiguity in lookups anyway. I would defer certs to Thomas, MSEC's resident certs expert (Verisign ;-)) cheers, Lakshminath George Gross wrote: > Hi Ran, > > inline below.... > > br, > George > > On Fri, 27 Jun 2003, canetti wrote: > > >>George, >> >>Sorry for jumping into the discussion late. >> >>I'm very glad you brought up this point. >>One of the main design principles of msec (coming from smug) is that the >>security we provide should be end-to-end, and furthermore should be as >>indepenent as possible from the underlying routing mechanism. > > > I have not yet dredged the SMUG archives, so I don't have the benefits of > that history. I have a hunch that in the future those readers approaching > secure multicast for the first time would pick up this document to get > oriented once it becomes available as an informational RFC. With that in > mind, I notice that this is not the first time that I heard the SMUG work > show up as the unspoken folklore of this working group ;o) IMHO, this > document could serve well as a summary of those design decisions rather > than be silent on them. For example, I noticed on the current FMKE thread > that SMUG was cited for the decision not to have ack/nack in the secure > multicast rekey protocol(s). > > > > >>Protecting the routing mechanism provides "only" protection against DoS >>(ie, it is not needed for guaranteeing secrecy or authenticity of thedata). >>While this is a very important concern, the feeling was that this should >>be dealt with on a different level than the basic msec goals of >>guaranteeing secrecy and authenticity of the data. >> >>So, in other words, the lack of discussion of the routing mechanisms and >>their protection is intentional. >> >>I'd suggest that some text clarifying this point be added to the document. >>(The point will be elaborated on in the upcoming requirements document; >>still it may be good to refer to it also in the architecture document.) >> > > > This is good. I think that text will help this document alot to the extent > that it identifies secure multicast routing as an architectural interface > or protocol that shows up in a comprehensive secure multicast > architecture, and it interacts with the secure multicast membership > controller. The text should also indicate it is out of scope of the > current working group but could be an area for future standardization. > > My original e-mail that triggered this thread had a laundry list > of 8 items, of which the multicast routing security was only one (albeit > perhaps the most interesting). I'll re-issue that list here, sans #2 which > we've largely answered. Comments from the list and the authors would be > appreciated.... > > 1 - For data traffic multicast, what error recovery procedure(s) are > required to detect and avoid network congestion? acks/nacks? what about > Explicit Congestion Notification (ECN)? > > 3 - Should/do the group key management protocols assume an underlying > reliable transport service? > > 4 - while this may be implied, you should indicate this architecture is > independent of IP-v4 or IP-v6 and that the secure multicast protocols MUST > operate with both. > > 5 - how does the secure multicast architecture interact with NAT? is it > required to work across multiple NAT boundaries? (e.g. does group AH > break?) > > 6 - does the architecture assume a single common PKI that spans all > members of the group or shared secrets (which does not scale)? > > 7 - does the architecture have a particular profile on X.509 > certificates that would assure interoperability (witness the discussions > on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid > that swamp?) > > 8 - what happens when the secure multicast protocols traverses an > IPSEC gateway? It seems that implicitly you are defining transport mode > multicast data security associations? or could they be in tunnel mode? if > the latter, then mention that and how it works. > > > > > Hope this clarifies. > >>Ran >> >> >>On Wed, 25 Jun 2003, George Gross wrote: >> >> >>>Hi Lakshminath, >>> >>> inline below... >>> >>>br, >>> George >>> >>>On Wed, 25 Jun 2003, Lakshminath Dondeti wrote: >>> >>> >>>>There are several old expired drafts that discussed IGMP and PIM >>>>security. Most of the folks in MSEC are aware of that work, yet decided >>>>to not include protocol security in the charter. It may belong in a >>>>separate WG IMO (e.g., IPSEC WG designs protocols for data protection >>>>and RPSEC discusses routing protocol protection). >>>> >>>> You are welcome to bring any new ideas (or >>>>revise old I-Ds and bring them for discussion) to the GSEC meeting; most >>>>MSEC regulars will show up and the RG might decide how to proceed >>>co-chair hat off>. >>> >>>regretably, I won't be in Vienna, ;o( no doubt it would be great place to >>>visit >>> >>>please let me know what comes out of those discussions... >>> >>> >>>>I think the MSEC architecture I-D should proceed with its current scope. >>> >>>I am not asking that the MSEC architecture expand its scope; rather it >>>should be _completed_ to describe the requirement to have a mechanism/hook >>>through which this type of information can be included/tunneled in the >>>MSEC protocols without defining its structure or semantics (i.e. it is >>>opaque and to be defined). In the short term, this is likely to be as >>>simple as reserving a TLV payload type for this future use. >>> >>> In the arch ID, the text should simply acknowledge that there is a >>>set of entities, multicast routers, that must participate in the group >>>membership's multicast data distribution and they do so securely under the >>>direction of the GKCS. Unlike point to point IPSEC which is independent of >>>the routing infrastructure, in MSEC there is a concept of group membership >>>that has a direct relationship with the multicast routing tables. The text >>>could be written in very general terms. The text should allow the >>>flexibility of allowing either the multicast router or the group member >>>securely initiating the group join/leave routing table update. >>> >>> >>> >>>>regards, >>>>Lakshminath >>>> >>>>George Gross wrote: >>>> >>>>>Hi, >>>>> With Mounir's permission, I'm forwarding an exchange we had wrt/ >>>>>securing IGMP/MLD/PIM as part of MSEC... >>>>> >>>>> George >>>>> >>>>>---------- Forwarded message ---------- >>>>>Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) >>>>>From: George Gross >>>>>To: mounir.kellil@hds.utc.fr >>>>>Cc: George Gross >>>>>Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 >>>>> >>>>>Hi Mounir, >>>>> >>>>> My goal with the section 2 questions was to tease out some of the >>>>>unspoken assumptions that lurk in the architecture if one were to actually >>>>>deploy MSEC. >>>>> >>>>> While Brian and Tom have yet to weigh in on this topic, I imagine >>>>>that adding refs to the GSEC RG work is a beginning, but not all that >>>>>needs to be said in the arch doc wrt/ to this comment. I think the >>>>>architecture doc has to describe, and the MSEC protocols have to define an >>>>>extensible mechanism(s) to encapsulate an opaque IGMP/MLD >>>>>authorization/authentication information payload within the {GSAKMP, GDOI, >>>>>whatever} key management protocol to each group member. With this >>>>>coupling, I think that the multicast session becomes far more secure. >>>>> >>>>>securing PIM or the multicast routing protocol du jour is another >>>>>interface to MSEC that needs to be mentioned in the arch doc, and perhaps >>>>>ultimately standardized... >>>>> >>>>>br, >>>>> George >>>>> >>>>>On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: >>>>> >>>>> >>>>> >>>>>>Hi George, >>>>>> >>>>>>I think that you asked very intersting questions with respect to section 2. >>>>>> >>>>>>For your follwong questions: >>>>>> >>>>>> >>>>>>> 2 - how to assure the security of the IGMP, MLD, and the multicast >>>>>>>routing protocol(s) like PIM? >>>>>>> >>>>>> >>>>>>I think Group Membership (MLD, IGMP) security issues as well as multicast >>>>>>routing porotocols security issues are adressed (exclusively) in GSEC RG. For >>>>>>the security issues in multicast routing protocols, it seems that there is a >>>>>>specific solution for each protocol. >>>>>> >>>>>>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- >>>>>>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they >>>>>>both propose extending GDOI to secure respectively IGMP and PIM-SM. >>>>>> >>>>>>However, I think that securing Group membership and multicast protocol >>>>>>protocols basing on GkmArch may not be a good thing as it makes the securty >>>>>>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at >>>>>>least partially) GkMArch form the other two issues can ensure a multi- >>>>>>(independent)level security need. >>>>>> >>>>>> >>>>>>Mounir >>>>>> >>>>>>------------------------------------------------- >>>>>>Laboratoire Heudiasyc. UMR CNRS 6599 >>>>>>http://www.hds.utc.fr >>>>>> >>>>> >>>>> >>>>> >>>>>_______________________________________________ >>>>>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 >>> >> >> >>_______________________________________________ >>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 Fri Jun 27 19:20:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25589 for ; Fri, 27 Jun 2003 19:19:59 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CB2AD53875; Fri, 27 Jun 2003 19:18: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 EFDC453549 for ; Fri, 27 Jun 2003 19:17:30 -0400 (EDT) Received: (qmail 37423 invoked by uid 3269); 27 Jun 2003 23:17:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37420 invoked from network); 27 Jun 2003 23:17:30 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 27 Jun 2003 23:17:30 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h5RNGoO0022038; Fri, 27 Jun 2003 16:16:51 -0700 (PDT) Message-ID: <3EFC6E59.A417DB1C@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: George Gross Cc: canetti , msec@securemulticast.org, gsec@lists.tislabs.com Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 27 Jun 2003 09:18:33 -0700 Content-Transfer-Encoding: 7bit George, I wasn't ignoring your original email ... it just took awhile to get to it, and then I enjoyed the resulting discussion. :-) Thanks to everyone for all the good discussion on these points. George Gross wrote: > > Hi Ran, > > inline below.... > > br, > George > > On Fri, 27 Jun 2003, canetti wrote: > > > > > George, > > > > Sorry for jumping into the discussion late. > > > > I'm very glad you brought up this point. > > One of the main design principles of msec (coming from smug) is that the > > security we provide should be end-to-end, and furthermore should be as > > indepenent as possible from the underlying routing mechanism. I believe the following statements summarize the discussion, and are what I propose adding to the architecture document. (This is not actual text, just the logical statements.) 1. A secure application layer group using MSEC protocols does not require the multicast routing infrastructure to participate in the group. However, that application layer group has no guarantee that the the multicast routing infrastructure will route the packets appropriately. 2. The multicast routing infrastructure comprises a group that could use MSEC protocols to protect its own traffic. However, this would be independent of any secure application layer groups. I would also add: 3. The bridge between the application layer group and the multicast routing is the network level "join" to a group. Joins to a multicast group are not the same as "joining" a secure group. I.e., the former involves sending an IGMP or MLD messages to the closest multicast-aware router, and the latter means registering with a GCKS to obtain the policy and keys necessary to participate in the group. (This is already mentioned in section 5.2.4, but probably needs more emphasis.) > I have not yet dredged the SMUG archives, so I don't have the benefits of > that history. I have a hunch that in the future those readers approaching > secure multicast for the first time would pick up this document to get > oriented once it becomes available as an informational RFC. With that in > mind, I notice that this is not the first time that I heard the SMUG work > show up as the unspoken folklore of this working group ;o) IMHO, this > document could serve well as a summary of those design decisions rather > than be silent on them. For example, I noticed on the current FMKE thread > that SMUG was cited for the decision not to have ack/nack in the secure > multicast rekey protocol(s). George makes a very valuable observation that we aren't writing everything that we're assuming. I appreciate him pointing out where we are doing this, because we do need to document them. > > > > Protecting the routing mechanism provides "only" protection against DoS > > (ie, it is not needed for guaranteeing secrecy or authenticity of thedata). > > While this is a very important concern, the feeling was that this should > > be dealt with on a different level than the basic msec goals of > > guaranteeing secrecy and authenticity of the data. > > > > So, in other words, the lack of discussion of the routing mechanisms and > > their protection is intentional. > > > > I'd suggest that some text clarifying this point be added to the document. > > (The point will be elaborated on in the upcoming requirements document; > > still it may be good to refer to it also in the architecture document.) > > > > This is good. I think that text will help this document alot to the extent > that it identifies secure multicast routing as an architectural interface > or protocol that shows up in a comprehensive secure multicast > architecture, and it interacts with the secure multicast membership > controller. The text should also indicate it is out of scope of the > current working group but could be an area for future standardization. > > My original e-mail that triggered this thread had a laundry list > of 8 items, of which the multicast routing security was only one (albeit > perhaps the most interesting). I'll re-issue that list here, sans #2 which > we've largely answered. Comments from the list and the authors would be > appreciated.... > > 1 - For data traffic multicast, what error recovery procedure(s) are > required to detect and avoid network congestion? acks/nacks? what about > Explicit Congestion Notification (ECN)? I think this should be addressed in the to-be-released Data Transforms Architecture specification. > 3 - Should/do the group key management protocols assume an underlying > reliable transport service? I believe the answer is that they should not assume they are available, because most multicast routing mechanisms deployed today are not reliable. My preference is for this issue to be dealt with in the GKMA document, which further refines the group key management architecture. > 4 - while this may be implied, you should indicate this architecture is > independent of IP-v4 or IP-v6 and that the secure multicast protocols MUST > operate with both. Good point. > 5 - how does the secure multicast architecture interact with NAT? is it > required to work across multiple NAT boundaries? (e.g. does group AH > break?) My usual answer to the problem of multicast and NAT is that it isn't a problem, because the multicast routing mechanisms (e.g., PIM) rely heavily on the source address. I'll try to find a place to say this in the architecture document. > 6 - does the architecture assume a single common PKI that spans all > members of the group or shared secrets (which does not scale)? The answer is "no", and I'll add a discussion of this in section 5.2.4. > 7 - does the architecture have a particular profile on X.509 > certificates that would assure interoperability (witness the discussions > on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid > that swamp?) I don't think it is a goal of the architecture document to ensure interoperability. It's describing the architecture at a much higher level. > 8 - what happens when the secure multicast protocols traverses an > IPSEC gateway? It seems that implicitly you are defining transport mode > multicast data security associations? or could they be in tunnel mode? if > the latter, then mention that and how it works. George, could you elaborate on the problem? I don't think it should matter if a multicast protocol gets encapsulated in a transport mode or tunnel mode IPsec header. If it gets sent through an IPsec gateway later, and that IPsec gateway policy says to encrypt it, then it would just end up with two IPsec headers, right? Thanks, Brian > > Hope this clarifies. > > > > Ran > > > > > > On Wed, 25 Jun 2003, George Gross wrote: > > > > > Hi Lakshminath, > > > > > > inline below... > > > > > > br, > > > George > > > > > > On Wed, 25 Jun 2003, Lakshminath Dondeti wrote: > > > > > > > There are several old expired drafts that discussed IGMP and PIM > > > > security. Most of the folks in MSEC are aware of that work, yet decided > > > > to not include protocol security in the charter. It may belong in a > > > > separate WG IMO (e.g., IPSEC WG designs protocols for data protection > > > > and RPSEC discusses routing protocol protection). > > > > > > > > You are welcome to bring any new ideas (or > > > > revise old I-Ds and bring them for discussion) to the GSEC meeting; most > > > > MSEC regulars will show up and the RG might decide how to proceed > > > co-chair hat off>. > > > > > > regretably, I won't be in Vienna, ;o( no doubt it would be great place to > > > visit > > > > > > please let me know what comes out of those discussions... > > > > > > > > > > > I think the MSEC architecture I-D should proceed with its current scope. > > > > > > I am not asking that the MSEC architecture expand its scope; rather it > > > should be _completed_ to describe the requirement to have a mechanism/hook > > > through which this type of information can be included/tunneled in the > > > MSEC protocols without defining its structure or semantics (i.e. it is > > > opaque and to be defined). In the short term, this is likely to be as > > > simple as reserving a TLV payload type for this future use. > > > > > > In the arch ID, the text should simply acknowledge that there is a > > > set of entities, multicast routers, that must participate in the group > > > membership's multicast data distribution and they do so securely under the > > > direction of the GKCS. Unlike point to point IPSEC which is independent of > > > the routing infrastructure, in MSEC there is a concept of group membership > > > that has a direct relationship with the multicast routing tables. The text > > > could be written in very general terms. The text should allow the > > > flexibility of allowing either the multicast router or the group member > > > securely initiating the group join/leave routing table update. > > > > > > > > > > > > > > regards, > > > > Lakshminath > > > > > > > > George Gross wrote: > > > > > Hi, > > > > > With Mounir's permission, I'm forwarding an exchange we had wrt/ > > > > > securing IGMP/MLD/PIM as part of MSEC... > > > > > > > > > > George > > > > > > > > > > ---------- Forwarded message ---------- > > > > > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > > > > > From: George Gross > > > > > To: mounir.kellil@hds.utc.fr > > > > > Cc: George Gross > > > > > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > > > > > > > > > Hi Mounir, > > > > > > > > > > My goal with the section 2 questions was to tease out some of the > > > > > unspoken assumptions that lurk in the architecture if one were to actually > > > > > deploy MSEC. > > > > > > > > > > While Brian and Tom have yet to weigh in on this topic, I imagine > > > > > that adding refs to the GSEC RG work is a beginning, but not all that > > > > > needs to be said in the arch doc wrt/ to this comment. I think the > > > > > architecture doc has to describe, and the MSEC protocols have to define an > > > > > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > > > > > authorization/authentication information payload within the {GSAKMP, GDOI, > > > > > whatever} key management protocol to each group member. With this > > > > > coupling, I think that the multicast session becomes far more secure. > > > > > > > > > > securing PIM or the multicast routing protocol du jour is another > > > > > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > > > > > ultimately standardized... > > > > > > > > > > br, > > > > > George > > > > > > > > > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > > > > > > > > > > > > >>Hi George, > > > > >> > > > > >>I think that you asked very intersting questions with respect to section 2. > > > > >> > > > > >>For your follwong questions: > > > > >> > > > > >>> 2 - how to assure the security of the IGMP, MLD, and the multicast > > > > >>>routing protocol(s) like PIM? > > > > >>> > > > > >> > > > > >>I think Group Membership (MLD, IGMP) security issues as well as multicast > > > > >>routing porotocols security issues are adressed (exclusively) in GSEC RG. For > > > > >>the security issues in multicast routing protocols, it seems that there is a > > > > >>specific solution for each protocol. > > > > >> > > > > >>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > > > > >>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > > > > >>both propose extending GDOI to secure respectively IGMP and PIM-SM. > > > > >> > > > > >>However, I think that securing Group membership and multicast protocol > > > > >>protocols basing on GkmArch may not be a good thing as it makes the securty > > > > >>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at > > > > >>least partially) GkMArch form the other two issues can ensure a multi- > > > > >>(independent)level security need. > > > > >> > > > > >> > > > > >>Mounir > > > > >> > > > > >>------------------------------------------------- > > > > >>Laboratoire Heudiasyc. UMR CNRS 6599 > > > > >>http://www.hds.utc.fr > > > > >> > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 00:42:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17431 for ; Mon, 30 Jun 2003 00:42:39 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F027C538A1; Mon, 30 Jun 2003 00:18: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 1BD10538A1 for ; Mon, 30 Jun 2003 00:16:22 -0400 (EDT) Received: (qmail 24506 invoked by uid 3269); 30 Jun 2003 04:16:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24502 invoked from network); 30 Jun 2003 04:16:22 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 30 Jun 2003 04:16:22 -0000 Received: (qmail 60430 invoked from network); 30 Jun 2003 04:16:21 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 30 Jun 2003 04:16:21 -0000 Received: (qmail 16853 invoked from network); 30 Jun 2003 04:16:20 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.182) by mail.nac.net with SMTP; 30 Jun 2003 04:16:20 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h5U2DP618593; Sun, 29 Jun 2003 22:13:25 -0400 From: George Gross To: Brian Weis Cc: George Gross , canetti , , Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) In-Reply-To: <3EFC6E59.A417DB1C@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 29 Jun 2003 22:13:25 -0400 (EDT) Hi Brian, appreciate your rev'ing the arch doc to address my comments/Qs... a few clarifications inline below. br, George On Fri, 27 Jun 2003, Brian Weis wrote: > George, I wasn't ignoring your original email ... it just took awhile to > get to it, and then I enjoyed the resulting discussion. :-) Thanks to > everyone for all the good discussion on these points. > > My original e-mail that triggered this thread had a laundry list > > of 8 items, of which the multicast routing security was only one (albeit > > perhaps the most interesting). I'll re-issue that list here, sans #2 which > > we've largely answered. Comments from the list and the authors would be > > appreciated.... > > > > 1 - For data traffic multicast, what error recovery procedure(s) are > > required to detect and avoid network congestion? acks/nacks? what about > > Explicit Congestion Notification (ECN)? > > I think this should be addressed in the to-be-released Data Transforms > Architecture specification. okay, but I would like to suggest adding a pointer in that direction within your arch document. > > > 3 - Should/do the group key management protocols assume an underlying > > reliable transport service? > > I believe the answer is that they should not assume they are available, > because most multicast routing mechanisms deployed today are not > reliable. > > My preference is for this issue to be dealt with in the GKMA document, > which further refines the group key management architecture. hmmm... the GKMA document will kind of describe how the cows have already left the barn ;o) i.e. GSAKMP is in last call, same story with MIKEY, and GDOI-v1 is in the RFC queue. I would have thought one would write the GKMA before the protocol specs?!? Anyway, I agree with the view you expresed above, that multicast routing is not reliable. Therefore, a MSEC protocol spec must either explicitly define its own error procedures or point to a reliable multicast data transport protocol that is mandatory to implement. At this point, are GSAKMP and MIKEY cast in stone? Maybe GDOIv2 is the only possible candidate for such a solution... > > > > 5 - how does the secure multicast architecture interact with NAT? is it > > required to work across multiple NAT boundaries? (e.g. does group AH > > break?) > > My usual answer to the problem of multicast and NAT is that it isn't a > problem, because the multicast routing mechanisms (e.g., PIM) rely > heavily on the source address. I'll try to find a place to say this in > the architecture document. You say that it is not a problem, but I don't share your confidance that it works in all cases. At the private/public network boundary, would the NAT gateway twiddle with the source IP address, and therefore break the MAC calc for group AH? > > > 7 - does the architecture have a particular profile on X.509 > > certificates that would assure interoperability (witness the discussions > > on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid > > that swamp?) > > I don't think it is a goal of the architecture document to ensure > interoperability. It's describing the architecture at a much higher > level. that implies I have to tackle each protocol spec in turn, and comb through it for an X.509 profile. My cursory survey of the GSAKMP spec didn't show anything resembling this. GDOIv1 inherits IKEv1, but I don't recall what it say wrt/ ID certificates in the context of groups. I'll take a look see... > > > 8 - what happens when the secure multicast protocols traverses an > > IPSEC gateway? It seems that implicitly you are defining transport mode > > multicast data security associations? or could they be in tunnel mode? if > > the latter, then mention that and how it works. > > George, could you elaborate on the problem? I don't think it should > matter if a multicast protocol gets encapsulated in a transport mode or > tunnel mode IPsec header. If it gets sent through an IPsec gateway > later, and that IPsec gateway policy says to encrypt it, then it would > just end up with two IPsec headers, right? It is not a problem per se, rather it is a use case: unsecure multicast tunnelled within secure multicast. The application that comes to mind is an Enterprise distributing a multicast session to its sites using secure multicast over the public Internet, and within each site doing regular multicast (i.e. trusted network inside the site). So I think that the MSEC protocol should allow negotiation of either tunnel or transport mode. And the arch doc should point out this is required. > > Thanks, > Brian > > > > Hope this clarifies. > > > > > > Ran > > > > > > > > > On Wed, 25 Jun 2003, George Gross wrote: > > > > > > > Hi Lakshminath, > > > > > > > > inline below... > > > > > > > > br, > > > > George > > > > > > > > On Wed, 25 Jun 2003, Lakshminath Dondeti wrote: > > > > > > > > > There are several old expired drafts that discussed IGMP and PIM > > > > > security. Most of the folks in MSEC are aware of that work, yet decided > > > > > to not include protocol security in the charter. It may belong in a > > > > > separate WG IMO (e.g., IPSEC WG designs protocols for data protection > > > > > and RPSEC discusses routing protocol protection). > > > > > > > > > > You are welcome to bring any new ideas (or > > > > > revise old I-Ds and bring them for discussion) to the GSEC meeting; most > > > > > MSEC regulars will show up and the RG might decide how to proceed > > > > co-chair hat off>. > > > > > > > > regretably, I won't be in Vienna, ;o( no doubt it would be great place to > > > > visit > > > > > > > > please let me know what comes out of those discussions... > > > > > > > > > > > > > > I think the MSEC architecture I-D should proceed with its current scope. > > > > > > > > I am not asking that the MSEC architecture expand its scope; rather it > > > > should be _completed_ to describe the requirement to have a mechanism/hook > > > > through which this type of information can be included/tunneled in the > > > > MSEC protocols without defining its structure or semantics (i.e. it is > > > > opaque and to be defined). In the short term, this is likely to be as > > > > simple as reserving a TLV payload type for this future use. > > > > > > > > In the arch ID, the text should simply acknowledge that there is a > > > > set of entities, multicast routers, that must participate in the group > > > > membership's multicast data distribution and they do so securely under the > > > > direction of the GKCS. Unlike point to point IPSEC which is independent of > > > > the routing infrastructure, in MSEC there is a concept of group membership > > > > that has a direct relationship with the multicast routing tables. The text > > > > could be written in very general terms. The text should allow the > > > > flexibility of allowing either the multicast router or the group member > > > > securely initiating the group join/leave routing table update. > > > > > > > > > > > > > > > > > > regards, > > > > > Lakshminath > > > > > > > > > > George Gross wrote: > > > > > > Hi, > > > > > > With Mounir's permission, I'm forwarding an exchange we had wrt/ > > > > > > securing IGMP/MLD/PIM as part of MSEC... > > > > > > > > > > > > George > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > > > Date: Wed, 25 Jun 2003 05:12:18 -0400 (EDT) > > > > > > From: George Gross > > > > > > To: mounir.kellil@hds.utc.fr > > > > > > Cc: George Gross > > > > > > Subject: Re: [MSEC] MSEC v01 arch, comments on section 2 > > > > > > > > > > > > Hi Mounir, > > > > > > > > > > > > My goal with the section 2 questions was to tease out some of the > > > > > > unspoken assumptions that lurk in the architecture if one were to actually > > > > > > deploy MSEC. > > > > > > > > > > > > While Brian and Tom have yet to weigh in on this topic, I imagine > > > > > > that adding refs to the GSEC RG work is a beginning, but not all that > > > > > > needs to be said in the arch doc wrt/ to this comment. I think the > > > > > > architecture doc has to describe, and the MSEC protocols have to define an > > > > > > extensible mechanism(s) to encapsulate an opaque IGMP/MLD > > > > > > authorization/authentication information payload within the {GSAKMP, GDOI, > > > > > > whatever} key management protocol to each group member. With this > > > > > > coupling, I think that the multicast session becomes far more secure. > > > > > > > > > > > > securing PIM or the multicast routing protocol du jour is another > > > > > > interface to MSEC that needs to be mentioned in the arch doc, and perhaps > > > > > > ultimately standardized... > > > > > > > > > > > > br, > > > > > > George > > > > > > > > > > > > On Tue, 24 Jun 2003 mounir.kellil@hds.utc.fr wrote: > > > > > > > > > > > > > > > > > >>Hi George, > > > > > >> > > > > > >>I think that you asked very intersting questions with respect to section 2. > > > > > >> > > > > > >>For your follwong questions: > > > > > >> > > > > > >>> 2 - how to assure the security of the IGMP, MLD, and the multicast > > > > > >>>routing protocol(s) like PIM? > > > > > >>> > > > > > >> > > > > > >>I think Group Membership (MLD, IGMP) security issues as well as multicast > > > > > >>routing porotocols security issues are adressed (exclusively) in GSEC RG. For > > > > > >>the security issues in multicast routing protocols, it seems that there is a > > > > > >>specific solution for each protocol. > > > > > >> > > > > > >>May be next GKarch draft can mention the drafts "draft-irtf-gsec-igmpv3- > > > > > >>security-issues-01" and "draft-irtf-gsec-pim-sm-security-issues-01" as they > > > > > >>both propose extending GDOI to secure respectively IGMP and PIM-SM. > > > > > >> > > > > > >>However, I think that securing Group membership and multicast protocol > > > > > >>protocols basing on GkmArch may not be a good thing as it makes the securty > > > > > >>solution (for MLD and IGMP ,and e.g. PIM) dependent on GKmArch . Decoupling (at > > > > > >>least partially) GkMArch form the other two issues can ensure a multi- > > > > > >>(independent)level security need. > > > > > >> > > > > > >> > > > > > >>Mounir > > > > > >> > > > > > >>------------------------------------------------- > > > > > >>Laboratoire Heudiasyc. UMR CNRS 6599 > > > > > >>http://www.hds.utc.fr > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > > > _______________________________________________ > > > 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 Mon Jun 30 14:59:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10980 for ; Mon, 30 Jun 2003 14:59:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A74BD53978; Mon, 30 Jun 2003 14:58: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 1F0AE53947 for ; Mon, 30 Jun 2003 14:57:23 -0400 (EDT) Received: (qmail 79018 invoked by uid 3269); 30 Jun 2003 18:57:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79014 invoked from network); 30 Jun 2003 18:57:22 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 30 Jun 2003 18:57:22 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5UItsq177742; Mon, 30 Jun 2003 14:55:54 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5UIuh8123736; Mon, 30 Jun 2003 14:56:43 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) id OAA30376; Mon, 30 Jun 2003 14:56:42 -0400 From: Ran Canetti Message-Id: <200306301856.OAA30376@ornavella.watson.ibm.com> To: bew@cisco.com, gmgross@nac.net Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) Cc: canetti@watson.ibm.com, gsec@lists.tislabs.com, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 30 Jun 2003 14:56:42 -0400 > From: George Gross ... > > > 1 - For data traffic multicast, what error recovery procedure(s) are > > > required to detect and avoid network congestion? acks/nacks? what about > > > Explicit Congestion Notification (ECN)? > > > > I think this should be addressed in the to-be-released Data Transforms > > Architecture specification. > > okay, but I would like to suggest adding a pointer in that direction > within your arch document. The approach taken in the GKMA document is to leave this issue to the individual key management protocols. There is a wide variety of potential settings (dependeing on the size of the group, the expected congestion, the ease of upstream communication, etc.), and it doesnt seem to make sense to impose a single mechanism here. > > > > > > 3 - Should/do the group key management protocols assume an underlying > > > reliable transport service? > > > > I believe the answer is that they should not assume they are available, > > because most multicast routing mechanisms deployed today are not > > reliable. > > > > My preference is for this issue to be dealt with in the GKMA document, > > which further refines the group key management architecture. > > hmmm... the GKMA document will kind of describe how the cows have already > left the barn ;o) i.e. GSAKMP is in last call, same story with MIKEY, and > GDOI-v1 is in the RFC queue. I would have thought one would write the GKMA > before the protocol specs?!? > > Anyway, I agree with the view you expresed above, that multicast routing > is not reliable. Therefore, a MSEC protocol spec must either explicitly > define its own error procedures or point to a reliable multicast data > transport protocol that is mandatory to implement. At this point, are > GSAKMP and MIKEY cast in stone? Maybe GDOIv2 is the only possible > candidate for such a solution... Again, there is history here... the common architecture to these KM protocols was discussed at length in smug/msec meetings. The GKMA document is indeed progressing more slowly than ther KM protocols themselves (for obvious reasons - people invest more time in their protocols); but the common architecture is understood by all authors (or so I hope). ... > > > 7 - does the architecture have a particular profile on X.509 > > > certificates that would assure interoperability (witness the discussions > > > on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid > > > that swamp?) > > > > I don't think it is a goal of the architecture document to ensure > > interoperability. It's describing the architecture at a much higher > > level. > > that implies I have to tackle each protocol spec in turn, and comb through > it for an X.509 profile. My cursory survey of the GSAKMP spec didn't show > anything resembling this. GDOIv1 inherits IKEv1, but I don't recall what > it say wrt/ ID certificates in the context of groups. I'll take a look > see... This is indeed a good point, that should be addressed by the KM protocols. Not at the architecture level though, I'd say... perhaps mentioned in the GKMA level. > > > > > > 8 - what happens when the secure multicast protocols traverses an > > > IPSEC gateway? It seems that implicitly you are defining transport mode > > > multicast data security associations? or could they be in tunnel mode? if > > > the latter, then mention that and how it works. > > > > George, could you elaborate on the problem? I don't think it should > > matter if a multicast protocol gets encapsulated in a transport mode or > > tunnel mode IPsec header. If it gets sent through an IPsec gateway > > later, and that IPsec gateway policy says to encrypt it, then it would > > just end up with two IPsec headers, right? > > It is not a problem per se, rather it is a use case: unsecure multicast > tunnelled within secure multicast. The application that comes to mind is > an Enterprise distributing a multicast session to its sites using secure > multicast over the public Internet, and within each site doing regular > multicast (i.e. trusted network inside the site). > > So I think that the MSEC protocol should allow negotiation of either > tunnel or transport mode. And the arch doc should point out this is > required. I'm still not sure I follow here. I guess in your example the gateways of the varioue corporate sites would not have access to the data, ie they would not have keys. right? so they would forward the data "opaquely" to he recipients, regardless of the encapsulation mode. or am i missing something? note btw that the architecture does not mandate ip-level data protection. potentially, the data can be protected via srtp or the like. Ran _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 15:08:33 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11945 for ; Mon, 30 Jun 2003 15:08:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6E94C5394E; Mon, 30 Jun 2003 15:07:25 -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 17416536FF for ; Mon, 30 Jun 2003 13:17:17 -0400 (EDT) Received: (qmail 63746 invoked by uid 3269); 30 Jun 2003 17:17:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63743 invoked from network); 30 Jun 2003 17:17:16 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 30 Jun 2003 17:17:16 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7/8.11.4) with ESMTP id h5UHFmq106902; Mon, 30 Jun 2003 13:15:48 -0400 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.7/8.11.7) with ESMTP id h5UHGb8146446; Mon, 30 Jun 2003 13:16:37 -0400 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3p2/8.9.3/09-18-2002) id NAA30362; Mon, 30 Jun 2003 13:16:37 -0400 From: Ran Canetti Message-Id: <200306301716.NAA30362@ornavella.watson.ibm.com> To: bew@cisco.com, gmgross@nac.net Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) Cc: canetti@watson.ibm.com, gsec@lists.tislabs.com, msec@securemulticast.org Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 30 Jun 2003 13:16:37 -0400 Brian, > From bew@cisco.com Fri Jun 27 19:17:41 2003 ... > > I believe the following statements summarize the discussion, and are > what I propose adding to the architecture document. (This is not actual > text, just the logical statements.) > > 1. A secure application layer group using MSEC protocols does not > require the multicast routing infrastructure to participate in the > group. However, that application layer group has no guarantee that the > the multicast routing infrastructure will route the packets > appropriately. I agree with this rendition. I would have the text stress that while inappropriate routing may cause denial of service, it cannot cause failure of authenticity or secrecy of the data. (This fact is clear to us but may not be obvious to a causual reader.) Ran > > 2. The multicast routing infrastructure comprises a group that could use > MSEC protocols to protect its own traffic. However, this would be > independent of any secure application layer groups. > > I would also add: > > 3. The bridge between the application layer group and the multicast > routing is the network level "join" to a group. Joins to a multicast > group are not the same as "joining" a secure group. I.e., the former > involves sending an IGMP or MLD messages to the closest multicast-aware > router, and the latter means registering with a GCKS to obtain the > policy and keys necessary to participate in the group. (This is already > mentioned in section 5.2.4, but probably needs more emphasis.) > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 15:11:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12288 for ; Mon, 30 Jun 2003 15:11:43 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id EE9A253984; Mon, 30 Jun 2003 15:09:21 -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 9E607536FF for ; Mon, 30 Jun 2003 13:19:44 -0400 (EDT) Received: (qmail 64054 invoked by uid 3269); 30 Jun 2003 17:19:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64051 invoked from network); 30 Jun 2003 17:19:44 -0000 Received: from smtp1.su.se (130.237.162.112) by klesh.pair.com with SMTP; 30 Jun 2003 17:19:44 -0000 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 5687538143; Mon, 30 Jun 2003 19:19:43 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24690-05; Mon, 30 Jun 2003 19:19:43 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp1.su.se (Postfix) with ESMTP id 0C9BC38132; Mon, 30 Jun 2003 19:19:43 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id 98C7A3D381; Mon, 30 Jun 2003 19:19:41 +0200 (MET DST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id CF40F3D36B; Mon, 30 Jun 2003 19:19:40 +0200 (MET DST) Message-Id: <3.0.32.20030630131940.003e9c78@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se (Unverified) X-Mailer: Windows Eudora Pro Version 3.0 (32) To: msec@securemulticast.org From: Sead Muftic Cc: amschue@tycho.ncsc.mil Mime-Version: 1.0 Content-Type: text/enriched; charset="us-ascii" X-Virus-Scanned: by amavisd-new at su.se Subject: [MSEC] CSPRI Implementation of the GSAKMP 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, 30 Jun 2003 13:19:41 -0400 I would like to inform this group that Cyber Security Research and Policy Institute of The George Washington University has recently completed the full implementation of the GSAKMP protocol, together with the first secure group application: secure instant messages within a group. The implementation is based on the documents draft-ietf-msec-gsakmp-sec-00.txt (March 2001) and draft-ietf-msec-tokenspec-sec-00.txt The implementation has been successfully tested against another implementation by Sparta, Inc, processing Policy Token file and all GSAKMP messages. Soon, all the information about our on-going "Survivable Group Security Architecture" project including our software for download will be available on the Institute's Web site. In the meantime, for any additional information please contact me directly. Regards, Sead Muftic Research Director CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 15:17:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12931 for ; Mon, 30 Jun 2003 15:17:40 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1E7B35394B; Mon, 30 Jun 2003 15:17:09 -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 4F183539A0 for ; Mon, 30 Jun 2003 15:10:04 -0400 (EDT) Received: (qmail 81293 invoked by uid 3269); 30 Jun 2003 19:10:04 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 81289 invoked from network); 30 Jun 2003 19:10:03 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 30 Jun 2003 19:10:03 -0000 Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UJ9xI21235; Mon, 30 Jun 2003 12:09:59 -0700 (PDT) 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 h5UJ9ua02945; Mon, 30 Jun 2003 14:09:57 -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 NALHFZ9L; Mon, 30 Jun 2003 12:09:56 -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 MGTS3YFP; Mon, 30 Jun 2003 15:09:55 -0400 Message-ID: <3F008BEB.3070602@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: Ran Canetti Cc: bew@cisco.com, gmgross@nac.net, gsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: <200306301856.OAA30376@ornavella.watson.ibm.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: Mon, 30 Jun 2003 15:13:47 -0400 Content-Transfer-Encoding: 7bit "but the common architecture is understood by all authors (or so I hope)." Ran, This probably should be documented in the MSEC architecture document! I am partially to blame on the GKMA stuff, but have plans to speed it up by recruiting new contributors in Vienna (those who are not attending the meeting, please contact Brian Weis and me). There are several teams presenting their work on GKMAs this time at the GSEC meeting; I plan to ask folks to join the GKMA standardization effort. regards, Lakshminath Ran Canetti wrote: >>From: George Gross > > > ... > > >>>> 1 - For data traffic multicast, what error recovery procedure(s) are >>>>required to detect and avoid network congestion? acks/nacks? what about >>>>Explicit Congestion Notification (ECN)? >>> >>>I think this should be addressed in the to-be-released Data Transforms >>>Architecture specification. >> >>okay, but I would like to suggest adding a pointer in that direction >>within your arch document. > > > The approach taken in the GKMA document is to leave this issue to the > individual key management protocols. There is a wide variety of potential > settings (dependeing on the size of the group, the expected congestion, the > ease of upstream communication, etc.), and it doesnt seem to make sense to > impose a single mechanism here. > > >>>> 3 - Should/do the group key management protocols assume an underlying >>>>reliable transport service? >>> >>>I believe the answer is that they should not assume they are available, >>>because most multicast routing mechanisms deployed today are not >>>reliable. >>> >>>My preference is for this issue to be dealt with in the GKMA document, >>>which further refines the group key management architecture. >> >>hmmm... the GKMA document will kind of describe how the cows have already >>left the barn ;o) i.e. GSAKMP is in last call, same story with MIKEY, and >>GDOI-v1 is in the RFC queue. I would have thought one would write the GKMA >>before the protocol specs?!? >> >>Anyway, I agree with the view you expresed above, that multicast routing >>is not reliable. Therefore, a MSEC protocol spec must either explicitly >>define its own error procedures or point to a reliable multicast data >>transport protocol that is mandatory to implement. At this point, are >>GSAKMP and MIKEY cast in stone? Maybe GDOIv2 is the only possible >>candidate for such a solution... > > > Again, there is history here... the common architecture to these KM > protocols was discussed at length in smug/msec meetings. The GKMA document > is indeed progressing more slowly than ther KM protocols themselves (for > obvious reasons - people invest more time in their protocols); but the > common architecture is understood by all authors (or so I hope). > > ... > > >>>> 7 - does the architecture have a particular profile on X.509 >>>>certificates that would assure interoperability (witness the discussions >>>>on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to avoid >>>>that swamp?) >>> >>>I don't think it is a goal of the architecture document to ensure >>>interoperability. It's describing the architecture at a much higher >>>level. >> >>that implies I have to tackle each protocol spec in turn, and comb through >>it for an X.509 profile. My cursory survey of the GSAKMP spec didn't show >>anything resembling this. GDOIv1 inherits IKEv1, but I don't recall what >>it say wrt/ ID certificates in the context of groups. I'll take a look >>see... > > > This is indeed a good point, that should be addressed by the KM protocols. > Not at the architecture level though, I'd say... perhaps mentioned in the > GKMA level. > > >>>> 8 - what happens when the secure multicast protocols traverses an >>>>IPSEC gateway? It seems that implicitly you are defining transport mode >>>>multicast data security associations? or could they be in tunnel mode? if >>>>the latter, then mention that and how it works. >>> >>>George, could you elaborate on the problem? I don't think it should >>>matter if a multicast protocol gets encapsulated in a transport mode or >>>tunnel mode IPsec header. If it gets sent through an IPsec gateway >>>later, and that IPsec gateway policy says to encrypt it, then it would >>>just end up with two IPsec headers, right? >> >>It is not a problem per se, rather it is a use case: unsecure multicast >>tunnelled within secure multicast. The application that comes to mind is >>an Enterprise distributing a multicast session to its sites using secure >>multicast over the public Internet, and within each site doing regular >>multicast (i.e. trusted network inside the site). >> >>So I think that the MSEC protocol should allow negotiation of either >>tunnel or transport mode. And the arch doc should point out this is >>required. > > > I'm still not sure I follow here. I guess in your example the gateways of > the varioue corporate sites would not have access to the data, ie they > would not have keys. right? so they would forward the data "opaquely" to he > recipients, regardless of the encapsulation mode. > or am i missing something? > > note btw that the architecture does not mandate ip-level data protection. > potentially, the data can be protected via srtp or the like. > > Ran > > > > _______________________________________________ > 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 Mon Jun 30 15:31:10 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13359 for ; Mon, 30 Jun 2003 15:31:10 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 84E1C535BD; Mon, 30 Jun 2003 15:29:42 -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 ADF8853532 for ; Mon, 30 Jun 2003 15:26:47 -0400 (EDT) Received: (qmail 84429 invoked by uid 3269); 30 Jun 2003 19:26:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84422 invoked from network); 30 Jun 2003 19:26:47 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 30 Jun 2003 19:26:47 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UJQgF03999; Mon, 30 Jun 2003 15:26:42 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAFSL4KP; Mon, 30 Jun 2003 15:26:41 -0400 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 MGTS3YGR; Mon, 30 Jun 2003 15:26:41 -0400 Message-ID: <3F008FDA.5030101@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: Sead Muftic Cc: msec@securemulticast.org, bew@cisco.com Subject: Re: [MSEC] CSPRI Implementation of the GSAKMP References: <3.0.32.20030630131940.003e9c78@mail.dsv.su.se> 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: Mon, 30 Jun 2003 15:30:34 -0400 Content-Transfer-Encoding: 7bit Hi, I have a question on the GSAKMP spec. When I read the spec (-01-, I think), my first feeling was that it is under specified. I have told Hugh and Andrea this and they said they might be able to include some additional detail, but not a lot. In your team's experience, is the spec self-contained? Did you have to refer to other RFCs (which is ok), or did you have to contact the authors or other implementers? If so, how frequently. For example, while implementing GDOI, I worked with the ISAKMP and IKE(v1) RFCs, and of course the GDOI I-D. During the interop testing, I interpreted some attributes differently than Brian did. After the testing, Brian revamped the spec to remove the ambiguities (is that a fair summary Brian?) Thanks for your input to the WG. regards, Lakshminath I might read the GSAKMP spec again when -02- comes out to see whether I would be able to implement it independently. Sead Muftic wrote: > > > I would like to inform this group that Cyber Security Research and > Policy Institute > > of The George Washington University has recently completed the full > implementation > > of the GSAKMP protocol, together with the first secure group > application: secure > > instant messages within a group. The implementation is based on the > documents > > > draft-ietf-msec-gsakmp-sec-00.txt (March 2001) and > > draft-ietf-msec-tokenspec-sec-00.txt > > > The implementation has been successfully tested against another > implementation > > by Sparta, Inc, processing Policy Token file and all GSAKMP messages. > > > Soon, all the information about our on-going "Survivable Group Security > Architecture" > > project including our software for download will be available on the > Institute's Web > > site. In the meantime, for any additional information please contact me > directly. > > > Regards, > > > Sead Muftic > > Research Director > > CSPRI/GWU > > > _______________________________________________ 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 Mon Jun 30 16:37:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14878 for ; Mon, 30 Jun 2003 16:37:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 0DA3D53641; Mon, 30 Jun 2003 16:36: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 AE80A537D7 for ; Mon, 30 Jun 2003 16:34:46 -0400 (EDT) Received: (qmail 95565 invoked by uid 3269); 30 Jun 2003 20:34:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 95560 invoked from network); 30 Jun 2003 20:34:46 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 30 Jun 2003 20:34:46 -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 h5UKXwq21769; Mon, 30 Jun 2003 15:33:58 -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 NALHF96B; Mon, 30 Jun 2003 13:33:58 -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 MGTS3YKQ; Mon, 30 Jun 2003 16:33:57 -0400 Message-ID: <3F009F9D.5020105@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: "Lakshminath Dondeti" Cc: Ran Canetti , bew@cisco.com, gmgross@nac.net, gsec@lists.tislabs.com, msec@securemulticast.org Subject: Re: [GSEC] Re: [MSEC] MSEC v01 arch, comments on section 2 (fwd) References: <200306301856.OAA30376@ornavella.watson.ibm.com> <3F008BEB.3070602@nortelnetworks.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: Mon, 30 Jun 2003 16:37:49 -0400 Content-Transfer-Encoding: 7bit Clarification: Ran uses GKMA for GKM architecture document, whereas I was talking about GKM algorithms. In future, we might use GKMarch and GKMalgm to avoid confusion. cheers, Lakshminath Dondeti, Lakshminath [BL60:1A14:EXCH] wrote: > "but the > common architecture is understood by all authors (or so I hope)." > > Ran, > > This probably should be documented in the MSEC architecture document! > > I am partially to blame on the GKMA stuff, but have plans to speed it up > by recruiting new contributors in Vienna (those who are not attending > the meeting, please contact Brian Weis and me). There are several teams > presenting their work on GKMAs this time at the GSEC meeting; I plan to > ask folks to join the GKMA standardization effort. > > regards, > Lakshminath > > Ran Canetti wrote: > >>> From: George Gross >> >> >> >> ... >> >> >>>>> 1 - For data traffic multicast, what error recovery procedure(s) are >>>>> required to detect and avoid network congestion? acks/nacks? what >>>>> about >>>>> Explicit Congestion Notification (ECN)? >>>> >>>> >>>> I think this should be addressed in the to-be-released Data Transforms >>>> Architecture specification. >>> >>> >>> okay, but I would like to suggest adding a pointer in that direction >>> within your arch document. >> >> >> >> The approach taken in the GKMA document is to leave this issue to the >> individual key management protocols. There is a wide variety of potential >> settings (dependeing on the size of the group, the expected >> congestion, the >> ease of upstream communication, etc.), and it doesnt seem to make >> sense to >> impose a single mechanism here. >> >> >>>>> 3 - Should/do the group key management protocols assume an underlying >>>>> reliable transport service? >>>> >>>> >>>> I believe the answer is that they should not assume they are available, >>>> because most multicast routing mechanisms deployed today are not >>>> reliable. >>>> >>>> My preference is for this issue to be dealt with in the GKMA document, >>>> which further refines the group key management architecture. >>> >>> >>> hmmm... the GKMA document will kind of describe how the cows have >>> already >>> left the barn ;o) i.e. GSAKMP is in last call, same story with MIKEY, >>> and >>> GDOI-v1 is in the RFC queue. I would have thought one would write the >>> GKMA >>> before the protocol specs?!? >>> >>> Anyway, I agree with the view you expresed above, that multicast routing >>> is not reliable. Therefore, a MSEC protocol spec must either explicitly >>> define its own error procedures or point to a reliable multicast data >>> transport protocol that is mandatory to implement. At this point, are >>> GSAKMP and MIKEY cast in stone? Maybe GDOIv2 is the only possible >>> candidate for such a solution... >> >> >> >> Again, there is history here... the common architecture to these KM >> protocols was discussed at length in smug/msec meetings. The GKMA >> document >> is indeed progressing more slowly than ther KM protocols themselves (for >> obvious reasons - people invest more time in their protocols); but the >> common architecture is understood by all authors (or so I hope). >> >> ... >> >> >>>>> 7 - does the architecture have a particular profile on X.509 >>>>> certificates that would assure interoperability (witness the >>>>> discussions >>>>> on IPSEC list wrt/ IKEv2 ID payloads and certs, wouldn't we like to >>>>> avoid >>>>> that swamp?) >>>> >>>> >>>> I don't think it is a goal of the architecture document to ensure >>>> interoperability. It's describing the architecture at a much higher >>>> level. >>> >>> >>> that implies I have to tackle each protocol spec in turn, and comb >>> through >>> it for an X.509 profile. My cursory survey of the GSAKMP spec didn't >>> show >>> anything resembling this. GDOIv1 inherits IKEv1, but I don't recall what >>> it say wrt/ ID certificates in the context of groups. I'll take a look >>> see... >> >> >> >> This is indeed a good point, that should be addressed by the KM >> protocols. >> Not at the architecture level though, I'd say... perhaps mentioned in the >> GKMA level. >> >> >>>>> 8 - what happens when the secure multicast protocols traverses an >>>>> IPSEC gateway? It seems that implicitly you are defining transport >>>>> mode >>>>> multicast data security associations? or could they be in tunnel >>>>> mode? if >>>>> the latter, then mention that and how it works. >>>> >>>> >>>> George, could you elaborate on the problem? I don't think it should >>>> matter if a multicast protocol gets encapsulated in a transport mode or >>>> tunnel mode IPsec header. If it gets sent through an IPsec gateway >>>> later, and that IPsec gateway policy says to encrypt it, then it would >>>> just end up with two IPsec headers, right? >>> >>> >>> It is not a problem per se, rather it is a use case: unsecure multicast >>> tunnelled within secure multicast. The application that comes to mind is >>> an Enterprise distributing a multicast session to its sites using secure >>> multicast over the public Internet, and within each site doing regular >>> multicast (i.e. trusted network inside the site). >>> >>> So I think that the MSEC protocol should allow negotiation of either >>> tunnel or transport mode. And the arch doc should point out this is >>> required. >> >> >> >> I'm still not sure I follow here. I guess in your example the gateways of >> the varioue corporate sites would not have access to the data, ie they >> would not have keys. right? so they would forward the data "opaquely" >> to he >> recipients, regardless of the encapsulation mode. >> or am i missing something? >> >> note btw that the architecture does not mandate ip-level data protection. >> potentially, the data can be protected via srtp or the like. >> >> Ran >> >> >> >> _______________________________________________ >> 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 > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 16:41:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14983 for ; Mon, 30 Jun 2003 16:41:37 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 22CC55354E; Mon, 30 Jun 2003 16:41: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 95C7653734 for ; Mon, 30 Jun 2003 16:39:34 -0400 (EDT) Received: (qmail 96376 invoked by uid 3269); 30 Jun 2003 20:39:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 96369 invoked from network); 30 Jun 2003 20:39:33 -0000 Received: from smtp2.su.se (130.237.93.212) by klesh.pair.com with SMTP; 30 Jun 2003 20:39:33 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id 1C853200018; Mon, 30 Jun 2003 22:39:32 +0200 (CEST) Received: from smtp2.su.se ([127.0.0.1]) by localhost (smtp2.su.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29945-07; Mon, 30 Jun 2003 22:39:31 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id DD5BF200001; Mon, 30 Jun 2003 22:39:31 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id 174A33D382; Mon, 30 Jun 2003 22:39:30 +0200 (MET DST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id DF46D3D381; Mon, 30 Jun 2003 22:39:27 +0200 (MET DST) Message-Id: <3.0.32.20030630163928.00ab2478@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: Windows Eudora Pro Version 3.0 (32) To: Lakshminath Dondeti From: Sead Muftic Subject: Re: [MSEC] CSPRI Implementation of the GSAKMP Cc: msec@securemulticast.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Virus-Scanned: by amavisd-new at su.se 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, 30 Jun 2003 16:39:30 -0400 Lakshminath: First, as I mentioned, we based our implementation on the two documents: > draft-ietf-msec-gsakmp-sec-00.txt (March 2001) and > draft-ietf-msec-tokenspec-sec-00.txt I am new to this list and the WG, so I don't know if there are any other relevant documents. But, since we are extending our GSAKMP project into another year, we will definitely in the next version cover all relevant aspects and standards, if any of them significantly different from the GSAKMP. As far as those two documents are concerned, we found them very clear and straight. We could implement all GSAKMP messages and Policy Token, so that our GSA system is operational and performs all functions required by the GSAKMP draft. Our interoperability testing with Sparta, Inc. was without serious problems. (Not even close to some other - PKI interoperability - projects !) However, our main impression is that the specs are over-specified. By that I mean there are certain features which are redundant and quite frankly, other than parsing them from GSAKMP messages, we do not use them. Finally, I personally found GSAKMP draft standard a bit "outside of the mainstream", especially wrt PKI, certificates, ASN.1, etc. But, as the first version, it is quite clear and not so complicated for the full implementation. Regards, Sead Muftic CSPRI/GWU ------------------------------- >Hi, > >I have a question on the GSAKMP spec. When I read the spec (-01-, I >think), my first feeling was that it is under specified. I have told >Hugh and Andrea this and they said they might be able to include some >additional detail, but not a lot. > >In your team's experience, is the spec self-contained? Did you have to >refer to other RFCs (which is ok), or did you have to contact the >authors or other implementers? If so, how frequently. > >For example, while implementing GDOI, I worked with the ISAKMP and >IKE(v1) RFCs, and of course the GDOI I-D. During the interop testing, I >interpreted some attributes differently than Brian did. After the >testing, Brian revamped the spec to remove the ambiguities (is that a >fair summary Brian?) > >Thanks for your input to the WG. > >regards, >Lakshminath > >I might read the GSAKMP spec again when -02- comes out to see whether I >would be able to implement it independently. > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 17:11:15 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16573 for ; Mon, 30 Jun 2003 17:11:14 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 04D3853937; Mon, 30 Jun 2003 17:08:50 -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 7112753929 for ; Mon, 30 Jun 2003 17:07:10 -0400 (EDT) Received: (qmail 2014 invoked by uid 3269); 30 Jun 2003 21:07:10 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 2010 invoked from network); 30 Jun 2003 21:07:10 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 30 Jun 2003 21:07:10 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.us.nortel.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UL75S17174; Mon, 30 Jun 2003 17:07:05 -0400 (EDT) Received: from zbl6c002.us.nortel.com (zbl6c002.corpeast.baynetworks.com [132.245.205.52]) by zbl6c012.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id NAFSLVJ0; Mon, 30 Jun 2003 17:07:04 -0400 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 MGTS3YL7; Mon, 30 Jun 2003 17:07:05 -0400 Message-ID: <3F00A760.90309@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: Sead Muftic Cc: msec@securemulticast.org Subject: Re: [MSEC] CSPRI Implementation of the GSAKMP References: <3.0.32.20030630163928.00ab2478@mail.dsv.su.se> 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: Mon, 30 Jun 2003 17:10:56 -0400 Content-Transfer-Encoding: 7bit Hi Sead, Thanks for sharing your opinions on the GSAKMP spec. Could you elaborate on what is *over-specified*? Also, Hugh noted in his email (dated June 20th) that the spec is ready for last call. In your comments you note "But, as the first version, it is quite clear and not so complicated for the full implementation." In fact, the current spec dated Feb 2003, is either -01- or -02-, and Hugh mentioned that they will be submitting -02-/-03- soon. Thanks again. regards, Lakshminath Sead Muftic wrote: > Lakshminath: > > First, as I mentioned, we based our implementation on the two documents: > > >>draft-ietf-msec-gsakmp-sec-00.txt (March 2001) and >>draft-ietf-msec-tokenspec-sec-00.txt > > > I am new to this list and the WG, so I don't know if there are any other > relevant > documents. But, since we are extending our GSAKMP project into another > year, we will > definitely in the next version cover all relevant aspects and standards, if > any of them > significantly different from the GSAKMP. > > As far as those two documents are concerned, we found them very clear and > straight. We could > implement all GSAKMP messages and Policy Token, so that our GSA system is > operational and > performs all functions required by the GSAKMP draft. Our interoperability > testing > with Sparta, Inc. was without serious problems. (Not even close to some > other - PKI interoperability - > projects !) > > However, our main impression is that the specs are over-specified. By that > I mean there are > certain features which are redundant and quite frankly, other than parsing > them from > GSAKMP messages, we do not use them. > > Finally, I personally found GSAKMP draft standard a bit "outside of the > mainstream", > especially wrt PKI, certificates, ASN.1, etc. But, as the first version, it > is quite clear > and not so complicated for the full implementation. > > Regards, > > Sead Muftic > CSPRI/GWU > > ------------------------------- > > > >>Hi, >> >>I have a question on the GSAKMP spec. When I read the spec (-01-, I >>think), my first feeling was that it is under specified. I have told >>Hugh and Andrea this and they said they might be able to include some >>additional detail, but not a lot. >> >>In your team's experience, is the spec self-contained? Did you have to >>refer to other RFCs (which is ok), or did you have to contact the >>authors or other implementers? If so, how frequently. >> >>For example, while implementing GDOI, I worked with the ISAKMP and >>IKE(v1) RFCs, and of course the GDOI I-D. During the interop testing, I >>interpreted some attributes differently than Brian did. After the >>testing, Brian revamped the spec to remove the ambiguities (is that a >>fair summary Brian?) >> >>Thanks for your input to the WG. >> >>regards, >>Lakshminath >> >>I might read the GSAKMP spec again when -02- comes out to see whether I >>would be able to implement it independently. >> > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jun 30 18:30:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19790 for ; Mon, 30 Jun 2003 18:30:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D20D553892; Mon, 30 Jun 2003 18:29:17 -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 1F1FB537DE for ; Mon, 30 Jun 2003 18:26:58 -0400 (EDT) Received: (qmail 14669 invoked by uid 3269); 30 Jun 2003 22:26:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14666 invoked from network); 30 Jun 2003 22:26:57 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 30 Jun 2003 22:26:57 -0000 Received: from zsc3c028.us.nortel.com (zsc3c028.us.nortel.com [47.81.138.28]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h5UMQii16705; Mon, 30 Jun 2003 15:26:45 -0700 (PDT) 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 NALHGGBP; Mon, 30 Jun 2003 15:26:44 -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 MGTS3YN7; Mon, 30 Jun 2003 18:26:43 -0400 Message-ID: <3F00BA0A.9050203@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: hh@sparta.com Cc: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] A few questions on GSAKMP (long) 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, 30 Jun 2003 18:30:34 -0400 Content-Transfer-Encoding: 7bit Hi Hugh, I have some questions GSAKMP (draft-ietf-msec-gsakmp-sec-01.txt, Feb 2003). Sec 4.2.3 on notification messages says: "The GCKS receives the signed notification and will verify the signature on the message to ensure its authenticity and the nonce value. If the message signature or nonce does not verify, the session MUST be terminated. GSAKMP sends a properly authenticated message with a Notification Payload of type NACK to indicate termination. " What happens if this message is lost or has never been sent. The member has no way of knowing whether the message has been delivered or not (at least not in the first case :-) ). In either case, it can go on to install the data security SA and listen in on secure group communications. What is the GCKS expected to do? It sounds counter-intuitive to do nonceC checking after keys have been distributed. Is this to finish in three messages? What does session termination mean in the context of 4.2.3? Does the GCKS terminate/update the Registration SA, Rekey SA or the Data Security SA, or all? If it is Registration SA, it does not affect the member, does it? In Table 4 of Section 4.3.2, is the Rekey Array same as the Key Download payload? Also, I was wondering if the Rekey message should be HMAC'ed to avoid a simple DoS attack. Why not encrypt the Rekey Array to avoid exposing portions of that payload (e.g., length) to eavesdroppers? There is also no SEQ number in that message. How would the members distinguish a legitimate Rekey message from a replayed one? Am I misreading the spec here? In "{}SigX :Indicates minimum fields used in Signature," I don't understand the reference to minimum fields. Finally, it may be useful to tailor some of the terminology in this document along the lines of GKM architecture document. Furthermore, it will be easier for folks planning to analyze the protocol to have all the definitions (e.g., NonceC = ..., ACK construction) in the running text, not in payload definitions. May I suggest replacing Key Creation payload with Key Exchange payload? thanks, Lakshminath PS: The I-D lacks a security considerations section. You might have included one in the latest version. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec