From msec-admin@securemulticast.org Tue Jul 1 07:24:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07548 for ; Tue, 1 Jul 2003 07:24:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4978B535C9; Tue, 1 Jul 2003 07:24: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 5A94B535B9 for ; Tue, 1 Jul 2003 07:23:27 -0400 (EDT) Received: (qmail 15628 invoked by uid 3269); 1 Jul 2003 11:23:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 15623 invoked from network); 1 Jul 2003 11:23:27 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 1 Jul 2003 11:23:27 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07251; Tue, 1 Jul 2003 07:23:23 -0400 (EDT) Message-Id: <200307011123.HAA07251@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-07.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: Tue, 01 Jul 2003 07:23:23 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : MIKEY: Multimedia Internet KEYing Author(s) : J. Arkko et al. Filename : draft-ietf-msec-mikey-07.txt Pages : 58 Date : 2003-6-30 Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-07.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-30151505.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-30151505.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 10:35:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02812 for ; Tue, 1 Jul 2003 10:35:02 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CCE1E53680; Tue, 1 Jul 2003 10:34: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 9EB2753600 for ; Tue, 1 Jul 2003 10:32:07 -0400 (EDT) Received: (qmail 50937 invoked by uid 3269); 1 Jul 2003 14:32:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 50934 invoked from network); 1 Jul 2003 14:32:07 -0000 Received: from smtp1.su.se (130.237.162.112) by klesh.pair.com with SMTP; 1 Jul 2003 14:32:07 -0000 Received: from localhost (smtp1.su.se [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 9CA0138198; Tue, 1 Jul 2003 16:32:06 +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 16825-04; Tue, 1 Jul 2003 16:32:06 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp1.su.se (Postfix) with ESMTP id 41569380E2; Tue, 1 Jul 2003 16:32:06 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id 2A5CA3D385; Tue, 1 Jul 2003 16:32:06 +0200 (MET DST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id 6BAF63D37F; Tue, 1 Jul 2003 16:32:05 +0200 (MET DST) Message-Id: <3.0.32.20030701102739.00aa9728@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: Tue, 01 Jul 2003 10:32:05 -0400 Lakshminath: >Thanks for sharing your opinions on the GSAKMP spec. Could you >elaborate on what is *over-specified*? By "over-specified" I really mean specs of the Policy Token, especially wrt PKI and certificates. Without elaborating all the details, just take "Owner PKI" payload. It contains "PKI Type" (strange formulation !?) meaning "the type of the certificate ... ". However, just by giving Issuer's DN and serialNumber (standard elements of every certificate) you may get from the certifiate its type. The same with "Public Key Length" - you really don't need that, since by extracting public key from the certificate, you can get its length. Many other aspects can be quoted. It seems that Policy Token was structured to be "self-contained", which I call "over-specified" as many aspects of PKI and certificates could have been solved by using appropriate references to standard PKI and certificate attributes. However, taking both specs (GSAKMP and Policy Token) as given, then implementation is straight forward and not complicated. Furthermore, interoperability goes quite smoothly. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 11:21:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04264 for ; Tue, 1 Jul 2003 11:21:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A21B45374A; Tue, 1 Jul 2003 11:20: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 DAFF85373F for ; Tue, 1 Jul 2003 11:18:11 -0400 (EDT) Received: (qmail 59226 invoked by uid 3269); 1 Jul 2003 15:18:11 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59223 invoked from network); 1 Jul 2003 15:18:11 -0000 Received: from smtp017.mail.yahoo.com (216.136.174.114) by klesh.pair.com with SMTP; 1 Jul 2003 15:18:11 -0000 Received: from h0010a4c49f9e.ne.client2.attbi.com (HELO THARDJONO-LAP.yahoo.com) (thardjono@24.128.44.201 with login) by smtp.mail.vip.sc5.yahoo.com with SMTP; 1 Jul 2003 15:18:10 -0000 Message-Id: <5.2.1.1.2.20030701111359.022c4dc0@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 To: msec@securemulticast.org From: Thomas Hardjono In-Reply-To: <200307011123.HAA07251@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Draft draft-ietf-msec-gsakmp-sec-03.txt now on MSEC website 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, 01 Jul 2003 11:18:08 -0400 Folks, Due to an oversight on my part, version -03 of GSAKMP did not make it to the cutoff date. However, the draft is now available at the MSEC site, in time for Vienna: http://www.securemulticast.org/draft-ietf-msec-gsakmp-sec-03.txt cheers, Thomas ------ (ps. I'll soon be updating the copies of other MSEC drafts on that site). _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 13:49:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09070 for ; Tue, 1 Jul 2003 13:49:03 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 21161537BE; Tue, 1 Jul 2003 13:11:20 -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 C81F7535FA for ; Tue, 1 Jul 2003 13:08:26 -0400 (EDT) Received: (qmail 78044 invoked by uid 3269); 1 Jul 2003 17:08:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78041 invoked from network); 1 Jul 2003 17:08:26 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 1 Jul 2003 17:08:26 -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 h61H7lB2007911; Tue, 1 Jul 2003 12:07:48 -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 h61H7i1L005455; Tue, 1 Jul 2003 12:07:44 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id NAA12390; Tue, 1 Jul 2003 13:07:42 -0400 (EDT) Message-ID: <3F01BFA3.4020907@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; 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: hh@sparta.com, msec@securemulticast.org Subject: Re: [MSEC] A few questions on GSAKMP (long) References: <3F00BA0A.9050203@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 01 Jul 2003 13:06:43 -0400 Content-Transfer-Encoding: 7bit Hi, Lakshminath, Hugh is away for a couple of weeks, so I will try to answer the questions that you posed to him. Lakshminath Dondeti wrote: > 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? Without the use of a synchronized timestamp, we need a minimum of three messages to complete the authentication including freshness. If the authentication fails for any reason (e.g., replay, lost messages) then the GCKS needs to respond in a policy-appropriate manner. In most cases, this will involving keying the failed potential member out through an update of the Rekey SA. Once again, whether this occurs immediately or whether some buffering of updates to the Rekey SA occurs is a matter of policy. > > > 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? The GSAKMP header has a sequence number, plus, the rekey array itself (for the LKH case) has a time/date stamp. Because of the relative infrequency of rekey messages, the group can tolerate a loose synchronization or even use the stamp in more of a sequence number type of check where the stamp only needs to be greater than the stamp last seen. In general, though, it is probably just easier to always use the GSAKMP header sequence number because it will always be available even if, say, an OFC scheme were used that didn't contain a timestamp in its syntax. The message is signed, so any change to the message (truncation, etc.) will be detected. Even with a keyed hash, any change in the array by an adversary will cause denial of service, but perhaps I am misunderstanding your DoS attack? The rekey array should be sent under the protection of the Data Security SA, so it is encrypted. The keys are, of course, encrypted with the tree scheme as well. The rekey array is a piece of the key download, but in not identical. > > > In "{}SigX :Indicates minimum fields used in Signature," I don't > understand the reference to minimum fields. The terminology is a little confusing, I agree. I believe it is a bit of a legacy from the original ISAKMP model, where additional payloads could be added to any message. The brackets indicate what fields are expected under the signature, which does beg the question, "why the square brackets, then?" > > 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. Yes, it was made available to the list this morning. Thanks for your comments. --- Andrea > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 16:03:56 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14772 for ; Tue, 1 Jul 2003 16:03:55 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AC3F753822; Tue, 1 Jul 2003 16:03: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 47DE75355F for ; Tue, 1 Jul 2003 16:01:51 -0400 (EDT) Received: (qmail 7678 invoked by uid 3269); 1 Jul 2003 20:01:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 7671 invoked from network); 1 Jul 2003 20:01:51 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 1 Jul 2003 20:01:51 -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 h61K1aS13795; Tue, 1 Jul 2003 16:01:37 -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 NAFSL607; Tue, 1 Jul 2003 16:01:36 -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 MGTS3ZJ5; Tue, 1 Jul 2003 16:01:36 -0400 Message-ID: <3F01E987.40502@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: Andrea Colegrove Cc: hh@sparta.com, msec@securemulticast.org Subject: Re: [MSEC] A few questions on GSAKMP (long) References: <3F00BA0A.9050203@nortelnetworks.com> <3F01BFA3.4020907@columbia.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: Tue, 01 Jul 2003 16:05:27 -0400 Content-Transfer-Encoding: 7bit Thanks Andrea. I did address them for Hugh, but the questions are for GSAKMP authors/editor(s). Before, we get to the current thread, can I ask why we cannot use IKEv2 model of 4/6 messages instead of the 3/5 messages in the current I-D? At that point we can call it GDOIv2 and be done with protocols in this group once and for all (I see *5* different IETF protocols for group key management so far, viz., GKMP, tGSAKMP, GDOI, GSAKMP, GDOIv2) ! Any opinions on this? Thanks for the clarification on SEQ numbers; however my point about specifying the protocol processing in the description section (Sec 4) rather than in payloads section (Sec 6) still stands. Is the SEQ number usage in GSAKMP different than message-IDs in IKEv2? A section about the Seq ID works during Registration and the Rekey, in the GCKS and in the SGCKSs would be necessary for the spec to be complete. Section 3 should probably be renamed as "Basis of security" or something like that, and there should be a security considerations at the end discussing what GSAKMP covers and what is out of scope (security wise). Or just move Section 3 to the end. Additional comments inline: Andrea Colegrove wrote: > Hi, Lakshminath, > Hugh is away for a couple of weeks, so I will try to answer the > questions that you posed to him. > > Lakshminath Dondeti wrote: > >> 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? > > > Without the use of a synchronized timestamp, we need a minimum of three > messages to complete the authentication including freshness. If the > authentication fails for any reason (e.g., replay, lost messages) then > the GCKS needs to respond in a policy-appropriate manner. In most > cases, this will involving keying the failed potential member out > through an update of the Rekey SA. Once again, whether this occurs > immediately or whether some buffering of updates to the Rekey SA occurs > is a matter of policy. This text should be in the I-D. This to me is a big disadvantage of the 3 message protocol. The rationale I recall is that the final message allows the accounting/auditing/billing systems to kick in. However, if that message is lost in transit, the GCKS might end up rekeying the whole group. This is inefficient in that an unsuccessful registration may end up affecting all members. If rekeying is done via unicast, this problem ends up requiring several messages. If the policy to avoid this problem is to periodically rekey the group, the rationale for the 3 message (as opposed to 4 message version) exchange falls apart; members can then gain access to a secure group, albeit for a relatively short while, subverting the accounting/auditing processes. > >> >> >> 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? > > > The GSAKMP header has a sequence number, plus, the rekey array itself > (for the LKH case) has a time/date stamp. Because of the relative > infrequency of rekey messages, the group can tolerate a loose > synchronization or even use the stamp in more of a sequence number type > of check where the stamp only needs to be greater than the stamp last > seen. In general, though, it is probably just easier to always use the > GSAKMP header sequence number because it will always be available even > if, say, an OFC scheme were used that didn't contain a timestamp in its > syntax. > > The message is signed, so any change to the message (truncation, etc.) > will be detected. Even with a keyed hash, any change in the array by an > adversary will cause denial of service, but perhaps I am > misunderstanding your DoS attack? If a member could verify the keyed hash before trying to verify the signature, we can avoid the DoS attack of an adversary sending bogus rekey messages (a simple replay succeeds as a DoS attack on the members' computational resources). > > The rekey array should be sent under the protection of the Data Security > SA, so it is encrypted. The keys are, of course, encrypted with the > tree scheme as well. Is the rekey message sent via the data security protocol (e.g., IPsec), not a separate rekey protocol? In either case, you might specify that clearly in Sec 4.3. Thanks again Andrea! best, Lakshminath > > The rekey array is a piece of the key download, but in not identical. > >> >> >> In "{}SigX :Indicates minimum fields used in Signature," I don't >> understand the reference to minimum fields. > > > The terminology is a little confusing, I agree. I believe it is a bit > of a legacy from the original ISAKMP model, where additional payloads > could be added to any message. The brackets indicate what fields are > expected under the signature, which does beg the question, "why the > square brackets, then?" > >> >> 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. > > > Yes, it was made available to the list this morning. > > Thanks for your comments. > > --- Andrea > >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec >> >> > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 17:31:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17079 for ; Tue, 1 Jul 2003 17:31:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8CED3536E6; Tue, 1 Jul 2003 17:31: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 3BFCC53641 for ; Tue, 1 Jul 2003 17:26:24 -0400 (EDT) Received: (qmail 21695 invoked by uid 3269); 1 Jul 2003 21:26:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21692 invoked from network); 1 Jul 2003 21:26:23 -0000 Received: from zrc2s0jx.nortelnetworks.com (47.103.122.112) by klesh.pair.com with SMTP; 1 Jul 2003 21:26:23 -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 h61KAv200249; Tue, 1 Jul 2003 15:10: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 NALHH77H; Tue, 1 Jul 2003 13:10:57 -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 MGTS3ZKF; Tue, 1 Jul 2003 16:10:55 -0400 Message-ID: <3F01EBB6.6030503@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 , canetti@watson.ibm.com Cc: msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, thardjono@yahoo.com Subject: Re: [MSEC] re-Charter of MSEC and milestones References: <5.2.1.1.2.20030625104340.022a9098@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: Tue, 01 Jul 2003 16:14:46 -0400 Content-Transfer-Encoding: 7bit Thomas and Ran, What about the Policy Token I-D (draft-ietf-msec-tokenspec-sec-00.txt) in the charter timeline? It appears that GSAKMP is closely tied in with that spec, so I guess it is better to have them go to last call simultaneously. regards, Lakshminath Thomas Hardjono wrote: > > [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 > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 17:55:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17621 for ; Tue, 1 Jul 2003 17:55:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 443AE536CA; Tue, 1 Jul 2003 17:55: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 C1B6853690 for ; Tue, 1 Jul 2003 17:52:43 -0400 (EDT) Received: (qmail 25022 invoked by uid 3269); 1 Jul 2003 21:52:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25019 invoked from network); 1 Jul 2003 21:52:43 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 1 Jul 2003 21:52:43 -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 h61LqOB2020570; Tue, 1 Jul 2003 16:52:24 -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 h61LqL1L015642; Tue, 1 Jul 2003 16:52:22 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id RAA16878; Tue, 1 Jul 2003 17:52:20 -0400 (EDT) Message-ID: <3F020257.5070505@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; 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: hh@sparta.com, msec@securemulticast.org Subject: Re: [MSEC] A few questions on GSAKMP (long) References: <3F00BA0A.9050203@nortelnetworks.com> <3F01BFA3.4020907@columbia.sparta.com> <3F01E987.40502@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 01 Jul 2003 17:51:20 -0400 Content-Transfer-Encoding: 7bit Lakshminath, Lakshminath Dondeti wrote: > Thanks Andrea. I did address them for Hugh, but the questions are for > GSAKMP authors/editor(s). > > Before, we get to the current thread, can I ask why we cannot use > IKEv2 model of 4/6 messages instead of the 3/5 messages in the current > I-D? At that point we can call it GDOIv2 and be done with protocols in > this group once and for all (I see *5* different IETF protocols for > group key management so far, viz., GKMP, tGSAKMP, GDOI, GSAKMP, > GDOIv2) ! Any opinions on this? Hmm. I believe that tGSAKMP and GKMP are both considered historical. GDOI, I have always believed, is somewhat more streamlined to IPsec. The differences between GDOI and GSAKMP have been debated before. I am not familiar with GDOIv2. IKEv2 is a pairwise SA that protects identities somewhat. Four messages are needed to do this. I don't think that the concept of a GCKS maps to that of a peer very well, so I do not really see the urgency of going to the four/six model. Perhaps there are other reasons, I haven't given it much more thought. IKEv2 was not around at the beginning of GSAKMP 's three message rebirth. > > Is the SEQ number usage in GSAKMP different than message-IDs in IKEv2? > A section about the Seq ID works during Registration and the Rekey, in > the GCKS and in the SGCKSs would be necessary for the spec to be > complete. Not different. I agree that this discussion should be included. > > > Section 3 should probably be renamed as "Basis of security" or > something like that, and there should be a security considerations at > the end discussing what GSAKMP covers and what is out of scope > (security wise). Or just move Section 3 to the end. Interesting section title ;-) >>> >>> 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? >> >> >> >> Without the use of a synchronized timestamp, we need a minimum of >> three messages to complete the authentication including freshness. >> If the authentication fails for any reason (e.g., replay, lost >> messages) then the GCKS needs to respond in a policy-appropriate >> manner. In most cases, this will involving keying the failed >> potential member out through an update of the Rekey SA. Once again, >> whether this occurs immediately or whether some buffering of updates >> to the Rekey SA occurs is a matter of policy. > > > This text should be in the I-D. > > This to me is a big disadvantage of the 3 message protocol. The > rationale I recall is that the final message allows the > accounting/auditing/billing systems to kick in. However, if that > message is lost in transit, the GCKS might end up rekeying the whole > group. This is inefficient in that an unsuccessful registration may > end up affecting all members. If rekeying is done via unicast, this > problem ends up requiring several messages. > > If the policy to avoid this problem is to periodically rekey the > group, the rationale for the 3 message (as opposed to 4 message > version) exchange falls apart; members can then gain access to a > secure group, albeit for a relatively short while, subverting the > accounting/auditing processes. The key exchange components are sent in signed messages, therefore, although it may potentially be a replay, it is still source authentic in that the D-H publics are still bound to the signature of the original source. This will not result in inappropriate disclosure of data in most groups as most groups will likely only provide the key if the member is authorized in the first place. The lack of an ACK (poetry here) resulting in a rekey is only necessary for certain types of groups (e.g., fee for service arrangements). It is related to the issue of being able to force acknowledgement of receipt of key. The amount of disclosure can be limited by rekeying prior to actual service start or by timing rekeys to occur periodically. Sort of like watching the first few minutes of pay per view for free :-) Again, this is really just for the few groups that are set up this way, most groups won't care if the ACK is lost. If rekey really needs to be limited, another option is to use tcp as that would limit the dropped ACKs to deliberate cases. > If a member could verify the keyed hash before trying to verify the > signature, we can avoid the DoS attack of an adversary sending bogus > rekey messages (a simple replay succeeds as a DoS attack on the > members' computational resources). Since the rekey is sent under the data protection SA, it wouldn't even decrypt unless it is from an "insider". DoS is therefore also limited to insiders. > Is the rekey message sent via the data security protocol (e.g., > IPsec), not a separate rekey protocol? In either case, you might > specify that clearly in Sec 4.3. Actually, now that you point it out, I believe we decided that it may be under the data SA, but wasn't necessarily. If not, the DoS against a member could be an issue. I wonder though, if it is significant? Sending erred Key Downloads to a member would only be a significant resource consumption if the member was expecting a KD and processed repeats. DoS by not letting them in the group on the other hand, could be accomplished easily with or without the keyed hash. Oh, well, regardless, you have a good point that it needs to be specified more clearly how the rekeys are sent. Thanks again for your very close review of this and for discussing this on the list. Additional comments are always welcomed. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 1 18:02:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17835 for ; Tue, 1 Jul 2003 18:02:12 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6785E53690; Tue, 1 Jul 2003 18:01: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 573275376C for ; Tue, 1 Jul 2003 17:56:28 -0400 (EDT) Received: (qmail 25576 invoked by uid 3269); 1 Jul 2003 21:56:27 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25567 invoked from network); 1 Jul 2003 21:56:26 -0000 Received: from sj-core-2.cisco.com (171.71.177.254) by klesh.pair.com with SMTP; 1 Jul 2003 21:56:26 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h61Lu62K025908; Tue, 1 Jul 2003 14:56:07 -0700 (PDT) Message-ID: <3F020376.814F9CDB@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: Sead Muftic , msec@securemulticast.org Subject: Re: [MSEC] CSPRI Implementation of the GSAKMP References: <3.0.32.20030630131940.003e9c78@mail.dsv.su.se> <3F008FDA.5030101@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 01 Jul 2003 14:56:06 -0700 Content-Transfer-Encoding: 7bit Lakshminath Dondeti wrote: > > 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. I've just glanced at the -03 version that Thomas just mentioned, and it seems to me that there are more details then there used to be. > 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?) Yes, that is a fair summary. In fact, there were just a few subtle ambiguities that were realized, but finding them was invaluable. I'm wondering if this was also true with the GSAKMP implementations? 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 -- 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 Jul 1 18:09:56 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18569 for ; Tue, 1 Jul 2003 18:09:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 29FD153776; Tue, 1 Jul 2003 18:09: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 B48DA53683 for ; Tue, 1 Jul 2003 18:06:05 -0400 (EDT) Received: (qmail 26680 invoked by uid 3269); 1 Jul 2003 22:06:05 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26677 invoked from network); 1 Jul 2003 22:06:05 -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; 1 Jul 2003 22:06:05 -0000 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 01 Jul 2003 15:07:03 -0700 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h61M62wM010232; Tue, 1 Jul 2003 15:06:02 -0700 (PDT) Message-ID: <3F0205C9.B3C05349@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: "Kenny, Gavin (Space)" Cc: "'Mark Baugher'" , Laurence.Duquerroy@space.alcatel.fr, Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org References: Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [MSEC] Re: Reliability & Secure Multicast Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 01 Jul 2003 15:06:01 -0700 Content-Transfer-Encoding: 8bit Hi Gavin, "Kenny, Gavin (Space)" wrote: > > Hi, Just to add my 2p worth. > > We're running a project which has produced a GSAKMP/LKH implementation for > use over satellite networks. We have been running the system using a > satellite link simulator with an error rate of 10-3 and a delay of 0.25s and > it works great! > > All we did was to have all re-key messages repeated three times, one after > another. In the past, we have postulated in MSEC that this simple method would usually be satisfactory for most IP multicast networks. I'm glad to hear that your experience that it indeed seems to be the case. It would be interesting to hear from anyone else who has done real world testing too. Thanks, Brian > Considering that most modern sat systems say they can give you an error rate > of approx 10-7 or better, I don't think reliability is much of an issue in > real world applications. I appreciate it is nice to close the loop, as it > were, but I think the downside of using up valuable bandwidth and time (in a > long transmission delay environment) with acks and nacks is hard to justify. > > I would vote on keeping reliability in a separate layer as multicast is > great for satellite transmission but a constant return path is not always > available. > > regards > > Gavin > > -----Original Message----- > From: Mark Baugher [mailto:mbaugher@cisco.com] > Sent: 27 June 2003 16:14 > To: Laurence.Duquerroy@space.alcatel.fr > Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath Dondeti; > msec@securemulticast.org > Subject: [MSEC] Re: [MSEC] Réf. : Re: [MSEC] Réf. : Re: [ MSEC] R éf. : > [MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] > > 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 > > This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- 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 Jul 2 06:53:18 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02120 for ; Wed, 2 Jul 2003 06:53:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 292D25374A; Wed, 2 Jul 2003 06:52: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 7CE7E537EB for ; Wed, 2 Jul 2003 06:50:16 -0400 (EDT) Received: (qmail 78622 invoked by uid 3269); 2 Jul 2003 10:50:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78619 invoked from network); 2 Jul 2003 10:50:16 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 2 Jul 2003 10:50:16 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01348; Wed, 2 Jul 2003 06:50:12 -0400 (EDT) Message-Id: <200307021050.GAA01348@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-gsakmp-sec-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 02 Jul 2003 06:50:12 -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 : GSAKMP Author(s) : H. Harney et al. Filename : draft-ietf-msec-gsakmp-sec-02.txt Pages : 52 Date : 2003-7-1 This document specifies the Group Secure Association Key Management Protocol (GSAKMP). The GSAKMP provides a security framework for creating and managing cryptographic groups on a network. It provides mechanisms to disseminate group policy and authenticate users, rules to perform access control decisions during group establishment and recovery, capabilities to recover from the compromise of group members, delegation of group security functions, and capabilities to destroy the group. It also generates group keys. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gsakmp-sec-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-1142701.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gsakmp-sec-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-1142701.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 Jul 2 09:11:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15113 for ; Wed, 2 Jul 2003 09:11:26 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E412853844; Wed, 2 Jul 2003 09:10:56 -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 BC7C753884 for ; Wed, 2 Jul 2003 09:08:57 -0400 (EDT) Received: (qmail 934 invoked by uid 3269); 2 Jul 2003 13:08:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 923 invoked from network); 2 Jul 2003 13:08:57 -0000 Received: from colt-na7.alcatel.fr (HELO smail3.alcatel.fr) (62.23.212.7) by klesh.pair.com with SMTP; 2 Jul 2003 13:08:57 -0000 Received: from vzmta01.netfr.alcatel.fr (vzmta01.netfr.alcatel.fr [155.132.210.38]) by smail3.alcatel.fr (ALCANET/NETFR) with SMTP id h62D8bhO011429; Wed, 2 Jul 2003 15:08:39 +0200 Received: by vzmta01.netfr.alcatel.fr(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id C1256D57.0047EC20 ; Wed, 2 Jul 2003 15:05:35 +0200 X-Lotus-FromDomain: ALCATEL-SPACE From: Laurence.Duquerroy@space.alcatel.fr To: "Kenny, Gavin (Space)" , "'Mark Baugher'" Cc: Brian Weis , Sebastien.Josset@space.alcatel.fr, 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._:_Reliability_&_Secure_Multicast?= Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 2 Jul 2003 15:06:22 +0200 Content-Transfer-Encoding: quoted-printable Hi Gavin, >We're running a project which has produced a GSAKMP/LKH implementation= for >use over satellite networks. We have been running the system using a >satellite link simulator with an error rate of 10-3 and a delay of 0.2= 5s and >it works great! Your results seems very interesting, we would be very interested in rea= ding more about them. Do you have some public reports or publications available ?= We just have one question about your error rate of 10-3. Is it the bit = error rate after decoding or the packet error rate at MAC or network level ( = at key exchange level)? Besides, concerning your delay of 0.25 s, does it not seem to be a litt= le bit short? Are you targeting one-way broadcast only satellite systems ? Ind= eed, with DAMA algorithms for the return link (user terminal to hub), for sporadi= c low bit rate, the delay can be between 0.25 and 2 s. However we don?t totally agree with you about the need of reliability m= echanisms in group key management protocols for satellite systems. The "world of satellite systems" is composed of two main system types := Fixe broadband systems ( i.e. TV broadcasting) and Mobile systems. Three optimized retransmissions of all re-key messages seem to fulfill = the needs of fixe broadcast systems without return link, that have an overprovisi= onned and stable link budget. However, in mobile systems or versatile systems (fa= st network inputs/outputs) , or heterogeneous systems, even with three retransmissions, it is not certain at all that each group member receiv= es all re-keying messages. Reliability mechanisms ( based on Nack/ack) would b= e needed. Finally, it seems easier and more optimized to add some reliability mec= hanisms to Group Key Management protocols (such as GSAKMP) compared to the use = of a reliable multicast transport protocol which shall also be secured (sign= ature of the Acks/Nacks) (Nowadays attacks are successfully launched on TCP exch= anges). Indeed, as adding lightweight reliability features in GSAKMP optimised = for our needs can be done for a very low cost, we don't see the need to use an = external multicast reliable protocol with its own additional signaling and byte = overhead for authentication and integrity check... > Finally, I don't see any difference between your Phase 3 and the MS= EC >Rekey protocol (called "groupkey push" in GDOI). Are there significan= t >differences? Sorry for my slow response to Mark's question (from the mail below). Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only dif= ference is ... the use of reliability mechanisms (i.e. the use of Nacks and mes= sages from the GCKS indicating the last used sequence number). Best regards, Laurence 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 >Hi, Just to add my 2p worth. >We're running a project which has produced a GSAKMP/LKH implementation= for >use over satellite networks. We have been running the system using a >satellite link simulator with an error rate of 10-3 and a delay of 0.2= 5s and >it works great! >All we did was to have all re-key messages repeated three times, one a= fter >another. >Considering that most modern sat systems say they can give you an erro= r rate >of approx 10-7 or better, I don't think reliability is much of an issu= e in >real world applications. I appreciate it is nice to close the loop, as= it >were, but I think the downside of using up valuable bandwidth and time= (in a >long transmission delay environment) with acks and nacks is hard to ju= stify. >I would vote on keeping reliability in a separate layer as multicast i= s >great for satellite transmission but a constant return path is not alw= ays >available. >regards >Gavin >-----Original Message----- >From: Mark Baugher [mailto:mbaugher@cisco.com] >Sent: 27 June 2003 16:14 >To: Laurence.Duquerroy@space.alcatel.fr >Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath Dondeti= ; >msec@securemulticast.org >Subject: [MSEC] Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : Re: [ MSEC] R = =E9f. : >[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] >Laurence, > We discussed putting reliability mechanisms into GDOI about three y= ears >ago. The decision of the secure multicast research group (SMuG) at th= at >time was to use the mechanisms that are being developed by another gro= up, >the reliable multicast group, rather than develop our own. MSEC has a= lso >taken this approach. > So, before we incorporate reliable multicast into an MSEC key manag= ement >protocol, we need to revisit this decision and discuss the pro's and c= on's >of having an ACK or NAK mechanism built into key management versus usi= ng 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 be= st >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 th= e key >management protocol. > Now, what are the advantages to mixing up reliable multicast with k= ey >establishment? > Finally, I don't see any difference between your Phase 3 and the MS= EC >Rekey protocol (called "groupkey push" in GDOI). Are there significan= t >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 >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec >This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary >material, confidential information and/or be subject to legal privilege. It should not be cop= ied, disclosed to, >retained or used by, any other party. If you are not an= intended recipient then please promptly delete this e-mail >and any attachment a= nd all copies and inform the sender. Thank you. = _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 2 10:16:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22641 for ; Wed, 2 Jul 2003 10:16:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A094A53800; Wed, 2 Jul 2003 10:16:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id AB16C53686 for ; Wed, 2 Jul 2003 10:14:59 -0400 (EDT) Received: (qmail 11104 invoked by uid 3269); 2 Jul 2003 14:08:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 11100 invoked from network); 2 Jul 2003 14:08:17 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 2 Jul 2003 14:08:17 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h62E8Gch011783 for ; Wed, 2 Jul 2003 07:08:16 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.169 [10.26.128.169]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYL07L9N; Wed, 2 Jul 2003 07:08:15 -0700 Message-Id: <5.2.1.1.2.20030702100424.022c8868@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 Subject: Clarification -- Re: [MSEC] I-D ACTION:draft-ietf-msec-gsakmp-sec-02.txt In-Reply-To: <200307021050.GAA01348@ietf.org> 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, 02 Jul 2003 10:08:08 -0400 Folks, There has been some mis-synchronization with regards to the version-numbering of the GSAKMP draft. Although it bears the version number -02, the version should actually be the next number up. However, in order to be in-step with the IETF database, we'll just stay with -02 for the version number. (The next update to the GSAKMP will have version number -03). thomas ------ At 7/2/2003||06:50 AM, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : GSAKMP > Author(s) : H. Harney et al. > Filename : draft-ietf-msec-gsakmp-sec-02.txt > Pages : 52 > Date : 2003-7-1 > >This document specifies the Group Secure Association Key >Management Protocol (GSAKMP). The GSAKMP provides a security >framework for creating and managing cryptographic groups on a >network. It provides mechanisms to disseminate group policy and >authenticate users, rules to perform access control decisions >during group establishment and recovery, capabilities to recover >from the compromise of group members, delegation of group security >functions, and capabilities to destroy the group. It also >generates group keys. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt > >To remove yourself from the IETF Announcement list, send a message to >ietf-announce-request with the word unsubscribe in the body of the message. > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-msec-gsakmp-sec-02.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <2003-7-1142701.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-msec-gsakmp-sec-02.txt > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 2 10:53:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25828 for ; Wed, 2 Jul 2003 10:53:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A6CE536C9; Wed, 2 Jul 2003 10:53:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B15C1535CF for ; Wed, 2 Jul 2003 10:50:14 -0400 (EDT) Received: (qmail 21975 invoked by uid 3269); 2 Jul 2003 14:50:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21967 invoked from network); 2 Jul 2003 14:50:14 -0000 Received: from smtp2.su.se (130.237.93.212) by klesh.pair.com with SMTP; 2 Jul 2003 14:50:14 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id D00C9200169; Wed, 2 Jul 2003 16:50:13 +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 15542-03; Wed, 2 Jul 2003 16:50:13 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id 874322000BB; Wed, 2 Jul 2003 16:50:13 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id A45E63D384; Wed, 2 Jul 2003 16:50:12 +0200 (MET DST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id B951C3D357; Wed, 2 Jul 2003 16:50:11 +0200 (MET DST) Message-Id: <3.0.32.20030702105010.00ab4f88@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: Windows Eudora Pro Version 3.0 (32) To: Brian Weis , 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: Wed, 02 Jul 2003 10:50:11 -0400 Brian and other MSEC friends: > >I'm wondering if this was also true with the GSAKMP implementations? > As I announced, our implementation is based on the first version of the GSAKMP. The reason we didn't follow upgrades is very simple: we were waiting for the protocol to become stable (standard), then we will upgrade our implementation in the second year of the project (Sept 2003 - Sept 2004). In addition, we have also designed and implemented a comprehensive security architecture for the GSA system, so (for shortage of manpower), we couldn't concentrate strictly on the GSAKMP. But, the upgrade to the (soon to be) official standard is definitely one of our future tasks. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 2 11:01:06 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26132 for ; Wed, 2 Jul 2003 11:01:04 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5AB07536C9; Wed, 2 Jul 2003 11:00:36 -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 6153A535CF for ; Wed, 2 Jul 2003 10:58:41 -0400 (EDT) Received: (qmail 23290 invoked by uid 3269); 2 Jul 2003 14:58:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23287 invoked from network); 2 Jul 2003 14:58:41 -0000 Received: from smtp2.su.se (130.237.93.212) by klesh.pair.com with SMTP; 2 Jul 2003 14:58:41 -0000 Received: from localhost (smtp2.su.se [127.0.0.1]) by smtp2.su.se (Postfix) with ESMTP id F0A6C2001F8; Wed, 2 Jul 2003 16:58:40 +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 15933-03; Wed, 2 Jul 2003 16:58:40 +0200 (CEST) Received: from unni.dsv.su.se (unni.dsv.su.se [130.237.161.27]) by smtp2.su.se (Postfix) with ESMTP id 3CEDC2000BB; Wed, 2 Jul 2003 16:58:40 +0200 (CEST) Received: from unni.dsv.su.se (localhost [127.0.0.1]) by spamcheck.local (Postfix) with ESMTP id 4DCD73D357; Wed, 2 Jul 2003 16:58:39 +0200 (MET DST) Received: from SeadMuftic (r2d2.cpi.seas.gwu.edu [128.164.82.43]) by unni.dsv.su.se (Postfix) with SMTP id CA6CD3D385; Wed, 2 Jul 2003 16:58:37 +0200 (MET DST) Message-Id: <3.0.32.20030702105836.00ab4f88@mail.dsv.su.se> X-Sender: sead@mail.dsv.su.se X-Mailer: Windows Eudora Pro Version 3.0 (32) To: Brian Weis , "Kenny, Gavin (Space)" From: Sead Muftic Subject: Re: [MSEC] Re: Reliability & Secure Multicast Cc: "'Mark Baugher'" , Laurence.Duquerroy@space.alcatel.fr, Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , 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: Wed, 02 Jul 2003 10:58:38 -0400 Brian and other MSEC Friends: >It would be interesting to hear from anyone else who has done real world >testing too. We have done some research on reliability and survivability of a secure group communication system and also some initial real life tests. First, we did not consider reliability in a sense of a stable, continuous and reliable multicast communications, but more as the issues of reliability and stability of the complete GSA system in a sense of providing continuous operations to group members, even in case of unavailability of some GSA components and/or roles. I have produced a research paper entitled "A Survivable Group Security Architecture" which I submitted to the ACM Workshop (10th Annual ACM Security Conference), so if someone is interested, please drop me a note. We have also performed some initial tests with SELinux, running GSAKMP controller (server) under SELinux, which provides additional protection of GSAKMP resources and operations. Regards, Sead Muftic CSPRI/GWU _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 2 16:36:16 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14150 for ; Wed, 2 Jul 2003 16:36:15 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7EE9053939; Wed, 2 Jul 2003 16:35:13 -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 ED7D453933 for ; Wed, 2 Jul 2003 16:33:28 -0400 (EDT) Received: (qmail 85148 invoked by uid 3269); 2 Jul 2003 20:33:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85129 invoked from network); 2 Jul 2003 20:33:24 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 2 Jul 2003 20:33:24 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12757; Wed, 2 Jul 2003 16:32:31 -0400 (EDT) Message-Id: <200307022032.QAA12757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-dhhmac-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 02 Jul 2003 16:32:31 -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 : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-02.txt Pages : 27 Date : 2003-7-2 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-2161606.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161606.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 Jul 2 16:36:56 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14413 for ; Wed, 2 Jul 2003 16:36:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5BD0C5386A; Wed, 2 Jul 2003 16:35: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 93E6E5386A for ; Wed, 2 Jul 2003 16:33:26 -0400 (EDT) Received: (qmail 85135 invoked by uid 3269); 2 Jul 2003 20:33:26 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85128 invoked from network); 2 Jul 2003 20:33:24 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 2 Jul 2003 20:33:24 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12719; Wed, 2 Jul 2003 16:32:27 -0400 (EDT) Message-Id: <200307022032.QAA12719@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-gkmarch-05.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, 02 Jul 2003 16:32:27 -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 : Group Key Management Architecture Author(s) : M. Baugher et al. Filename : draft-ietf-msec-gkmarch-05.txt Pages : 32 Date : 2003-7-2 This document presents the group key management architecture for MSEC. The purpose of this document is to define the common architecture for MSEC group key-management protocols that support a variety of application, transport, and internetwork security protocols. To address these diverse uses, MSEC may need to standardize two or more group key management protocols that have common requirements, abstractions, overall design, and messages. The framework and guidelines in this document allow for a modular and flexible design of group key management protocols for a variety of different settings that are specialized to application needs. Comments on this document should be sent to msec@securemulticast.org. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-gkmarch-05.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-gkmarch-05.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-gkmarch-05.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-7-2161556.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-2161556.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 Jul 2 23:59:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13805 for ; Wed, 2 Jul 2003 23:59:45 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7D1875369B; Wed, 2 Jul 2003 23: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 F0DFB5369B for ; Wed, 2 Jul 2003 23:54:50 -0400 (EDT) Received: (qmail 28965 invoked by uid 3269); 3 Jul 2003 03:54:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28960 invoked from network); 3 Jul 2003 03:54:50 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 3 Jul 2003 03:54:50 -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 h633roq107794; Wed, 2 Jul 2003 23:53: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 h633sh8128448; Wed, 2 Jul 2003 23:54:43 -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 XAA30750; Wed, 2 Jul 2003 23:54:42 -0400 From: canetti To: Lakshminath Dondeti Cc: Thomas Hardjono , msec@securemulticast.org, housley@vigilsec.com, smb@research.att.com, thardjono@yahoo.com Subject: Re: [MSEC] re-Charter of MSEC and milestones In-Reply-To: <3F01EBB6.6030503@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, 2 Jul 2003 23:54:42 -0400 (EDT) Any of the GSAKMP authors care to comment on that? Would you like to postpone your deadline to be aligned with the policy token document? Ran On Tue, 1 Jul 2003, Lakshminath Dondeti wrote: > Thomas and Ran, > > What about the Policy Token I-D (draft-ietf-msec-tokenspec-sec-00.txt) > in the charter timeline? It appears that GSAKMP is closely tied in > with that spec, so I guess it is better to have them go to last call > simultaneously. > > regards, > Lakshminath > > > Thomas Hardjono wrote: > > > > [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 > > > > > > _______________________________________________ > 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 Jul 3 11:29:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15713 for ; Thu, 3 Jul 2003 11:29:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1AA4353847; Thu, 3 Jul 2003 11:28: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 544285354C for ; Thu, 3 Jul 2003 11:27:40 -0400 (EDT) Received: (qmail 79790 invoked by uid 3269); 3 Jul 2003 15:27:40 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 79787 invoked from network); 3 Jul 2003 15:27:40 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 3 Jul 2003 15:27:40 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2003 08:24:25 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn2-590.cisco.com [10.21.114.78]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h63FRZpa006359; Thu, 3 Jul 2003 08:27:36 -0700 (PDT) Message-Id: <5.1.1.5.2.20030703073326.05f6d9c8@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: "Kenny, Gavin (Space)" , Brian Weis , Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [MSEC] =?iso-8859-1?Q?Re:_R=E9f._:_Reliability_&_Secure_Multicast?= Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 03 Jul 2003 08:27:35 -0700 Content-Transfer-Encoding: quoted-printable Laurence, At 03:06 PM 7/2/2003 +0200, Laurence.Duquerroy@space.alcatel.fr wrote: <...> >However we don?t totally agree with you about the need of reliability=20 >mechanisms >in group key management protocols for satellite systems. >The "world of satellite systems" is composed of two main system types := Fixe >broadband systems ( i.e. TV broadcasting) and Mobile systems. >Three optimized retransmissions of all re-key messages seem to fulfill the= =20 >needs >of fixe broadcast systems without return link, that have an=20 >overprovisionned and >stable link budget. However, in mobile systems or versatile systems (fast >network inputs/outputs) , or heterogeneous systems, even with three >retransmissions, it is not certain at all that each group member receives= all >re-keying messages. Reliability mechanisms ( based on Nack/ack) would be=20 >needed. >Finally, it seems easier and more optimized to add some reliability= mechanisms >to Group Key Management protocols (such as GSAKMP) compared to the use of = a >reliable multicast transport protocol which shall also be secured=20 >(signature of >the Acks/Nacks) (Nowadays attacks are successfully launched on TCP= exchanges). I don't think this makes the case why msec should build a reliable=20 multicast protocol into its key management. The arguments for using a=20 reliable multicast protocol rather than incorporating one probably include= =20 the following. 1. allows us to select the best protocol for a particular application=20 environment 2. allows us to introduce better protocols when they are developed 3. reduces the functionality and the complexity of the key management= protocol Are there others? Probably the best (maybe the only) argument for including it in the key=20 management is security. We need to answer the following questions. 1. How can the security of the key management protocol be successfully=20 undermined by attacking the reliable multicast protocol and is this true=20 for all interesting reliable-multicast protocols. 2. How can incorporation of the reliable multicast protocol into the key=20 management protocol protect against these attacks? 3. Is it possible to protect against these attacks without putting the=20 reliable multicast protocol into the key management protocol. Are there others? It's good that you raise this issue now in msec because the previous=20 discussion we had was some time ago in msec's predecessor group, IRTF SMuG. Mark >Indeed, as adding lightweight reliability features in GSAKMP optimised for= our >needs can be done for a very low cost, we don't see the need to use an=20 >external >multicast reliable protocol with its own additional signaling and byte=20 >overhead >for authentication and integrity check... > > > > > > 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? > >Sorry for my slow response to Mark's question (from the mail below). >Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only= difference >is ... the use of reliability mechanisms (i.e. the use of Nacks and= messages >from the GCKS indicating the last used sequence number). > > >Best regards, > >Laurence > >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 > > > > >Hi, Just to add my 2p worth. > > >We're running a project which has produced a GSAKMP/LKH implementation= for > >use over satellite networks. We have been running the system using a > >satellite link simulator with an error rate of 10-3 and a delay of 0.25s= and > >it works great! > > >All we did was to have all re-key messages repeated three times, one= after > >another. > > >Considering that most modern sat systems say they can give you an error= rate > >of approx 10-7 or better, I don't think reliability is much of an issue= in > >real world applications. I appreciate it is nice to close the loop, as it > >were, but I think the downside of using up valuable bandwidth and time= (in a > >long transmission delay environment) with acks and nacks is hard to= justify. > > >I would vote on keeping reliability in a separate layer as multicast is > >great for satellite transmission but a constant return path is not always > >available. > > >regards > > >Gavin > > > > >-----Original Message----- > >From: Mark Baugher [mailto:mbaugher@cisco.com] > >Sent: 27 June 2003 16:14 > >To: Laurence.Duquerroy@space.alcatel.fr > >Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath Dondeti; > >msec@securemulticast.org > >Subject: [MSEC] Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : Re: [ MSEC] R =E9= f. : > >[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] > > > >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 > > > >_______________________________________________ > >msec mailing list > >msec@securemulticast.org > >http://www.pairlist.net/mailman/listinfo/msec > > >This e-mail and any attachment is for authorised use by the intended >recipient(s) only. It may contain proprietary >material, confidential >information and/or be subject to legal privilege. It should not be copied, >disclosed to, >retained or used by, any other party. If you are not an=20 >intended >recipient then please promptly delete this e-mail >and any attachment and= all >copies and inform the sender. Thank you. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 3 12:54:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24423 for ; Thu, 3 Jul 2003 12:54:23 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id ED4F55393A; Thu, 3 Jul 2003 12:53: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 159D25393E for ; Thu, 3 Jul 2003 12:51:12 -0400 (EDT) Received: (qmail 93311 invoked by uid 3269); 3 Jul 2003 16:51:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93308 invoked from network); 3 Jul 2003 16:51:12 -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; 3 Jul 2003 16:51:12 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 03 Jul 2003 09:52:36 -0700 Received: from cisco.com (stealth-10-32-244-211.cisco.com [10.32.244.211]) by sj-core-3.cisco.com (8.12.6/8.12.6) with SMTP id h63Gp9pZ024735 for ; Thu, 3 Jul 2003 09:51:10 -0700 (PDT) Message-ID: <3F045EFD.34CEB22B@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] RFC 3547 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, 03 Jul 2003 09:51:09 -0700 Content-Transfer-Encoding: 7bit GDOI has now been published as an RFC. Thanks to everyone who helped make this a reality! ftp://ftp.rfc-editor.org/in-notes/rfc3547.txt Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 4 22:25:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15225 for ; Fri, 4 Jul 2003 22:25:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 024E353568; Fri, 4 Jul 2003 22:24: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 68A2653568 for ; Fri, 4 Jul 2003 22:23:23 -0400 (EDT) Received: (qmail 23957 invoked by uid 3269); 5 Jul 2003 02:23:23 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 23952 invoked from network); 5 Jul 2003 02:23:23 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 5 Jul 2003 02:23:23 -0000 Received: (qmail 63502 invoked from network); 5 Jul 2003 02:23:22 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 5 Jul 2003 02:23:22 -0000 Received: (qmail 4461 invoked from network); 5 Jul 2003 02:23:22 -0000 Received: from unknown (HELO nsx.garage) (64.21.175.41) by mail.nac.net with SMTP; 5 Jul 2003 02:23:22 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h650JdO02522; Fri, 4 Jul 2003 20:19:39 -0400 From: George Gross To: Andrea Colegrove Cc: , , Subject: Re: [MSEC] A few questions on GSAKMP (long) In-Reply-To: <3F01BFA3.4020907@columbia.sparta.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: Fri, 4 Jul 2003 20:19:39 -0400 (EDT) Hi Andrea, I have been taking a quick look at GSAKMP v03, and consequently some of my comments may be off the mark because it was such a quick look. In several cases, there is an omission of detail in the specification for some "first mention" passages, albeit later in the spec you add details For example in section 4.2.1.2, the spec says: "The Policy Token and Key Download payloads are sent encrypted in the KEK generated by the Key Creation payload information using the mechanisms defined in the group announcment." However, the group announcement is done out of band and it is not defined within this specification. Yet here it directly impacts what algorithms and key lengths one would expect to encounter in the Key Download message. This seems to be a place where you would say something like: "...using the mechanisms defined in the group announcement, which are required to be identical to the set defined for IKEv2, or the IANA registry's current set of algorithms. This includes the same MUST implement requirements as IKEv2" or some words to that effect (wordsmithing TBD). Or did you really mean to say "group policy token" rather than group announcement? In the Request To Join (RTJ) message, the spec says that the GCKS must verify each of the fields in that message, including the nonce. However, there was no mention of any anti-replay mechanism that would have assured the freshness of that nonce. Does the GCKS implicitly keep a list of nonces used per GM? If so, this section should say so. I infer that I'm missing something that was probably not said explicitly in this text (section 4.2.1.1). In other words, please specify what it means to verify the nonce field, and for that matter, any of the other fields: e.g. the group identifier must have some kind of list that the GKCS consults to know who are possible authorized members. I would have thought that table 6 should have included a group identification type definition for IPv6 as well as IPv4. Does GSAKMP work with IPv6? Several sections mention the optional use of LKH. Could you please indicate the intellectual property status of LKH? For that matter, any other aspects of GSAKMP? Is there a way to add vendor-specific extensions to the RTJ, Key Download, Rekey, and other messages? If so, please create a paragraph that discusses that capability. If not, I'd like to ask that capability be created in the protocol. Regretably, I am leaving on vacation tomorrow, and will be offline until 7/16. I apologize for the awkward timing, but I decided that if I didn't offer comments now, the door might be closed by the time I returned. If it turns out my quick review was so quick that I overlooked things that answered my above questions, I'd certainly stand corrected, and will look more closely once I'm back ;o) br, George Gross _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Jul 6 13:18:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17671 for ; Sun, 6 Jul 2003 13:18:29 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id AC21B53684; Sun, 6 Jul 2003 13:18: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 5AEDB535E3 for ; Sun, 6 Jul 2003 13:17:08 -0400 (EDT) Received: (qmail 16100 invoked by uid 3269); 6 Jul 2003 17:17:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16097 invoked from network); 6 Jul 2003 17:17:08 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 6 Jul 2003 17:17:08 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h66HH2ch004507 for ; Sun, 6 Jul 2003 10:17:07 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.120 [10.26.128.120]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id LYMAF8G4; Sun, 6 Jul 2003 10:17:00 -0700 Message-Id: <5.2.1.1.2.20030706131342.022c8d10@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] Tentative MSEC Agenda for IETF57 Vienna (as of Sun 6 July) 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, 06 Jul 2003 13:16:53 -0400 Folks, Here is the tentative Agenda for the MSEC working group 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) - DHHMAC update (M. Euchner) - 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 Mon Jul 7 08:31:19 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22845 for ; Mon, 7 Jul 2003 08:31:18 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 94A38536F1; Mon, 7 Jul 2003 08:30: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 6AE1B536BA for ; Mon, 7 Jul 2003 08:23:31 -0400 (EDT) Received: (qmail 21316 invoked by uid 3269); 7 Jul 2003 12:23:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21313 invoked from network); 7 Jul 2003 12:23:31 -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; 7 Jul 2003 12:23:31 -0000 Received: from esealnt610.al.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 h67CNTIi009907; Mon, 7 Jul 2003 14:23:29 +0200 (MEST) Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2655.55) id ; Mon, 7 Jul 2003 14:24:13 +0200 Message-ID: <1F55F6582266314A85A55F6241509B6707EF4CC4@Esealnt863.al.sw.ericsson.se> From: "Fredrik Lindholm (KI/EAB)" To: "'Euchner Martin'" , msec@securemulticast.org MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [MSEC] RE: I-D ACTION:draft-ietf-msec-mikey-07.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, 7 Jul 2003 14:22:18 +0200 Hi Martin, still problem with the mailing list I see (have you tried to re-subscribe?). Anyway, thanks for the comments, see inline. > -----Original Message----- > From: Euchner Martin [mailto:martin.euchner@siemens.com] > Sent: den 7 juli 2003 11:26 > To: msec@securemulticast.org; Euchner Martin; Fredrik > Lindholm (KI/EAB) > Subject: RE: I-D ACTION:draft-ietf-msec-mikey-07.txt > > > Fredrik, > > Let me raise a couple of issues upon MIKEY-07: > > > 1.) I can see in section 4.2.3 that MIKEY-07 references the > AES-key wrap function as a new optional key transport method: > > The AES key wrap function [AESKW] is included as an > optional (but not > mandatory to implement) method. If the key wrap function > is used, the > NULL MAC is RECOMMENDED to be used when using the public key method > (NOT the pre-shared key method) as the key wrap itself will provide > integrity of the keys. The 128-bit key and a 64-bit salt, S, are > derived in accordance to Section 4.1.5 and the key wrap IV is then > set to S. > > RFC 3394 (that defines the AES-KW) defines OID(s) for the key > wrap algorithm. Where in MIKEY does one have to put that OID > (i.e I believe id-aes128-wrap is the only OID that would > apply to MIKEY at present, the other OIDs currently do not > make much sense for MIKEY). That should be clarified. We do not use the OID (see below). > 1.1) Or asked more generally: How does the recipient know > which key transport method (MIKEY default or AES-key wrap) is > being used? The algorithm used for key encryption is signaled in the KEMAC payload (see Section 6.2). > 2.) Section 6.5 now lists the applied signature algorithm by > the sender: > > S type | Value | Comments > ------------------------------------- > RSA/PKCS#1/1.5| 0 | Denotes a PKCS #1 version 1.5 signature > RSA/PSS | 1 | Denotes a PSS signature > > While the reference section lists a PKCS#1 reference, I can't > find any (normative) references to RSA/PSS. I assume that > this one should be added to the normative references too. Yes > BTW: The PKCS#1 reference is probably not in the most > appropriate shape: > > [PKCS1] PKCS #1 - RSA Cryptography Standard, > http://www.rsalabs.com/pkcs/pkcs-1/ > > We should try to reference some more official (IETF) > document: Ok > Let me recommend to >>normatively<< reference RFC > (2313/2437/) 3447 instead (see below): > > 2313 PKCS #1: RSA Encryption Version 1.5. B. Kaliski. March 1998. > (Format: TXT=37777 bytes) (Obsoleted by RFC2437) (Status: > INFORMATIONAL) > > 2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, > J. Staddon. October 1998. (Format: TXT=73529 bytes) (Obsoletes > RFC2313) (Obsoleted by RFC3447) (Status: INFORMATIONAL) > > 3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography > Specifications Version 2.1. J. Jonsson, B. Kaliski. > February 2003. > (Format: TXT=143173 bytes) (Obsoletes RFC2437) (Status: > INFORMATIONAL) > > Problem: Version 1.5 (RFC 2313) is no longer in force, > neither is Version 2.0. The RFC index indicates RFC 3447 > being in force, however that refers to RSA spec 2.1; thus > section 6.5 would have to be changed. > > > 3.) For completeness, may I request to add the MIKEY-DHHMAC > as an informative reference? Ok Cheers, Fredrik > With kind regards > > Martin Euchner. > -------------------------------------------------------------- > --------- > | Dipl.-Inf. Rapporteur Q.G/SG16 > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | ICN M SR 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > -------------------------------------------------------------- > --------- > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 7 12:52:20 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03487 for ; Mon, 7 Jul 2003 12:52:19 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 995F953637; Mon, 7 Jul 2003 12:51: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 19F7953561 for ; Mon, 7 Jul 2003 11:48:58 -0400 (EDT) Received: (qmail 59626 invoked by uid 3269); 7 Jul 2003 15:48:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59623 invoked from network); 7 Jul 2003 15:48:58 -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; 7 Jul 2003 15:48:58 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn1-493.cisco.com [10.21.97.237]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h67Fmspa027227; Mon, 7 Jul 2003 08:48:55 -0700 (PDT) Message-Id: <5.1.1.5.2.20030707084801.05a69688@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] A few questions on GSAKMP (long) Cc: In-Reply-To: References: <3F01BFA3.4020907@columbia.sparta.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 07 Jul 2003 08:48:53 -0700 At 08:19 PM 7/4/2003 -0400, George Gross wrote: <...> >Several sections mention the optional use of LKH. Could you please >indicate the intellectual property status of LKH? For that matter, any >other aspects of GSAKMP? Regarding LKH, it's in the public domain to my knowledge. Mark >Is there a way to add vendor-specific extensions to the RTJ, Key Download, >Rekey, and other messages? If so, please create a paragraph that discusses >that capability. If not, I'd like to ask that capability be created in the >protocol. > > >Regretably, I am leaving on vacation tomorrow, and will be offline until >7/16. I apologize for the awkward timing, but I decided that if I didn't >offer comments now, the door might be closed by the time I returned. If it >turns out my quick review was so quick that I overlooked things that >answered my above questions, I'd certainly stand corrected, and will look >more closely once I'm back ;o) > >br, > George Gross > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 15 06:08:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12135 for ; Tue, 15 Jul 2003 06:08:06 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id F392D53797; Tue, 15 Jul 2003 06:06:01 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D82BE53674 for ; Tue, 15 Jul 2003 06:04:14 -0400 (EDT) Received: (qmail 19471 invoked by uid 3269); 15 Jul 2003 10:04:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 19468 invoked from network); 15 Jul 2003 10:04:14 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 15 Jul 2003 10:04:14 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6FA4Dch020650 for ; Tue, 15 Jul 2003 03:04:13 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.118 [10.26.128.118]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XFY7GS8; Tue, 15 Jul 2003 03:04:13 -0700 Message-Id: <5.2.1.1.2.20030715060340.02389d90@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] test - please ignore Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 15 Jul 2003 06:04:02 -0400 test - please ignore _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 15 06:56:02 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13725 for ; Tue, 15 Jul 2003 06:56:01 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9F5E95377E; Tue, 15 Jul 2003 06:54:20 -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 CFB5E53758 for ; Tue, 15 Jul 2003 06:53:43 -0400 (EDT) Received: (qmail 26122 invoked by uid 3269); 15 Jul 2003 10:53:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26119 invoked from network); 15 Jul 2003 10:53:43 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 15 Jul 2003 10:53:43 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6FArhch027252 for ; Tue, 15 Jul 2003 03:53:43 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.118 [10.26.128.118]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XFY72HP; Tue, 15 Jul 2003 03:53:42 -0700 Message-Id: <5.2.1.1.2.20030715064536.022a7398@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] Closing date for MIKEY wg last call Friday 1 August 2003 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, 15 Jul 2003 06:53:08 -0400 Folks, One of the action items resulting from last night's MSEC WG meeting in Vienna was the need to end the WG Last Call process for MIKEY, which was started at the last IETF-56. The date chosen is Friday 1 August 2003. Please review the MIKEY draft. If you have further issues/comments regarding MIKEY, please send it immediately to the mailing list. Regards. Thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 15 07:09:22 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14037 for ; Tue, 15 Jul 2003 07:09:22 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2DFF853729; Tue, 15 Jul 2003 07:08:20 -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 966DB536C2 for ; Tue, 15 Jul 2003 07:07:06 -0400 (EDT) Received: (qmail 27529 invoked by uid 3269); 15 Jul 2003 11:07:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 27526 invoked from network); 15 Jul 2003 11:07:06 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 15 Jul 2003 11:07:06 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6FB75ch029099 for ; Tue, 15 Jul 2003 04:07:05 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.118 [10.26.128.118]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XFY72VZ; Tue, 15 Jul 2003 04:07:05 -0700 Message-Id: <5.2.1.1.2.20030715070433.022b2850@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] Lost/found items in Hall G after MSEC meeting last night 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, 15 Jul 2003 07:06:49 -0400 Folks, Some items (e.g. power supply) were found in Hall G after the MSEC meeting last night. If you have lost such items, please go to the Reception desk. Thanks. thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 15 07:14:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14191 for ; Tue, 15 Jul 2003 07:14:32 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 99A7D536C2; Tue, 15 Jul 2003 07:14: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 4BFD353697 for ; Tue, 15 Jul 2003 07:12:42 -0400 (EDT) Received: (qmail 28901 invoked by uid 3269); 15 Jul 2003 11:12:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28898 invoked from network); 15 Jul 2003 11:12:42 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 15 Jul 2003 11:12:42 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6FBCfch029883 for ; Tue, 15 Jul 2003 04:12:41 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.118 [10.26.128.118]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XFY727M; Tue, 15 Jul 2003 04:12:40 -0700 Message-Id: <5.2.1.1.2.20030715070935.022b2c40@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] Summary and notes from MSEC WG meeting at 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: Tue, 15 Jul 2003 07:12:33 -0400 Folks, Here are some notes/summary from the MSEC WG meeting last night in Vienna. Please review/comment/correct. cheers, thomas ------ ---------------------------------------------------------------------- MSEC WG Meeting Summary & Notes, IETF57 Vienna ---------------------------------------------- The MSEC WG met on Monday night (14 July 2003), with presentations and updates on the current drafts. Presentations were given on GSAKMP, MIKEY, FMKE, DHHMAC and the GKM Architecture draft. The Re-Charter and New Milestones have been approved by the ADs, but the Re-Charter must be further approved by the IESG. (1) GSAKMP: ----------- - The GSAKMP protocol will now be aimed at Standards Track (with the GSAKM_-Light draft being deprecated). - Although there is a close relationship between the Policy Token and GSAKMP, the Token should be usable with other group-key management protocols and in various areas of application. A possible way forward would be to define a "base-profile" for the token containing fields common to the various key management protocols. Area-specific needs would then be satisfied by adding additional fields ("extensions") to the Token. - The Policy Token cannot, therefore, be Informational (ie. it must be aimed at Experimental, at least). (2) MIKEY and DHHMAC: --------------------- - Most (if not all) issues with regards to MIKEY have been resolved. The DH Mode is now optional, while additional text have been added regarding defining new DH groups and regarding AES Key Wrap (suggestion from AD). - Since MIKEY has been in WG Last Call status since the last IETF-56, its Last Call must be ended at a given date (decided to be 1 August 2003). - The WG last call for the DHHMAC draft will follow soon after MIKEY's closing last call. For DHHMAC, this is tentatively 1 September 2003. (3) GKM-Architecture: --------------------- - Extensive discussion on this draft, particularly on whether or not it should contain feature-comparisons of the key management protocols. - One suggestion was to limit the contents of this document to architecture-level descriptions and the explanation of Group Security Associations (GSA). - Since it was agreed that some guidance document was needed for implementers, the text (in the GKM-Arch draft) describing feature-comparisons will be split-off into a new draft (tentatively titled "Guidance to choosing MSEC Key Management Protocols" or similar). Lakshminath, Hugh and Thomas will be initial contributors to this draft. Other authors sought. (4) Action Items: ----------------- (a) Last Call closing date for MIKEY draft Friday 1 August 2003. (b) Last Call closing date for MSEC Architecture draft Friday 8 August 2003. (c) Last Call announcement for GKM Architecture draft, will be sent out Friday 1 August 2003 (closing date of 1 September 2003). (d) Last Call announcement for DHHMAC draft, will be sent out Friday 1 August 2003 (closing date of 1 September 2003). (5) Others: ----------- - A separate LKH-Algorithm draft is needed in order to help in implementations. Lakshminath will continue this effort (ps. other authors sought after). ---------------------------------------------------------------------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Jul 16 03:58:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19883 for ; Wed, 16 Jul 2003 03:58:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DAA2553680; Wed, 16 Jul 2003 03:58:15 -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 A12A8535B9 for ; Wed, 16 Jul 2003 03:57:49 -0400 (EDT) Received: (qmail 75529 invoked by uid 3269); 16 Jul 2003 07:57:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75525 invoked from network); 16 Jul 2003 07:57:49 -0000 Received: from peacock.verisign.com (65.205.251.73) by klesh.pair.com with SMTP; 16 Jul 2003 07:57:49 -0000 Received: from mou1wnexc02.verisign.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.9/) with ESMTP id h6G7vmch013280 for ; Wed, 16 Jul 2003 00:57:48 -0700 (PDT) Received: from THARDJONO-LAP.verisign.com (10.26.128.160 [10.26.128.160]) by mou1wnexc02.verisign.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3XFY9LWL; Wed, 16 Jul 2003 00:57:48 -0700 Message-Id: <5.2.1.1.2.20030716034030.022b1980@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] Closing date for MSEC-Arch wg last call is 8 August 2003 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, 16 Jul 2003 03:57:35 -0400 Folks, Another item from Vienna/IETF57 is the closure of the WG Last Call for the MSEC-Arch document (which was sent out on 18 June 2003). The date chosen is Friday 8 August 2003. Please review the MSEC-Arch draft. If you have further issues/comments, please send it immediately to the mailing list so that the authors can address them. One comment I received was that it was unusual to do a WG Last Call on a version -01 doc. However, I'd like to point out that the material (and some text) in this MSEC-Arch document has been around for the last three years at least. Some of the text come from the SMuG drafts from 1998/1999. Regards. Thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 18 17:58:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14608 for ; Fri, 18 Jul 2003 17:58:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6F24653605; Fri, 18 Jul 2003 17:58: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 DCEE853544 for ; Fri, 18 Jul 2003 17:57:16 -0400 (EDT) Received: (qmail 77609 invoked by uid 3269); 18 Jul 2003 21:57:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 77606 invoked from network); 18 Jul 2003 21:57:16 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 18 Jul 2003 21:57:16 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-754.cisco.com [10.21.82.242]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6ILvCpq014556; Fri, 18 Jul 2003 14:57:13 -0700 (PDT) Message-Id: <5.1.1.5.2.20030718145234.080ccc78@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] A few questions on GSAKMP (long) Cc: George Gross , In-Reply-To: References: <5.1.1.5.2.20030707084801.05a69688@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jul 2003 14:57:11 -0700 George I could not find it on http://www.ietf.org/ipr.html. Mark At 03:40 PM 7/18/2003 -0400, George Gross wrote: >Hi Mark, > > a follow up inline below.... > >br, > George > > >On Mon, 7 Jul 2003, Mark Baugher wrote: > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: > > <...> > > > > >Several sections mention the optional use of LKH. Could you please > > >indicate the intellectual property status of LKH? For that matter, any > > >other aspects of GSAKMP? > > > > Regarding LKH, it's in the public domain to my knowledge. > >I am not so sure if it is or is not. In my review of multicast IPR, I came >across patent# 6049878 held by Sun. While I am not a patent attornory, >from a technical perspective there seems to be alot of resemblance between >LKH and this patent. The only thing that differs from vanilla LKH from >what I could see is that sub-group membership assignment was based on 0/1 >state of bit positions in each node's identifier. However, interpreting >the claims is not in my realm of expertise. Could anyone from Sun (or >someone familiar with this area) please comment on this? A search of the >IETF IPR page for "multicast" as a search keyword did not turn up >anything about this. I'd like to avoid a silent submarine ;o( _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 18 18:51:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17077 for ; Fri, 18 Jul 2003 18:51:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 07D21537F5; Fri, 18 Jul 2003 18:50: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 69CD45366E for ; Fri, 18 Jul 2003 18:48:00 -0400 (EDT) Received: (qmail 84892 invoked by uid 3269); 18 Jul 2003 22:48:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84884 invoked from network); 18 Jul 2003 22:48:00 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 18 Jul 2003 22:48:00 -0000 Received: (qmail 21002 invoked from network); 18 Jul 2003 22:47:59 -0000 Received: from unknown (HELO lithium.nac.net) (64.21.52.83) by mercury.nac.net with SMTP; 18 Jul 2003 22:47:59 -0000 Received: (qmail 3191 invoked from network); 18 Jul 2003 22:47:58 -0000 Received: from unknown (HELO nsx.garage) (64.21.175.81) by mail.nac.net with SMTP; 18 Jul 2003 22:47:58 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h6IKhe816076; Fri, 18 Jul 2003 16:43:40 -0400 From: George Gross To: Mark Baugher Cc: George Gross , Subject: Re: [MSEC] A few questions on GSAKMP (long) In-Reply-To: <5.1.1.5.2.20030718145234.080ccc78@mira-sjc5-6.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: Fri, 18 Jul 2003 16:43:40 -0400 (EDT) Mark, On Fri, 18 Jul 2003, Mark Baugher wrote: > George > I could not find it on http://www.ietf.org/ipr.html. That's correct. But if Sun has claim on LKH, Sun could assert that IPR at _any_ time in the future regardless of not yet posting to the IETF IPR page as of today. BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt draft. Section 8 seems relevant: "An IETF consensus has developed that no mandatory-to-implement security technology can be specified in an IETF specification unless it has no known IPR claims against it or a royalty-free license is available to implementers of the specification unless there is a very good reason to do so. This limitation does not extend to other security technologies in the same specification if they are not listed as mandatory-to-implement..." GSAKMP says that LKH is optional to implement, but I have not heard the reasons why. Did the MSEC group decide that inter-operable forward secrecy is optional because of complexity? Or IPR? > > Mark > At 03:40 PM 7/18/2003 -0400, George Gross wrote: > >Hi Mark, > > > > a follow up inline below.... > > > >br, > > George > > > > > >On Mon, 7 Jul 2003, Mark Baugher wrote: > > > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: > > > <...> > > > > > > >Several sections mention the optional use of LKH. Could you please > > > >indicate the intellectual property status of LKH? For that matter, any > > > >other aspects of GSAKMP? > > > > > > Regarding LKH, it's in the public domain to my knowledge. > > > >I am not so sure if it is or is not. In my review of multicast IPR, I came > >across patent# 6049878 held by Sun. While I am not a patent attornory, > >from a technical perspective there seems to be alot of resemblance between > >LKH and this patent. The only thing that differs from vanilla LKH from > >what I could see is that sub-group membership assignment was based on 0/1 > >state of bit positions in each node's identifier. However, interpreting > >the claims is not in my realm of expertise. Could anyone from Sun (or > >someone familiar with this area) please comment on this? A search of the > >IETF IPR page for "multicast" as a search keyword did not turn up > >anything about this. I'd like to avoid a silent submarine ;o( > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Jul 18 19:29:42 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17889 for ; Fri, 18 Jul 2003 19:29:41 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C645753830; Fri, 18 Jul 2003 19:29:12 -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 02908536EC for ; Fri, 18 Jul 2003 19:24:12 -0400 (EDT) Received: (qmail 90409 invoked by uid 3269); 18 Jul 2003 23:24:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90402 invoked from network); 18 Jul 2003 23:24:12 -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; 18 Jul 2003 23:24:12 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-754.cisco.com [10.21.82.242]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id h6INO9uE001267; Fri, 18 Jul 2003 16:24:10 -0700 (PDT) Message-Id: <5.1.1.5.2.20030718161954.081a6db0@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Subject: Re: [MSEC] A few questions on GSAKMP (long) Cc: George Gross , In-Reply-To: References: <5.1.1.5.2.20030718145234.080ccc78@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 18 Jul 2003 16:24:07 -0700 George At 04:43 PM 7/18/2003 -0400, George Gross wrote: >Mark, > >On Fri, 18 Jul 2003, Mark Baugher wrote: > > > George > > I could not find it on http://www.ietf.org/ipr.html. > >That's correct. But if Sun has claim on LKH, Sun could assert that IPR at >_any_ time in the future regardless of not yet posting to the IETF IPR >page as of today. One could assert any patent at any time. The best we can say is that none are being asserted against RFC 2627. Sun has pressed IPR against other RFCs. >BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt draft. >Section 8 seems relevant: > > "An IETF consensus has developed that no mandatory-to-implement security >technology can be specified in an IETF specification unless it has no >known IPR claims against it or a royalty-free license is available to >implementers of the specification unless there is a very good reason to do >so. This limitation does not extend to other security technologies in the >same specification if they are not listed as mandatory-to-implement..." > >GSAKMP says that LKH is optional to implement, but I have not heard the >reasons why. Did the MSEC group decide that inter-operable forward secrecy >is optional because of complexity? Or IPR? No, I don't believe LKH IPR has been a factor in any of our decisions in msec. GDOI has LKH as an optional component simply because many implementations don't need it. Mark > > > > Mark > > At 03:40 PM 7/18/2003 -0400, George Gross wrote: > > >Hi Mark, > > > > > > a follow up inline below.... > > > > > >br, > > > George > > > > > > > > >On Mon, 7 Jul 2003, Mark Baugher wrote: > > > > > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: > > > > <...> > > > > > > > > >Several sections mention the optional use of LKH. Could you please > > > > >indicate the intellectual property status of LKH? For that matter, any > > > > >other aspects of GSAKMP? > > > > > > > > Regarding LKH, it's in the public domain to my knowledge. > > > > > >I am not so sure if it is or is not. In my review of multicast IPR, I came > > >across patent# 6049878 held by Sun. While I am not a patent attornory, > > >from a technical perspective there seems to be alot of resemblance between > > >LKH and this patent. The only thing that differs from vanilla LKH from > > >what I could see is that sub-group membership assignment was based on 0/1 > > >state of bit positions in each node's identifier. However, interpreting > > >the claims is not in my realm of expertise. Could anyone from Sun (or > > >someone familiar with this area) please comment on this? A search of the > > >IETF IPR page for "multicast" as a search keyword did not turn up > > >anything about this. I'd like to avoid a silent submarine ;o( > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 21 11:06:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00228 for ; Mon, 21 Jul 2003 11:06:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 8189E5358D; Mon, 21 Jul 2003 11:06: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 79BD95360E for ; Mon, 21 Jul 2003 11:04:50 -0400 (EDT) Received: (qmail 56124 invoked by uid 3269); 21 Jul 2003 15:04:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 56121 invoked from network); 21 Jul 2003 15:04: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; 21 Jul 2003 15:04:50 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-22.cisco.com [10.21.64.22]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6LF4luH014371 for ; Mon, 21 Jul 2003 08:04:47 -0700 (PDT) Message-Id: <5.1.1.5.2.20030721075924.0719a990@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: msec@securemulticast.org From: Mark Baugher Subject: Re: [MSEC] A few questions on GSAKMP (long) In-Reply-To: <200307211153.HAA11794@columbia.sparta.com> References: <5.1.1.5.2.20030718161954.081a6db0@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 21 Jul 2003 08:04:47 -0700 Uri Meth sent me a private note that reminded me that LKH is not the only solution in this space. Far from it. One should also consider McGrew & Sherman One-way Function Trees (OFT). Lakshminath might also agree that subset difference is another alternative, and it is one that has RAND (reasonable and non-discriminatory) licensing terms. Ultimately, if you want to be lawsuit-proof in your technology choices, then license the technology from a company that will accept any expected or surprise lawsuits covering that technology. There are many surprises when it comes to IPR encumbrances. Mark > > > > George > > > > At 04:43 PM 7/18/2003 -0400, George Gross wrote: > > >Mark, > > > > > >On Fri, 18 Jul 2003, Mark Baugher wrote: > > > > > > > George > > > > I could not find it on http://www.ietf.org/ipr.html. > > > > > >That's correct. But if Sun has claim on LKH, Sun could assert that IPR at > > >_any_ time in the future regardless of not yet posting to the IETF IPR > > >page as of today. > > > > One could assert any patent at any time. The best we can say is that none > > are being asserted against RFC 2627. Sun has pressed IPR against other > RFCs. > > > > > > >BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt draft. > > >Section 8 seems relevant: > > > > > > "An IETF consensus has developed that no mandatory-to-implement > security > > >technology can be specified in an IETF specification unless it has no > > >known IPR claims against it or a royalty-free license is available to > > >implementers of the specification unless there is a very good reason to do > > >so. This limitation does not extend to other security technologies in the > > >same specification if they are not listed as mandatory-to-implement..." > > > > > >GSAKMP says that LKH is optional to implement, but I have not heard the > > >reasons why. Did the MSEC group decide that inter-operable forward secrecy > > >is optional because of complexity? Or IPR? > > > > No, I don't believe LKH IPR has been a factor in any of our decisions in > > msec. GDOI has LKH as an optional component simply because many > > implementations don't need it. > > > > Mark > > > > > > > > > > > > Mark > > > > At 03:40 PM 7/18/2003 -0400, George Gross wrote: > > > > >Hi Mark, > > > > > > > > > > a follow up inline below.... > > > > > > > > > >br, > > > > > George > > > > > > > > > > > > > > >On Mon, 7 Jul 2003, Mark Baugher wrote: > > > > > > > > > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: > > > > > > <...> > > > > > > > > > > > > >Several sections mention the optional use of LKH. Could you please > > > > > > >indicate the intellectual property status of LKH? For that > matter, any > > > > > > >other aspects of GSAKMP? > > > > > > > > > > > > Regarding LKH, it's in the public domain to my knowledge. > > > > > > > > > >I am not so sure if it is or is not. In my review of multicast > IPR, I came > > > > >across patent# 6049878 held by Sun. While I am not a patent attornory, > > > > >from a technical perspective there seems to be alot of resemblance > between > > > > >LKH and this patent. The only thing that differs from vanilla LKH from > > > > >what I could see is that sub-group membership assignment was based > on 0/1 > > > > >state of bit positions in each node's identifier. However, > interpreting > > > > >the claims is not in my realm of expertise. Could anyone from Sun (or > > > > >someone familiar with this area) please comment on this? A search > of the > > > > >IETF IPR page for "multicast" as a search keyword did not turn up > > > > >anything about this. I'd like to avoid a silent submarine ;o( > > > > > > > > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > >-- >Uri Meth (410) 872 - 1515 x233 (voice) >SPARTA, Inc. (410) 872 - 8079 (fax) >7075 Samuel Morse Drive umeth@sparta.com >Columbia, MD 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Jul 21 11:13:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00353 for ; Mon, 21 Jul 2003 11:13:27 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 617C953704; Mon, 21 Jul 2003 11:12: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 5E7735353A for ; Mon, 21 Jul 2003 11:11:46 -0400 (EDT) Received: (qmail 57265 invoked by uid 3269); 21 Jul 2003 15:11:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57262 invoked from network); 21 Jul 2003 15:11:46 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 21 Jul 2003 15:11:46 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id h6LFBYw18919; Mon, 21 Jul 2003 11:11:35 -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 3ZF0M6XW; Mon, 21 Jul 2003 11:11:34 -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 3ZF93JH8; Mon, 21 Jul 2003 11:11:33 -0400 Message-ID: <3F1C035E.6010109@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] A few questions on GSAKMP (long) References: <5.1.1.5.2.20030718161954.081a6db0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030721075924.0719a990@mira-sjc5-6.cisco.com> In-Reply-To: <5.1.1.5.2.20030721075924.0719a990@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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, 21 Jul 2003 11:14:38 -0400 Content-Transfer-Encoding: 7bit We have known about the LKH patent for a while now. I am not sure whether it is applicable to d>2 though. OFT, as I recall, does not have IPR (David McGrew mentioned this at some IETF WG meeting). I did not know that SDR has IPR on it (Did IBM post RAND on it?). regards, Lakshminath Mark Baugher wrote: > Uri Meth sent me a private note that reminded me that LKH is not the > only solution in this space. Far from it. One should also consider > McGrew & Sherman One-way Function Trees (OFT). Lakshminath might also > agree that subset difference is another alternative, and it is one > that has RAND (reasonable and non-discriminatory) licensing terms. > Ultimately, if you want to be lawsuit-proof in your technology > choices, then license the technology from a company that will accept > any expected or surprise lawsuits covering that technology. There are > many surprises when it comes to IPR encumbrances. > > Mark > > >> > >> > George >> > >> > At 04:43 PM 7/18/2003 -0400, George Gross wrote: >> > >Mark, >> > > >> > >On Fri, 18 Jul 2003, Mark Baugher wrote: >> > > >> > > > George >> > > > I could not find it on http://www.ietf.org/ipr.html. >> > > >> > >That's correct. But if Sun has claim on LKH, Sun could assert that >> IPR at >> > >_any_ time in the future regardless of not yet posting to the IETF >> IPR >> > >page as of today. >> > >> > One could assert any patent at any time. The best we can say is >> that none >> > are being asserted against RFC 2627. Sun has pressed IPR against >> other RFCs. >> > >> > >> > >BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt >> draft. >> > >Section 8 seems relevant: >> > > >> > > "An IETF consensus has developed that no mandatory-to-implement >> security >> > >technology can be specified in an IETF specification unless it has no >> > >known IPR claims against it or a royalty-free license is available to >> > >implementers of the specification unless there is a very good >> reason to do >> > >so. This limitation does not extend to other security >> technologies in the >> > >same specification if they are not listed as >> mandatory-to-implement..." >> > > >> > >GSAKMP says that LKH is optional to implement, but I have not >> heard the >> > >reasons why. Did the MSEC group decide that inter-operable forward >> secrecy >> > >is optional because of complexity? Or IPR? >> > >> > No, I don't believe LKH IPR has been a factor in any of our >> decisions in >> > msec. GDOI has LKH as an optional component simply because many >> > implementations don't need it. >> > >> > Mark >> > >> > >> > > > >> > > > Mark >> > > > At 03:40 PM 7/18/2003 -0400, George Gross wrote: >> > > > >Hi Mark, >> > > > > >> > > > > a follow up inline below.... >> > > > > >> > > > >br, >> > > > > George >> > > > > >> > > > > >> > > > >On Mon, 7 Jul 2003, Mark Baugher wrote: >> > > > > >> > > > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: >> > > > > > <...> >> > > > > > >> > > > > > >Several sections mention the optional use of LKH. Could >> you please >> > > > > > >indicate the intellectual property status of LKH? For that >> matter, any >> > > > > > >other aspects of GSAKMP? >> > > > > > >> > > > > > Regarding LKH, it's in the public domain to my knowledge. >> > > > > >> > > > >I am not so sure if it is or is not. In my review of multicast >> IPR, I came >> > > > >across patent# 6049878 held by Sun. While I am not a patent >> attornory, >> > > > >from a technical perspective there seems to be alot of >> resemblance between >> > > > >LKH and this patent. The only thing that differs from vanilla >> LKH from >> > > > >what I could see is that sub-group membership assignment was >> based on 0/1 >> > > > >state of bit positions in each node's identifier. However, >> interpreting >> > > > >the claims is not in my realm of expertise. Could anyone from >> Sun (or >> > > > >someone familiar with this area) please comment on this? A >> search of the >> > > > >IETF IPR page for "multicast" as a search keyword did not >> turn up >> > > > >anything about this. I'd like to avoid a silent submarine ;o( >> > > > >> > > > >> > >> > >> > >> > _______________________________________________ >> > msec mailing list >> > msec@securemulticast.org >> > http://www.pairlist.net/mailman/listinfo/msec >> > >> >> -- >> Uri Meth (410) 872 - 1515 x233 (voice) >> SPARTA, Inc. (410) 872 - 8079 (fax) >> 7075 Samuel Morse Drive umeth@sparta.com >> 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 Mon Jul 21 11:42:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01171 for ; Mon, 21 Jul 2003 11:42:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2FC93535C2; Mon, 21 Jul 2003 11:42: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 2FE27535A3 for ; Mon, 21 Jul 2003 11:40:57 -0400 (EDT) Received: (qmail 62716 invoked by uid 3269); 21 Jul 2003 15:40:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62713 invoked from network); 21 Jul 2003 15:40:57 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 21 Jul 2003 15:40:57 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn3-22.cisco.com [10.21.64.22]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6LFelpq021598; Mon, 21 Jul 2003 08:40:48 -0700 (PDT) Message-Id: <5.1.1.5.2.20030721082626.073a9b60@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] A few questions on GSAKMP (long) Cc: msec@securemulticast.org In-Reply-To: <3F1C035E.6010109@nortelnetworks.com> References: <5.1.1.5.2.20030721075924.0719a990@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030718161954.081a6db0@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030721075924.0719a990@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 21 Jul 2003 08:40:46 -0700 At 11:14 AM 7/21/2003 -0400, Lakshminath Dondeti wrote: >We have known about the LKH patent for a while now. I am not sure whether >it is applicable to d>2 though. OFT, as I recall, does not have IPR >(David McGrew mentioned this at some IETF WG meeting). I would not say that there is no IPR encumbrance on any technology because it's too complex a question. For starters, there are US patents and International patents to worry about just in the US. Then there is the applicability of a patent, that can be hard to determine and requires IPR expertise. That being said, I don't know of any IPR claims on OFT, which is not an IETF protocol at present. And I'd expect Sun to have notified the Internet community if it intended to press IPR claims on RFC 2627 but could not find any such notification in the IETF repository of IPR claims. Mark >I did not know that SDR has IPR on it (Did IBM post RAND on it?). > >regards, >Lakshminath > >Mark Baugher wrote: > >>Uri Meth sent me a private note that reminded me that LKH is not the only >>solution in this space. Far from it. One should also consider McGrew & >>Sherman One-way Function Trees (OFT). Lakshminath might also agree that >>subset difference is another alternative, and it is one that has RAND >>(reasonable and non-discriminatory) licensing terms. >>Ultimately, if you want to be lawsuit-proof in your technology choices, >>then license the technology from a company that will accept any expected >>or surprise lawsuits covering that technology. There are many surprises >>when it comes to IPR encumbrances. >> >>Mark >> >> >>> > >>> > George >>> > >>> > At 04:43 PM 7/18/2003 -0400, George Gross wrote: >>> > >Mark, >>> > > >>> > >On Fri, 18 Jul 2003, Mark Baugher wrote: >>> > > >>> > > > George >>> > > > I could not find it on http://www.ietf.org/ipr.html. >>> > > >>> > >That's correct. But if Sun has claim on LKH, Sun could assert that >>> IPR at >>> > >_any_ time in the future regardless of not yet posting to the IETF IPR >>> > >page as of today. >>> > >>> > One could assert any patent at any time. The best we can say is that >>> none >>> > are being asserted against RFC 2627. Sun has pressed IPR against >>> other RFCs. >>> > >>> > >>> > >BTW, I took a quick look at Bradner's ipr-technology-rights-10.txt >>> draft. >>> > >Section 8 seems relevant: >>> > > >>> > > "An IETF consensus has developed that no mandatory-to-implement >>> security >>> > >technology can be specified in an IETF specification unless it has no >>> > >known IPR claims against it or a royalty-free license is available to >>> > >implementers of the specification unless there is a very good reason >>> to do >>> > >so. This limitation does not extend to other security technologies >>> in the >>> > >same specification if they are not listed as mandatory-to-implement..." >>> > > >>> > >GSAKMP says that LKH is optional to implement, but I have not heard the >>> > >reasons why. Did the MSEC group decide that inter-operable forward >>> secrecy >>> > >is optional because of complexity? Or IPR? >>> > >>> > No, I don't believe LKH IPR has been a factor in any of our decisions in >>> > msec. GDOI has LKH as an optional component simply because many >>> > implementations don't need it. >>> > >>> > Mark >>> > >>> > >>> > > > >>> > > > Mark >>> > > > At 03:40 PM 7/18/2003 -0400, George Gross wrote: >>> > > > >Hi Mark, >>> > > > > >>> > > > > a follow up inline below.... >>> > > > > >>> > > > >br, >>> > > > > George >>> > > > > >>> > > > > >>> > > > >On Mon, 7 Jul 2003, Mark Baugher wrote: >>> > > > > >>> > > > > > At 08:19 PM 7/4/2003 -0400, George Gross wrote: >>> > > > > > <...> >>> > > > > > >>> > > > > > >Several sections mention the optional use of LKH. Could you >>> please >>> > > > > > >indicate the intellectual property status of LKH? For that >>> matter, any >>> > > > > > >other aspects of GSAKMP? >>> > > > > > >>> > > > > > Regarding LKH, it's in the public domain to my knowledge. >>> > > > > >>> > > > >I am not so sure if it is or is not. In my review of multicast >>> IPR, I came >>> > > > >across patent# 6049878 held by Sun. While I am not a patent >>> attornory, >>> > > > >from a technical perspective there seems to be alot of >>> resemblance between >>> > > > >LKH and this patent. The only thing that differs from vanilla >>> LKH from >>> > > > >what I could see is that sub-group membership assignment was >>> based on 0/1 >>> > > > >state of bit positions in each node's identifier. However, >>> interpreting >>> > > > >the claims is not in my realm of expertise. Could anyone from >>> Sun (or >>> > > > >someone familiar with this area) please comment on this? A >>> search of the >>> > > > >IETF IPR page for "multicast" as a search keyword did not turn up >>> > > > >anything about this. I'd like to avoid a silent submarine ;o( >>> > > > >>> > > > >>> > >>> > >>> > >>> > _______________________________________________ >>> > msec mailing list >>> > msec@securemulticast.org >>> > http://www.pairlist.net/mailman/listinfo/msec >>> > >>> >>>-- >>>Uri Meth (410) 872 - 1515 x233 (voice) >>>SPARTA, Inc. (410) 872 - 8079 (fax) >>>7075 Samuel Morse Drive umeth@sparta.com >>>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 24 11:11:36 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10449 for ; Thu, 24 Jul 2003 11:11:35 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 44F6853869; Thu, 24 Jul 2003 11:09:11 -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 B94595382C for ; Thu, 24 Jul 2003 11:07:52 -0400 (EDT) Received: (qmail 87579 invoked by uid 3269); 24 Jul 2003 15:07:52 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 87569 invoked from network); 24 Jul 2003 15:07:52 -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; 24 Jul 2003 15:07:52 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 24 Jul 2003 08:07:53 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn2-373.cisco.com [10.21.113.117]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6OF7luH014950; Thu, 24 Jul 2003 08:07:48 -0700 (PDT) Message-Id: <5.1.1.5.2.20030724072807.0237fda8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: msec@securemulticast.org From: Mark Baugher Cc: Laurence.Duquerroy@space.alcatel.fr, "Kenny, Gavin (Space)" , Brian Weis , Sebastien.Josset@space.alcatel.fr, Lakshminath Dondeti , msec@securemulticast.org In-Reply-To: <5.1.1.5.2.20030703073326.05f6d9c8@mira-sjc5-6.cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [MSEC] =?iso-8859-1?Q?Re:_[MSEC]_Re:_R=E9f._:_Reliability_&_Secure_?= Multicast Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 24 Jul 2003 08:07:45 -0700 Content-Transfer-Encoding: quoted-printable Hi, We are working on the Last Call draft of the Group Key Management=20 Architecture (gkmarch) I-D and need one final point on reliability for the= =20 re-key class of protocols. Recall from gkmarch that re-key messages may=20 may use multicast delivery. Our unstated assumption has been that the key= =20 management protocol would use whatever reliable multicast mechanism that=20 was considered to be applicable for a given application environment. We=20 want to use the protocols that come out of the reliable multicast transport= =20 (RMT) working group in the IETF. RMT has not produced any standards-track= =20 documents, however, only experimental and informational standards have come= =20 from RMT to date. I have reviewed the security considerations of these=20 documents (briefly) and see no reason to incorporate one or more RMT=20 building blocks into gkmarch protocols. MSEC group key management protocols assume that the network is under=20 control of an attacker who can delay, reorder, alter, cut and paste,=20 replay, and perform other mischief to key management messages. ISAKMP=20 protocols (I include GSAKMP, GDOI and MIKEY in this class) are designed to= =20 operate securely over insecure networks. IKE builds reliability into its=20 protocol although in principle, it could run over TCP. One problem with=20 securing TCP payloads but not TCP headers, however, is that an attacker=20 could alter or forge a packet with a sequence number that forces the TCP=20 window to be wrongly advanced but the forgery won't be detected until after= =20 the update to the TCP window. This would cause a later, valid message to=20 be rejected at the TCP layer. This might suggest that msec should incorporate reliable multicast=20 mechanisms into its re-key message. But it is simple to retransmit and IKE= =20 message until N timeouts or a re-key message M times to accommodate network= =20 loss. It is not simple to incorporate an ACK, NACK, TRACK or some other=20 reliable multicast protocol into the key management protocol. Unless we=20 can find a single reliable multicast protocol that will suit all purposes,= =20 moreover, we will have to incorporate a multiplicity of such protocols and= =20 this is a great complication. We shouldn't do this. I think we should consider an alternative approach and that is to=20 bootstrap the security for the reliable multicast protocol (RMP) at the=20 time the msec registration protocol is run. The RMP that key management=20 uses needs to be in accordance with the policy of the key management=20 system; that policy is implemented in the registration exchange. Once the= =20 underlying reliable multicast connection is installed, the msec re-key=20 message can use it and benefit from its DoS protections as well=20 reliable-multicast service. Mark At 08:27 AM 7/3/2003 -0700, Mark Baugher wrote: >Laurence, > >At 03:06 PM 7/2/2003 +0200, Laurence.Duquerroy@space.alcatel.fr wrote: ><...> > >>However we don?t totally agree with you about the need of reliability=20 >>mechanisms >>in group key management protocols for satellite systems. >>The "world of satellite systems" is composed of two main system types := Fixe >>broadband systems ( i.e. TV broadcasting) and Mobile systems. >>Three optimized retransmissions of all re-key messages seem to fulfill=20 >>the needs >>of fixe broadcast systems without return link, that have an=20 >>overprovisionned and >>stable link budget. However, in mobile systems or versatile systems (fast >>network inputs/outputs) , or heterogeneous systems, even with three >>retransmissions, it is not certain at all that each group member receives= all >>re-keying messages. Reliability mechanisms ( based on Nack/ack) would be= =20 >>needed. >>Finally, it seems easier and more optimized to add some reliability=20 >>mechanisms >>to Group Key Management protocols (such as GSAKMP) compared to the use of = a >>reliable multicast transport protocol which shall also be secured=20 >>(signature of >>the Acks/Nacks) (Nowadays attacks are successfully launched on TCP=20 >>exchanges). > >I don't think this makes the case why msec should build a reliable=20 >multicast protocol into its key management. The arguments for using a=20 >reliable multicast protocol rather than incorporating one probably include= =20 >the following. > >1. allows us to select the best protocol for a particular application=20 >environment >2. allows us to introduce better protocols when they are developed >3. reduces the functionality and the complexity of the key management= protocol > >Are there others? > >Probably the best (maybe the only) argument for including it in the key=20 >management is security. We need to answer the following questions. > >1. How can the security of the key management protocol be successfully=20 >undermined by attacking the reliable multicast protocol and is this true=20 >for all interesting reliable-multicast protocols. >2. How can incorporation of the reliable multicast protocol into the key=20 >management protocol protect against these attacks? >3. Is it possible to protect against these attacks without putting the=20 >reliable multicast protocol into the key management protocol. > >Are there others? > >It's good that you raise this issue now in msec because the previous=20 >discussion we had was some time ago in msec's predecessor group, IRTF SMuG. > >Mark > >>Indeed, as adding lightweight reliability features in GSAKMP optimised=20 >>for our >>needs can be done for a very low cost, we don't see the need to use an=20 >>external >>multicast reliable protocol with its own additional signaling and byte=20 >>overhead >>for authentication and integrity check... >> >> >> >> >> > 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? >> >>Sorry for my slow response to Mark's question (from the mail below). >>Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only=20 >>difference >>is ... the use of reliability mechanisms (i.e. the use of Nacks and= messages >>from the GCKS indicating the last used sequence number). >> >> >>Best regards, >> >>Laurence >> >>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 >> >> >> >> >Hi, Just to add my 2p worth. >> >> >We're running a project which has produced a GSAKMP/LKH implementation= for >> >use over satellite networks. We have been running the system using a >> >satellite link simulator with an error rate of 10-3 and a delay of=20 >> 0.25s and >> >it works great! >> >> >All we did was to have all re-key messages repeated three times, one= after >> >another. >> >> >Considering that most modern sat systems say they can give you an error= =20 >> rate >> >of approx 10-7 or better, I don't think reliability is much of an issue= in >> >real world applications. I appreciate it is nice to close the loop, as= it >> >were, but I think the downside of using up valuable bandwidth and time= =20 >> (in a >> >long transmission delay environment) with acks and nacks is hard to=20 >> justify. >> >> >I would vote on keeping reliability in a separate layer as multicast is >> >great for satellite transmission but a constant return path is not= always >> >available. >> >> >regards >> >> >Gavin >> >> >> >> >-----Original Message----- >> >From: Mark Baugher [mailto:mbaugher@cisco.com] >> >Sent: 27 June 2003 16:14 >> >To: Laurence.Duquerroy@space.alcatel.fr >> >Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath Dondeti; >> >msec@securemulticast.org >> >Subject: [MSEC] Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : Re: [ MSEC] R= =E9f. : >> >[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] >> >> >> >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 >> >> >> >_______________________________________________ >> >msec mailing list >> >msec@securemulticast.org >> >http://www.pairlist.net/mailman/listinfo/msec >> >> >This e-mail and any attachment is for authorised use by the intended >>recipient(s) only. It may contain proprietary >material, confidential >>information and/or be subject to legal privilege. It should not be= copied, >>disclosed to, >retained or used by, any other party. If you are not an=20 >>intended >>recipient then please promptly delete this e-mail >and any attachment and= all >>copies and inform the sender. Thank you. > > > >_______________________________________________ >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 Jul 24 15:15:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24826 for ; Thu, 24 Jul 2003 15:15:25 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7688953840; Thu, 24 Jul 2003 15:14: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 2DF4C53536 for ; Thu, 24 Jul 2003 15:12:56 -0400 (EDT) Received: (qmail 30098 invoked by uid 3269); 24 Jul 2003 19:12:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 30093 invoked from network); 24 Jul 2003 19:12:55 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 24 Jul 2003 19:12:55 -0000 Received: (qmail 8555 invoked from network); 24 Jul 2003 19:06:01 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.169) by mail.nac.net with SMTP; 24 Jul 2003 19:06:01 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h6OH0le30324; Thu, 24 Jul 2003 13:00:47 -0400 From: George Gross To: Mark Baugher Cc: , , "Kenny, Gavin (Space)" , Brian Weis , , Lakshminath Dondeti Subject: Re: [MSEC] =?iso-8859-1?Q?Re:_[MSEC]_Re:_R=E9f._:_Reliability_&_Secure_?= Multicast In-Reply-To: <5.1.1.5.2.20030724072807.0237fda8@mira-sjc5-6.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 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: Thu, 24 Jul 2003 13:00:47 -0400 (EDT) Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Mark, =09inline.... br, =09George On Thu, 24 Jul 2003, Mark Baugher wrote: > > This might suggest that msec should incorporate reliable multicast > mechanisms into its re-key message. But it is simple to retransmit and I= KE > message until N timeouts or a re-key message M times to accommodate netwo= rk > loss. It is not simple to incorporate an ACK, NACK, TRACK or some other > reliable multicast protocol into the key management protocol. Unless we > can find a single reliable multicast protocol that will suit all purposes= , > moreover, we will have to incorporate a multiplicity of such protocols an= d > this is a great complication. We shouldn't do this. OTOH, we do have an obligation to create an interoperable standard. It should be possible for Vendor A to be the GCKS, and the group members to be an arbitary mixture of Vendors B, C, D,... Consider that in the absence of a mandatory to implement error recovery mechanism, the implementations at a inter-op testfest would all potentially bring their favorite (yet non-interoperable) RMT protocol to the testfest. As you point out below, the selection of the RMT protocol is a group policy decision, and therefore the policy token (or the key management spec) will have a protocol field(s) whose values identifies the RMT du jour mechanisms and parameters. =09Therefore, it is incumbent on the GKM-arch spec to define that mandatory to implement mechanism. In other words, I think you probably are forced into saying what a GCKS and a member must do to recover from an error when RMT is not available, since there is no RMT standard to point at. At the moment, GSAKMP doesn't say anything about this, nor does GDOI. I would think we'd want _one_ rudimentary mechanism/strategy articulated that is part of the MSEC proposed standards. Your pick whether it is in the key management protocol specs in multiple places, or you elect to spec it once in GKM-arch. IKE handled this by defining a timeout and retry policy. Seems to me that at the least that what we need here. In addition, some verbage should explain how a member detects that it lost a rekey message and how it should recover synchronization.... =09This is tricky, since if the policy is to do a "leave group" message followed by re-registration, there is a potential for overwhelming/DoS the GCKS if large numbers of members trigger the same error response at the same time. So the policy should have some ditter in the timing constant. I know you expressed the view not to do this, but a member->GCKS "notify" payload would avoid alot of the dropped data and delay here... > I think we should consider an alternative approach and that is to > bootstrap the security for the reliable multicast protocol (RMP) at the > time the msec registration protocol is run. The RMP that key management > uses needs to be in accordance with the policy of the key management > system; that policy is implemented in the registration exchange. Once th= e > underlying reliable multicast connection is installed, the msec re-key > message can use it and benefit from its DoS protections as well > reliable-multicast service. Ok, as long as it accomodates the above requirement wrt/ a mandatory to implement RMP or a default error recovery policy when there is no RMP, we're set. A snapshot of the policy token spec should be frozen with this capability in its v1 profile before GSAKMP can move forward to PS. > > Mark > > > At 08:27 AM 7/3/2003 -0700, Mark Baugher wrote: > >Laurence, > > > >At 03:06 PM 7/2/2003 +0200, Laurence.Duquerroy@space.alcatel.fr wrote: > ><...> > > > >>However we don?t totally agree with you about the need of reliability > >>mechanisms > >>in group key management protocols for satellite systems. > >>The "world of satellite systems" is composed of two main system types := Fixe > >>broadband systems ( i.e. TV broadcasting) and Mobile systems. > >>Three optimized retransmissions of all re-key messages seem to fulfill > >>the needs > >>of fixe broadcast systems without return link, that have an > >>overprovisionned and > >>stable link budget. However, in mobile systems or versatile systems (fa= st > >>network inputs/outputs) , or heterogeneous systems, even with three > >>retransmissions, it is not certain at all that each group member receiv= es all > >>re-keying messages. Reliability mechanisms ( based on Nack/ack) would b= e > >>needed. > >>Finally, it seems easier and more optimized to add some reliability > >>mechanisms > >>to Group Key Management protocols (such as GSAKMP) compared to the use = of a > >>reliable multicast transport protocol which shall also be secured > >>(signature of > >>the Acks/Nacks) (Nowadays attacks are successfully launched on TCP > >>exchanges). > > > >I don't think this makes the case why msec should build a reliable > >multicast protocol into its key management. The arguments for using a > >reliable multicast protocol rather than incorporating one probably inclu= de > >the following. > > > >1. allows us to select the best protocol for a particular application > >environment > >2. allows us to introduce better protocols when they are developed > >3. reduces the functionality and the complexity of the key management pr= otocol > > > >Are there others? > > > >Probably the best (maybe the only) argument for including it in the key > >management is security. We need to answer the following questions. > > > >1. How can the security of the key management protocol be successfully > >undermined by attacking the reliable multicast protocol and is this true > >for all interesting reliable-multicast protocols. > >2. How can incorporation of the reliable multicast protocol into the key > >management protocol protect against these attacks? > >3. Is it possible to protect against these attacks without putting the > >reliable multicast protocol into the key management protocol. > > > >Are there others? > > > >It's good that you raise this issue now in msec because the previous > >discussion we had was some time ago in msec's predecessor group, IRTF SM= uG. > > > >Mark > > > >>Indeed, as adding lightweight reliability features in GSAKMP optimised > >>for our > >>needs can be done for a very low cost, we don't see the need to use an > >>external > >>multicast reliable protocol with its own additional signaling and byte > >>overhead > >>for authentication and integrity check... > >> > >> > >> > >> > >> > Finally, I don't see any difference between your Phase 3 and the M= SEC > >> >Rekey protocol (called "groupkey push" in GDOI). Are there significa= nt > >> >differences? > >> > >>Sorry for my slow response to Mark's question (from the mail below). > >>Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only > >>difference > >>is ... the use of reliability mechanisms (i.e. the use of Nacks and mes= sages > >>from the GCKS indicating the last used sequence number). > >> > >> > >>Best regards, > >> > >>Laurence > >> > >>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 > >> > >> > >> > >> >Hi, Just to add my 2p worth. > >> > >> >We're running a project which has produced a GSAKMP/LKH implementatio= n for > >> >use over satellite networks. We have been running the system using a > >> >satellite link simulator with an error rate of 10-3 and a delay of > >> 0.25s and > >> >it works great! > >> > >> >All we did was to have all re-key messages repeated three times, one = after > >> >another. > >> > >> >Considering that most modern sat systems say they can give you an err= or > >> rate > >> >of approx 10-7 or better, I don't think reliability is much of an iss= ue in > >> >real world applications. I appreciate it is nice to close the loop, a= s it > >> >were, but I think the downside of using up valuable bandwidth and tim= e > >> (in a > >> >long transmission delay environment) with acks and nacks is hard to > >> justify. > >> > >> >I would vote on keeping reliability in a separate layer as multicast = is > >> >great for satellite transmission but a constant return path is not al= ways > >> >available. > >> > >> >regards > >> > >> >Gavin > >> > >> > >> > >> >-----Original Message----- > >> >From: Mark Baugher [mailto:mbaugher@cisco.com] > >> >Sent: 27 June 2003 16:14 > >> >To: Laurence.Duquerroy@space.alcatel.fr > >> >Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath Dondet= i; > >> >msec@securemulticast.org > >> >Subject: [MSEC] Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : Re: [ MSEC] R= =E9f. : > >> >[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] > >> > >> > >> >Laurence, > >> > We discussed putting reliability mechanisms into GDOI about three = years > >> >ago. The decision of the secure multicast research group (SMuG) at t= hat > >> >time was to use the mechanisms that are being developed by another gr= oup, > >> >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 mana= gement > >> >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 us= ing a > >> >separate layer. The advantage that I see of using a separate layer i= s what > >> >one generally gets from design modularity: We can choose among the b= est > >> >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 t= he 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 M= SEC > >> >Rekey protocol (called "groupkey push" in GDOI). Are there significa= nt > >> >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 > >> > >> > >> >_______________________________________________ > >> >msec mailing list > >> >msec@securemulticast.org > >> >http://www.pairlist.net/mailman/listinfo/msec > >> > >> >This e-mail and any attachment is for authorised use by the intended > >>recipient(s) only. It may contain proprietary >material, confidential > >>information and/or be subject to legal privilege. It should not be cop= ied, > >>disclosed to, >retained or used by, any other party. If you are not an > >>intended > >>recipient then please promptly delete this e-mail >and any attachment a= nd all > >>copies and inform the sender. Thank you. > > > > > > > >_______________________________________________ > >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 Jul 28 14:12:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14688 for ; Mon, 28 Jul 2003 14:12:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2FE155382E; Mon, 28 Jul 2003 14:12:12 -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 4007253868 for ; Mon, 28 Jul 2003 14:10:07 -0400 (EDT) Received: (qmail 22250 invoked by uid 3269); 28 Jul 2003 18:10:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 22244 invoked from network); 28 Jul 2003 18:10:06 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 28 Jul 2003 18:10:06 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn1-846.cisco.com [10.21.99.78]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6SI9ppq009934; Mon, 28 Jul 2003 11:09:51 -0700 (PDT) Message-Id: <5.1.1.5.2.20030728103413.07242a48@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: George Gross From: Mark Baugher Cc: , Lakshminath Dondeti , canetti , Fredrik.Lindholm@era.ericsson.se In-Reply-To: References: <5.1.1.5.2.20030724072807.0237fda8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [MSEC] =?iso-8859-1?Q?Re:_[MSEC]_Re:_[MSEC]_Re:_R=E9f._:_?= Reliability & Secure Multicast Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 28 Jul 2003 11:09:50 -0700 Content-Transfer-Encoding: quoted-printable hello George, At 01:00 PM 7/24/2003 -0400, George Gross wrote: >Hi Mark, > inline.... > >br, > George > >On Thu, 24 Jul 2003, Mark Baugher wrote: > > > > > > > This might suggest that msec should incorporate reliable multicast > > mechanisms into its re-key message. But it is simple to retransmit and= IKE > > message until N timeouts or a re-key message M times to accommodate= network > > loss. It is not simple to incorporate an ACK, NACK, TRACK or some other > > reliable multicast protocol into the key management protocol. Unless we > > can find a single reliable multicast protocol that will suit all= purposes, > > moreover, we will have to incorporate a multiplicity of such protocols= and > > this is a great complication. We shouldn't do this. > >OTOH, we do have an obligation to create an interoperable standard. It >should be possible for Vendor A to be the GCKS, and the group members to >be an arbitary mixture of Vendors B, C, D,... Good point. This follows from the existence of interoperable reliable=20 multicast protocols. There are several candidate products and=20 standards. I'd like for msec group key management architecture to be able= =20 to use any of them that have good data security definitions for denial of=20 service protection. One might also want to use multicast source=20 authentication (TESLA is mentioned as a requirement for RMT protocols, I=20 think) from the underlying reliable multicast transport. >Consider that in the absence of a mandatory to implement error recovery >mechanism, the implementations at a inter-op testfest would all >potentially bring their favorite (yet non-interoperable) RMT protocol to >the testfest. So what? They might also bring their own favorite (yet non-interoperable)= =20 authorization to the plugfest as well. But I would not attempt to=20 incorporate an authorization system in the group key management protocol in= =20 order to avoid this problem. Here's what I think the msec group key management protocol should offer as= =20 a baseline: A protected re-key message with sequence counter. As a matter= =20 of local policy, a GCKS sender or a re-key message can send a re-key=20 message as many times at whatever time intervals it chooses. When we have=20 reliable multicast standards that are more than Experimental, the GCKS=20 sender only needs to send out the message once - as a matter of local=20 policy. The group member will reject duplicates based on the sequence=20 number in the authenticated message. >As you point out below, the selection of the RMT protocol is >a group policy decision, and therefore the policy token (or the key >management spec) will have a protocol field(s) whose values identifies the >RMT du jour mechanisms and parameters. Unfortunately, I don't think we want to reference Experimental RFCs in a=20 Standards-track specification. Frankly, I'm not happy with where we are at= =20 with RMT. > Therefore, it is incumbent on the GKM-arch spec to define that >mandatory to implement mechanism. In other words, I think you probably are >forced into saying what a GCKS and a member must do to recover from an >error when RMT is not available, since there is no RMT standard to point >at. At the moment, GSAKMP doesn't say anything about this, nor does GDOI. ftp://ftp.rfc-editor.org/in-notes/rfc3547.txt uses SEQ to order re-key=20 messages (groupkey-push messages in GDOI parlance) so a receiver can detect= =20 a duplicate and discover one or more missed sequence numbers. In the=20 latter circumstance, the receiver has no other recourse than to run the=20 groupkey-pull protocol and re-synchronize with the GCKS. >I would think we'd want _one_ rudimentary mechanism/strategy articulated >that is part of the MSEC proposed standards. I agree that the groupkey management architecture should address this topic= =20 (and this is why I am engaging you and others on this topic). I think we=20 should say that the rudimentary strategy is to use sequencing of re-key=20 messages to allow (1) a sender to send multiple re-key messages, and (2) a= =20 receiver should discard duplicate re-key messages and respond to missed=20 re-key messages. (Note that in the latter case, re-ordered messages need=20 to be taken into account). One response is to re-synchronize with the=20 GCKS. This can have very bad ramifications when a lot of members=20 synchronously contact the GCKS. This and the concomitant DoS attacks need= =20 to be considered in the gkmarch as well. >Your pick whether it is in >the key management protocol specs in multiple places, or you elect to spec >it once in GKM-arch. IKE handled this by defining a timeout and retry >policy. Seems to me that at the least that what we need here. In addition, >some verbage should explain how a member detects that it lost a rekey >message and how it should recover synchronization.... Well, we have that in GDOI. It needs to be articulated in gkmarch. > This is tricky, since if the policy is to do a "leave group" >message followed by re-registration, there is a potential for >overwhelming/DoS the GCKS if large numbers of members trigger the same >error response at the same time. So the policy should have some ditter in >the timing constant. I know you expressed the view not to do this, but a >member->GCKS "notify" payload would avoid alot of the dropped data and >delay here... Perhaps so. > > I think we should consider an alternative approach and that is to > > bootstrap the security for the reliable multicast protocol (RMP) at the > > time the msec registration protocol is run. The RMP that key management > > uses needs to be in accordance with the policy of the key management > > system; that policy is implemented in the registration exchange. Once= the > > underlying reliable multicast connection is installed, the msec re-key > > message can use it and benefit from its DoS protections as well > > reliable-multicast service. > >Ok, as long as it accomodates the above requirement wrt/ a mandatory to >implement RMP or a default error recovery policy when there is no RMP, >we're set. As I explained above, we don't have a standard RMP. I don't think we need= =20 one so badly either. I think the rudimentary approach will work well. The= =20 alternative is to standardize an RMP in msec. I don't think that should=20 happen. >A snapshot of the policy token spec should be frozen with this capability >in its v1 profile before GSAKMP can move forward to PS. Thomas? Ran? What do you think? Mark > > > > Mark > > > > > > At 08:27 AM 7/3/2003 -0700, Mark Baugher wrote: > > >Laurence, > > > > > >At 03:06 PM 7/2/2003 +0200, Laurence.Duquerroy@space.alcatel.fr wrote: > > ><...> > > > > > >>However we don?t totally agree with you about the need of reliability > > >>mechanisms > > >>in group key management protocols for satellite systems. > > >>The "world of satellite systems" is composed of two main system types= =20 > : Fixe > > >>broadband systems ( i.e. TV broadcasting) and Mobile systems. > > >>Three optimized retransmissions of all re-key messages seem to fulfill > > >>the needs > > >>of fixe broadcast systems without return link, that have an > > >>overprovisionned and > > >>stable link budget. However, in mobile systems or versatile systems= (fast > > >>network inputs/outputs) , or heterogeneous systems, even with three > > >>retransmissions, it is not certain at all that each group member=20 > receives all > > >>re-keying messages. Reliability mechanisms ( based on Nack/ack) would= be > > >>needed. > > >>Finally, it seems easier and more optimized to add some reliability > > >>mechanisms > > >>to Group Key Management protocols (such as GSAKMP) compared to the=20 > use of a > > >>reliable multicast transport protocol which shall also be secured > > >>(signature of > > >>the Acks/Nacks) (Nowadays attacks are successfully launched on TCP > > >>exchanges). > > > > > >I don't think this makes the case why msec should build a reliable > > >multicast protocol into its key management. The arguments for using a > > >reliable multicast protocol rather than incorporating one probably= include > > >the following. > > > > > >1. allows us to select the best protocol for a particular application > > >environment > > >2. allows us to introduce better protocols when they are developed > > >3. reduces the functionality and the complexity of the key management= =20 > protocol > > > > > >Are there others? > > > > > >Probably the best (maybe the only) argument for including it in the key > > >management is security. We need to answer the following questions. > > > > > >1. How can the security of the key management protocol be successfully > > >undermined by attacking the reliable multicast protocol and is this= true > > >for all interesting reliable-multicast protocols. > > >2. How can incorporation of the reliable multicast protocol into the= key > > >management protocol protect against these attacks? > > >3. Is it possible to protect against these attacks without putting the > > >reliable multicast protocol into the key management protocol. > > > > > >Are there others? > > > > > >It's good that you raise this issue now in msec because the previous > > >discussion we had was some time ago in msec's predecessor group, IRTF= =20 > SMuG. > > > > > >Mark > > > > > >>Indeed, as adding lightweight reliability features in GSAKMP optimised > > >>for our > > >>needs can be done for a very low cost, we don't see the need to use an > > >>external > > >>multicast reliable protocol with its own additional signaling and byte > > >>overhead > > >>for authentication and integrity check... > > >> > > >> > > >> > > >> > > >> > Finally, I don't see any difference between your Phase 3 and the= =20 > MSEC > > >> >Rekey protocol (called "groupkey push" in GDOI). Are there= significant > > >> >differences? > > >> > > >>Sorry for my slow response to Mark's question (from the mail below). > > >>Indeed FMKE Phase 3 and GDOI "group key push" are similar. The only > > >>difference > > >>is ... the use of reliability mechanisms (i.e. the use of Nacks and=20 > messages > > >>from the GCKS indicating the last used sequence number). > > >> > > >> > > >>Best regards, > > >> > > >>Laurence > > >> > > >>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 > > >> > > >> > > >> > > >> >Hi, Just to add my 2p worth. > > >> > > >> >We're running a project which has produced a GSAKMP/LKH=20 > implementation for > > >> >use over satellite networks. We have been running the system using a > > >> >satellite link simulator with an error rate of 10-3 and a delay of > > >> 0.25s and > > >> >it works great! > > >> > > >> >All we did was to have all re-key messages repeated three times,=20 > one after > > >> >another. > > >> > > >> >Considering that most modern sat systems say they can give you an= error > > >> rate > > >> >of approx 10-7 or better, I don't think reliability is much of an=20 > issue in > > >> >real world applications. I appreciate it is nice to close the loop,= =20 > as it > > >> >were, but I think the downside of using up valuable bandwidth and= time > > >> (in a > > >> >long transmission delay environment) with acks and nacks is hard to > > >> justify. > > >> > > >> >I would vote on keeping reliability in a separate layer as multicast= is > > >> >great for satellite transmission but a constant return path is not= =20 > always > > >> >available. > > >> > > >> >regards > > >> > > >> >Gavin > > >> > > >> > > >> > > >> >-----Original Message----- > > >> >From: Mark Baugher [mailto:mbaugher@cisco.com] > > >> >Sent: 27 June 2003 16:14 > > >> >To: Laurence.Duquerroy@space.alcatel.fr > > >> >Cc: Brian Weis; Sebastien.Josset@space.alcatel.fr; Lakshminath= Dondeti; > > >> >msec@securemulticast.org > > >> >Subject: [MSEC] Re: [MSEC] R=E9f. : Re: [MSEC] R=E9f. : Re: [ MSEC]= R =E9f. : > > >> >[MSEC] [Fwd: I-D ACTION: draft-duquer-fmke- 00.txt] > > >> > > >> > > >> >Laurence, > > >> > We discussed putting reliability mechanisms into GDOI about=20 > three years > > >> >ago. The decision of the secure multicast research group (SMuG) at= =20 > that > > >> >time was to use the mechanisms that are being developed by another= =20 > group, > > >> >the reliable multicast group, rather than develop our own. MSEC=20 > has also > > >> >taken this approach. > > >> > > >> > So, before we incorporate reliable multicast into an MSEC key=20 > management > > >> >protocol, we need to revisit this decision and discuss the pro's=20 > and con's > > >> >of having an ACK or NAK mechanism built into key management versus= =20 > using a > > >> >separate layer. The advantage that I see of using a separate layer= =20 > is what > > >> >one generally gets from design modularity: We can choose among the= =20 > 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= =20 > the key > > >> >management protocol. > > >> > > >> > Now, what are the advantages to mixing up reliable multicast=20 > with key > > >> >establishment? > > >> > > >> > Finally, I don't see any difference between your Phase 3 and the= =20 > 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 > > >> > > >> > > >> >_______________________________________________ > > >> >msec mailing list > > >> >msec@securemulticast.org > > >> >http://www.pairlist.net/mailman/listinfo/msec > > >> > > >> >This e-mail and any attachment is for authorised use by the intended > > >>recipient(s) only. It may contain proprietary >material, confidential > > >>information and/or be subject to legal privilege. It should not be=20 > copied, > > >>disclosed to, >retained or used by, any other party. If you are not= an > > >>intended > > >>recipient then please promptly delete this e-mail >and any attachment= =20 > and all > > >>copies and inform the sender. Thank you. > > > > > > > > > > > >_______________________________________________ > > >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 Tue Jul 29 12:16:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27885 for ; Tue, 29 Jul 2003 12:16:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 54E1F53805; Tue, 29 Jul 2003 12:16: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 BAC3853547 for ; Tue, 29 Jul 2003 12:14:59 -0400 (EDT) Received: (qmail 72731 invoked by uid 3269); 29 Jul 2003 16:14:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72728 invoked from network); 29 Jul 2003 16:14:59 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 29 Jul 2003 16:14:59 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27705; Tue, 29 Jul 2003 12:14:53 -0400 (EDT) Message-Id: <200307291614.MAA27705@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-mikey-dhhmac-03.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: Tue, 29 Jul 2003 12:14:53 -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 : HMAC-authenticated Diffie-Hellman for MIKEY Author(s) : M. Euchner Filename : draft-ietf-msec-mikey-dhhmac-03.txt Pages : 28 Date : 2003-7-29 This document describes a point-to-point key management protocol variant for the multimedia Internet keying (MIKEY). In particular, the classic Diffie-Hellman key agreement protocol is used for key establishment in conjunction with a keyed hash (HMAC-SHA1) for achieving mutual authentication and message integrity of the key management messages exchanged. This MIKEY variant is called the HMAC-authenticated Diffie-Hellmann (DHHMAC). It addresses the security and performance constraints of multimedia key management in MIKEY. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-dhhmac-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mikey-dhhmac-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-03.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-7-29122720.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mikey-dhhmac-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mikey-dhhmac-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-29122720.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 29 16:50:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08749 for ; Tue, 29 Jul 2003 16:50:52 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 770DD538E4; Tue, 29 Jul 2003 16:50: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 092F853677 for ; Tue, 29 Jul 2003 16:49:19 -0400 (EDT) Received: (qmail 20260 invoked by uid 3269); 29 Jul 2003 20:49:19 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 20256 invoked from network); 29 Jul 2003 20:49:19 -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; 29 Jul 2003 20:49:19 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn2-654.cisco.com [10.21.114.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6TKnFuH018791 for ; Tue, 29 Jul 2003 13:49:16 -0700 (PDT) Message-Id: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: msec@securemulticast.org From: Mark Baugher Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Next gkmarch 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: Tue, 29 Jul 2003 13:49:14 -0700 Hi, I have posted two notes to msec about reliable delivery of re-key messages. We want to discuss the role of reliable multicast in the MSEC Group Key Management I-D. In outline form, here is what I think we should say in the I-D. 1. The Re-key message may be sent multicast and may be sent using reliable multicast. 2. There are multiple types of reliable multicast protocols and products that have different properties. 3. There are no reliable multicast protocols that are standards - yet. 4. The RECOMMENDED design is to NOT incorporate a special-purpose reliable multicast protocol for the Re-key message but to use existing products and future standards for reliable multicast service when such a service is needed for the Re-key message. 5. The minimal operational capability of an MSEC group key management protocol is to support sequencing of the Re-key messages through a sequence number, which is authenticated along with the Re-key message. A sender of Re-key messages may re-transmit multiple copies of the message provided that they have the same sequence number and this repetition is a rudimentary means of overcoming loss along the network path. A member who receives the Re-key message will check the sequence number to detect duplicate and missing Re-key messages. The member receiver will discard duplicate messages that it receives. 6. The group member might be out of synchrony with the GCKS if it receives a Re-key message having a sequence number that is more than one greater than the last sequence number processed. This is one means by which the GCKS member detects that it has missed a Re-key message. A second means occurs when the application that uses the key notifies its group key provider, which is the GCKS member. What action the GCKS member takes is a matter of group policy: The GCKS member SHOULD log the condition and MAY contact the GCKS to re-run the re-registration protocol to obtain a fresh group key. The group policy needs to take into account boundary conditions, such as re-ordered Re-key messages where rekeying is so frequent that two messages can get reordered in an IP network. The group key policy also needs to take into account the potential for denial of service attacks where an attacker delays or deletes a Re-key message in order to force a subnetwork or subset of the members to synchronously contact the GCKS. I think we can write a short section based on this outline. Mark _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 29 17:01:32 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09282 for ; Tue, 29 Jul 2003 17:01:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 23718536B9; Tue, 29 Jul 2003 17:00: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 79A05535A7 for ; Tue, 29 Jul 2003 16:59:07 -0400 (EDT) Received: (qmail 21826 invoked by uid 3269); 29 Jul 2003 20:59:07 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 21823 invoked from network); 29 Jul 2003 20:59:07 -0000 Received: from h65s138a81n47.user.nortelnetworks.com (HELO zsc3s004.nortelnetworks.com) (47.81.138.65) by klesh.pair.com with SMTP; 29 Jul 2003 20:59:07 -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 h6TKx4a02062 for ; Tue, 29 Jul 2003 13:59:04 -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 PXPP1DSD; Tue, 29 Jul 2003 13:59:04 -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 3ZF93QX2; Tue, 29 Jul 2003 16:59:03 -0400 Message-ID: <3F26E017.3060001@nortelnetworks.com> X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Lakshminath Dondeti User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> In-Reply-To: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Tue, 29 Jul 2003 16:59:03 -0400 Content-Transfer-Encoding: 7bit Mark and I went back and forth on this topic and decided that we should take the discussion to the list. So, here is my response. +++++++++++ I have additional thoughts that I was discussing with Thomas, along the following lines. Some of the reliable rekey transport protocols use FEC (which is one of the RMT experimental track protocols) with NACKs for feedback. There are two ways (perhaps more) for members to provide feedback to the GCKS. One is to have a secure feedback channel between the members and the GCKS. The other is to have members that go out of sync to re-register with the GCKS to download the latest SAs, but in doing so allow a feedback message be part of the re-registration request. This will allow the GCKS to change the FEC encoding parameters. And yes, these thoughts and discussion should be part of the GKMarch I-D. A general question is whether RM protocols need any special signaling that need to be part of the MSEC protocols. Feedback (some form of member to GCKS communication) protection comes to mind. cheers, Lakshminath ++++++++++ Mark Baugher wrote: > Hi, > I have posted two notes to msec about reliable delivery of re-key > messages. We want to discuss the role of reliable multicast in the > MSEC Group Key Management I-D. In outline form, here is what I think > we should say in the I-D. > > 1. The Re-key message may be sent multicast and may be sent using > reliable multicast. > > 2. There are multiple types of reliable multicast protocols and > products that have different properties. > > 3. There are no reliable multicast protocols that are standards - yet. > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose > reliable multicast protocol for the Re-key message but to use existing > products and future standards for reliable multicast service when such > a service is needed for the Re-key message. > > 5. The minimal operational capability of an MSEC group key management > protocol is to support sequencing of the Re-key messages through a > sequence number, which is authenticated along with the Re-key > message. A sender of Re-key messages may re-transmit multiple copies > of the message provided that they have the same sequence number and > this repetition is a rudimentary means of overcoming loss along the > network path. A member who receives the Re-key message will check the > sequence number to detect duplicate and missing Re-key messages. The > member receiver will discard duplicate messages that it receives. > > 6. The group member might be out of synchrony with the GCKS if it > receives a Re-key message having a sequence number that is more than > one greater than the last sequence number processed. This is one > means by which the GCKS member detects that it has missed a Re-key > message. A second means occurs when the application that uses the key > notifies its group key provider, which is the GCKS member. What > action the GCKS member takes is a matter of group policy: The GCKS > member SHOULD log the condition and MAY contact the GCKS to re-run the > re-registration protocol to obtain a fresh group key. The group > policy needs to take into account boundary conditions, such as > re-ordered Re-key messages where rekeying is so frequent that two > messages can get reordered in an IP network. The group key policy > also needs to take into account the potential for denial of service > attacks where an attacker delays or deletes a Re-key message in order > to force a subnetwork or subset of the members to synchronously > contact the GCKS. > > I think we can write a short section based on this outline. > > 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 Tue Jul 29 18:12:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12670 for ; Tue, 29 Jul 2003 18:12:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BDAFD538DE; Tue, 29 Jul 2003 18:12: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 64481535E6 for ; Tue, 29 Jul 2003 18:11:36 -0400 (EDT) Received: (qmail 34826 invoked by uid 3269); 29 Jul 2003 22:11:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 34823 invoked from network); 29 Jul 2003 22:11:36 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 29 Jul 2003 22:11:36 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h6TMArfn023428; Tue, 29 Jul 2003 17:10:53 -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 h6TMBM1l014402; Tue, 29 Jul 2003 17:11:22 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id SAA15863; Tue, 29 Jul 2003 18:11:20 -0400 (EDT) Message-ID: <3F26F098.8000403@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 29 Jul 2003 18:09:28 -0400 Content-Transfer-Encoding: 7bit Mark, It might be preferable not to suggest any particular reliable multicast standards as they become available. The r-multicast standards are more focussed on IP-multicast. I believe that our charter was changed to focus more on group communications in general (I may be wrong as the charter does not appear to be updated on ietf.org.) It would be a shame to needlessly couple the rekey protocol with transport protocols and lose the application layer multicast folks. Perhaps that is what you were saying in 3 and 4, but I am misreading your intent to include reliable standards as they are available? Also, another suggestion, for environments where a simple re-registration is not a desireable method of recovery from lost rekey messages, it might be proposed as a matter of that group's policy that they use more loss-tolerant methods such as subset-difference for rekey. Oops, I said the P-word again :-) Anyway, loss-tolerant rekey schemes deserve a paragraph as well. --- Andrea Mark Baugher wrote: > Hi, > I have posted two notes to msec about reliable delivery of re-key > messages. We want to discuss the role of reliable multicast in the > MSEC Group Key Management I-D. In outline form, here is what I think > we should say in the I-D. > > 1. The Re-key message may be sent multicast and may be sent using > reliable multicast. > > 2. There are multiple types of reliable multicast protocols and > products that have different properties. > > 3. There are no reliable multicast protocols that are standards - yet. > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose > reliable multicast protocol for the Re-key message but to use existing > products and future standards for reliable multicast service when such > a service is needed for the Re-key message. > > 5. The minimal operational capability of an MSEC group key management > protocol is to support sequencing of the Re-key messages through a > sequence number, which is authenticated along with the Re-key > message. A sender of Re-key messages may re-transmit multiple copies > of the message provided that they have the same sequence number and > this repetition is a rudimentary means of overcoming loss along the > network path. A member who receives the Re-key message will check the > sequence number to detect duplicate and missing Re-key messages. The > member receiver will discard duplicate messages that it receives. > > 6. The group member might be out of synchrony with the GCKS if it > receives a Re-key message having a sequence number that is more than > one greater than the last sequence number processed. This is one > means by which the GCKS member detects that it has missed a Re-key > message. A second means occurs when the application that uses the key > notifies its group key provider, which is the GCKS member. What > action the GCKS member takes is a matter of group policy: The GCKS > member SHOULD log the condition and MAY contact the GCKS to re-run the > re-registration protocol to obtain a fresh group key. The group > policy needs to take into account boundary conditions, such as > re-ordered Re-key messages where rekeying is so frequent that two > messages can get reordered in an IP network. The group key policy > also needs to take into account the potential for denial of service > attacks where an attacker delays or deletes a Re-key message in order > to force a subnetwork or subset of the members to synchronously > contact the GCKS. > > I think we can write a short section based on this outline. > > 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 Tue Jul 29 19:38:40 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15603 for ; Tue, 29 Jul 2003 19:38:38 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 898D95389C; Tue, 29 Jul 2003 19:38: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 36FDD535E4 for ; Tue, 29 Jul 2003 19:36:37 -0400 (EDT) Received: (qmail 48199 invoked by uid 3269); 29 Jul 2003 23:36:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 48196 invoked from network); 29 Jul 2003 23:36:37 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 29 Jul 2003 23:36:37 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn2-654.cisco.com [10.21.114.142]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6TNaQpq023155; Tue, 29 Jul 2003 16:36:27 -0700 (PDT) Message-Id: <5.1.1.5.2.20030729161529.07427ef8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: msec@securemulticast.org In-Reply-To: <3F26F098.8000403@columbia.sparta.com> References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 29 Jul 2003 16:35:58 -0700 hi Andrea, At 06:09 PM 7/29/2003 -0400, Andrea Colegrove wrote: >Mark, > >It might be preferable not to suggest any particular reliable multicast >standards as they become available. The r-multicast standards are more >focussed on IP-multicast. I believe that our charter was changed to focus >more on group communications in general (I may be wrong as the charter >does not appear to be updated on ietf.org.) It would be a shame to >needlessly couple the rekey protocol with transport protocols and lose the >application layer multicast folks. Perhaps that is what you were saying >in 3 and 4, but I am misreading your intent to include reliable standards >as they are available? My intent is de-couple reliable multicast transport from key management. I think that's clear from my previous posts but not necessarily from the outline. The outline addresses the question of what to do *if* a reliable multicast service is wanted for the rekey message, which may be sent via IP multicast and thus using reliable multicast if desired. The outline points out that there are no standards yet and recommends that we not standardize a reliable multicast protocol as part of group key management. For those persons who want reliable multicast service for the rekey, and a couple have voiced this need on this mailing list, I would recommend that they use one of the RMT standards when RMT produces them. RMT keying will need to used msec group key management in the form of GDOI, GSAKMP or possibly MIKEY (though this application is not high on MIKEY's list of applications). So it might sound circular for me to then recommend use of an RMT protocol for group key management. But for those who need it, the outline recommends that RMT keys be established through the registration protocol. I think we're in agreement and I just need to clarify my intent. >Also, another suggestion, for environments where a simple re-registration >is not a desireable method of recovery from lost rekey messages, it might >be proposed as a matter of that group's policy that they use more >loss-tolerant methods such as subset-difference for rekey. I don't think SD is loss tolerant. I expect that an SD keying message will look more like a small file transfer, no part of which can be lost. Also, we need to keep in mind that SD is not an open standard and has known IPR encumbrances. I don't think it looks promising for IETF standardization at the present time. >Oops, I said the P-word again :-) Hopefully someone will start on the msec policy specification soon. >Anyway, loss-tolerant rekey schemes deserve a paragraph as well. I don't understand your point about SD. We did have a presentation from Jessica Staddon in GSEC some time back (http://www.securemulticast.org/GSEC/gsec2_staddon.pdf) on this topic. Frankly, I have not looked closely at the relevant literature on loss-tolerant rekey. Perhaps you're right and we should add a paragraph on it. I'm open to suggestions. Mark >--- Andrea > >Mark Baugher wrote: > >>Hi, >> I have posted two notes to msec about reliable delivery of re-key >> messages. We want to discuss the role of reliable multicast in the MSEC >> Group Key Management I-D. In outline form, here is what I think we >> should say in the I-D. >> >>1. The Re-key message may be sent multicast and may be sent using >>reliable multicast. >> >>2. There are multiple types of reliable multicast protocols and products >>that have different properties. >> >>3. There are no reliable multicast protocols that are standards - yet. >> >>4. The RECOMMENDED design is to NOT incorporate a special-purpose >>reliable multicast protocol for the Re-key message but to use existing >>products and future standards for reliable multicast service when such a >>service is needed for the Re-key message. >> >>5. The minimal operational capability of an MSEC group key management >>protocol is to support sequencing of the Re-key messages through a >>sequence number, which is authenticated along with the Re-key message. A >>sender of Re-key messages may re-transmit multiple copies of the message >>provided that they have the same sequence number and this repetition is a >>rudimentary means of overcoming loss along the network path. A member >>who receives the Re-key message will check the sequence number to detect >>duplicate and missing Re-key messages. The member receiver will discard >>duplicate messages that it receives. >> >>6. The group member might be out of synchrony with the GCKS if it >>receives a Re-key message having a sequence number that is more than one >>greater than the last sequence number processed. This is one means by >>which the GCKS member detects that it has missed a Re-key message. A >>second means occurs when the application that uses the key notifies its >>group key provider, which is the GCKS member. What action the GCKS >>member takes is a matter of group policy: The GCKS member SHOULD log the >>condition and MAY contact the GCKS to re-run the re-registration protocol >>to obtain a fresh group key. The group policy needs to take into account >>boundary conditions, such as re-ordered Re-key messages where rekeying is >>so frequent that two messages can get reordered in an IP network. The >>group key policy also needs to take into account the potential for denial >>of service attacks where an attacker delays or deletes a Re-key message >>in order to force a subnetwork or subset of the members to synchronously >>contact the GCKS. >> >>I think we can write a short section based on this outline. >> >>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 Tue Jul 29 19:55:07 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16035 for ; Tue, 29 Jul 2003 19:55:07 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 27FA6538E4; Tue, 29 Jul 2003 19:54:30 -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 4BA17538A0 for ; Tue, 29 Jul 2003 19:50:13 -0400 (EDT) Received: (qmail 49739 invoked by uid 3269); 29 Jul 2003 23:50:13 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 49736 invoked from network); 29 Jul 2003 23:50:12 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 29 Jul 2003 23:50:12 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h6TNnbfn024089; Tue, 29 Jul 2003 18:49:38 -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 h6TNo61l016267; Tue, 29 Jul 2003 18:50:06 -0500 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id TAA16679; Tue, 29 Jul 2003 19:50:05 -0400 (EDT) Message-ID: <3F2707BC.5070706@columbia.sparta.com> From: Andrea Colegrove User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030729161529.07427ef8@mira-sjc5-6.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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, 29 Jul 2003 19:48:12 -0400 Content-Transfer-Encoding: 7bit Mark > >> Also, another suggestion, for environments where a simple >> re-registration is not a desireable method of recovery from lost >> rekey messages, it might be proposed as a matter of that group's >> policy that they use more loss-tolerant methods such as >> subset-difference for rekey. > > > I don't think SD is loss tolerant. I expect that an SD keying message > will look more like a small file transfer, no part of which can be > lost. Also, we need to keep in mind that SD is not an open standard > and has known IPR encumbrances. I don't think it looks promising for > IETF standardization at the present time. > >> Anyway, loss-tolerant rekey schemes deserve a paragraph as well. > > > I don't understand your point about SD. We did have a presentation > from Jessica Staddon in GSEC some time back > (http://www.securemulticast.org/GSEC/gsec2_staddon.pdf) on this > topic. Frankly, I have not looked closely at the relevant literature > on loss-tolerant rekey. Perhaps you're right and we should add a > paragraph on it. I'm open to suggestions. I believe that you can miss a rekey "event" and still be able to understand subsequent events (i.e., all your keys do not change as they do with some of the other schemes.) While you would be out for a small epoch, you would be back in at the next rekey. Also, smaller rekey messages will allow more resends within the same amount of bandwidth expended. Didn't the authors of SD provide an I-D a little while back? I am really largely ignorant of the I-D process, but I thought that the "thoughts" presented through the IETF are not encumbered. --- Andrea _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 29 21:29:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18789 for ; Tue, 29 Jul 2003 21:29:36 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 27BD2538FA; Tue, 29 Jul 2003 21:26:19 -0400 (EDT) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2C87953573 for ; Tue, 29 Jul 2003 21:22:45 -0400 (EDT) Received: (qmail 63282 invoked by uid 3269); 30 Jul 2003 01:22:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63279 invoked from network); 30 Jul 2003 01:22:44 -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; 30 Jul 2003 01:22:44 -0000 Received: from cisco.com ([128.107.177.101]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h6U1MfpZ010972 for ; Tue, 29 Jul 2003 18:22:42 -0700 (PDT) Message-ID: <3F271DE0.4BF07F09@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [MSEC] Announcement of draft-ietf-msec-arch-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:22:40 -0700 Content-Transfer-Encoding: 7bit Thanks to everyone who provided comments on the MSEC Arch -01 draft, and to those who discussed it on the list. I've attempted to address those comments and discussion in the -02 draft, which was submitted today. Thomas has made an early copy available for your immediate perusal, and further comments are welcomed. As previously announced, the last call for the document ends on Friday, 8 August 2003. http://www.securemulticast.org/draft-ietf-msec-arch-02.txt Here is a summary of the changes: 1. Formatting nits: a. Funny looking bullets were fixed. b. Mis-numbered headings were re-numbered. 2. Addition of a "Scope" section as Section 1.1. This section attempts to address much of the discussion on this list regarding IP multicast routing, IGMP, NAT, and reliability. 3. The text in Section 4.3 was re-worded to match section 4.4 4. Text was added to Section 5.4 to clarify the separation of IGMP "joins"/"leaves" and group key management "joins"/"leaves". 5. A sentence was added to Section 5.5 regarding PKI. Thanks, Brian -- Brian Weis Strategic Cryptographic Development, ITD, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Jul 29 21:48:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19334 for ; Tue, 29 Jul 2003 21:48:31 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2D65C53711; Tue, 29 Jul 2003 21:48: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 085E15355A for ; Tue, 29 Jul 2003 21:47:07 -0400 (EDT) Received: (qmail 75099 invoked by uid 3269); 30 Jul 2003 01:47:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 75084 invoked from network); 30 Jul 2003 01:47:03 -0000 Received: from sj-iport-2-in.cisco.com (HELO sj-iport-2.cisco.com) (171.71.176.71) by klesh.pair.com with SMTP; 30 Jul 2003 01:47:03 -0000 Received: from cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 29 Jul 2003 18:49:49 -0700 Received: from cscoamera13263.cisco.com (sjc-vpn2-654.cisco.com [10.21.114.142]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id h6U1l0uH020303; Tue, 29 Jul 2003 18:47:01 -0700 (PDT) Message-Id: <5.1.1.5.2.20030729170159.07399820@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Andrea Colegrove From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: msec@securemulticast.org In-Reply-To: <3F2707BC.5070706@columbia.sparta.com> References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030729161529.07427ef8@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 29 Jul 2003 18:46:59 -0700 hi At 07:48 PM 7/29/2003 -0400, Andrea Colegrove wrote: >Mark > >> >>>Also, another suggestion, for environments where a simple >>>re-registration is not a desireable method of recovery from lost rekey >>>messages, it might be proposed as a matter of that group's policy that >>>they use more loss-tolerant methods such as subset-difference for rekey. >> >> >>I don't think SD is loss tolerant. I expect that an SD keying message >>will look more like a small file transfer, no part of which can be >>lost. Also, we need to keep in mind that SD is not an open standard and >>has known IPR encumbrances. I don't think it looks promising for IETF >>standardization at the present time. >> >>>Anyway, loss-tolerant rekey schemes deserve a paragraph as well. >> >> >>I don't understand your point about SD. We did have a presentation from >>Jessica Staddon in GSEC some time back >>(http://www.securemulticast.org/GSEC/gsec2_staddon.pdf) on this >>topic. Frankly, I have not looked closely at the relevant literature on >>loss-tolerant rekey. Perhaps you're right and we should add a paragraph >>on it. I'm open to suggestions. > >I believe that you can miss a rekey "event" and still be able to >understand subsequent events (i.e., all your keys do not change as they do >with some of the other schemes.) While you would be out for a small >epoch, you would be back in at the next rekey. Also, smaller rekey >messages will allow more resends within the same amount of bandwidth expended. With SD you would encrypt a session key with a key encrypting key that is derived from your current subset of the tree. SD requires that the receiver have enough of that tree to be able to derive the keys from its particular subset. That's the data structure that must be passed to the member in its entirety. In this sense, SD is no different from LKH or OFT if the entire history of the latter algorithms were passed down with the tree. SD does this much more efficiently in terms of storage and computation compared with LKH and OFT. Unlike LKH and OFT, incremental updates to the tree are not needed by SD. So, I would not use "loss tolerant" to describe SD. >Didn't the authors of SD provide an I-D a little while back? Yes they did. But they let us know that their company had IPR on it and they would give us an IPR statement in the second revision of the I-D. But they never did a second revision. >I am really largely ignorant of the I-D process, but I thought that the >"thoughts" presented through the IETF are not encumbered. I should take a look at the latest word on this but someone can surely present to the IETF any invention, system or apparatus for which they have previously filed a patent without invalidating the patent in any way. Mark >--- Andrea > > > >_______________________________________________ >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 Jul 31 09:11:49 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24267 for ; Thu, 31 Jul 2003 09:11:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7433E535BE; Thu, 31 Jul 2003 09:11: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 2A8345355A for ; Thu, 31 Jul 2003 09:08:59 -0400 (EDT) Received: (qmail 92485 invoked by uid 3269); 30 Jul 2003 17:20:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92482 invoked from network); 30 Jul 2003 17:20:50 -0000 Received: from ckmso2.att.com (HELO ckmso2.proxy.att.com) (209.219.209.75) by klesh.pair.com with SMTP; 30 Jul 2003 17:20:50 -0000 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso2.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id h6UHHeFi030202 for ; Wed, 30 Jul 2003 13:20:49 -0400 Received: from occlust04evs1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (6.5.032) id 3EE9217C010C08E7 for msec@securemulticast.org; Wed, 30 Jul 2003 13:20:42 -0400 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Wed, 30 Jul 2003 12:20:24 -0500 Received: from OCCLUST02EVS1.ugd.att.com ([135.38.164.9]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 10:04:36 -0500 Received: from acfe01.ugd.att.com ([135.37.16.16]) by OCCLUST02EVS1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 10:04:29 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by acfe01.ugd.att.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 30 Jul 2003 11:04:35 -0400 Received: from alpmx1.proxy.att.com (192.168.108.105) by attrh0i.attrh.att.com (6.5.032) id 3F08489B0054CAFE for gayen@ems.att.com; Wed, 30 Jul 2003 11:03:44 -0400 X-PMX-From: ;owner-ietf-announce@ietf.org; X-PMX-To: 1; Received: from almsi1.proxy.att.com (almsi1.proxy.att.com [192.168.108.71]) by alpmx1.proxy.att.com (AT&T IPNS/PMX-5.0) with ESMTP id h6UF4X7E012303 for ; Wed, 30 Jul 2003 11:04:33 -0400 X-MSI-From: ;owner-ietf-announce@ietf.org; X-MSI-To: 1; Received: from asgard.ietf.org ([132.151.6.40]) by almsi1.proxy.att.com (AT&T IPNS/MSI-5.0) with ESMTP id h6UF3opP001123 for ; Wed, 30 Jul 2003 11:04:27 -0400 Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19hrD1-0005yF-57 for ietf-announce-list@asgard.ietf.org; Wed, 30 Jul 2003 09:41:39 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19hrCj-0005wD-R5 for all-ietf@asgard.ietf.org; Wed, 30 Jul 2003 09:41:21 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00388; Wed, 30 Jul 2003 09:41:16 -0400 (EDT) Message-Id: <200307301341.JAA00388@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 Precedence: bulk X-ATT-Spam: Gauge=XXXXIII, Probability=43%, Report='NO_REAL_NAME, TO_MALFORMED, SEARCH_ENGINE_PROMO, SPAM_PHRASE_01_02' X-OriginalArrivalTime: 30 Jul 2003 15:04:35.0334 (UTC) FILETIME=[E3897A60:01C356AB] Subject: [MSEC] I-D ACTION:draft-ietf-msec-arch-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:41:16 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Multicast Security Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-02.txt Pages : 22 Date : 2003-7-30 This document provides a foundation for the protocols developed by the Multicast Security (MSEC) group. The document begins by introducing a Reference Framework, and proceeds to identify functional areas which must be addressed as part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-30095936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-30095936.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 09:51:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25628 for ; Thu, 31 Jul 2003 09:51:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7F0CD537C6; Thu, 31 Jul 2003 09:50: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 DD7DA53904 for ; Thu, 31 Jul 2003 09:47:11 -0400 (EDT) Received: (qmail 51410 invoked by uid 3269); 30 Jul 2003 14:06:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51407 invoked from network); 30 Jul 2003 14:06:06 -0000 Received: from m4.sparta.com (157.185.61.2) by klesh.pair.com with SMTP; 30 Jul 2003 14:06:06 -0000 Received: from beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by m4.sparta.com (8.12.8/8.12.8) with ESMTP id h6UE5Tfn028592; Wed, 30 Jul 2003 09:05:29 -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 h6UE601l026392; Wed, 30 Jul 2003 09:06:00 -0500 Received: from sparta.com (dhcp-7.columbia.sparta.com [157.185.80.8]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA22460; Wed, 30 Jul 2003 10:05:59 -0400 (EDT) Subject: Re: [MSEC] Next gkmarch I-D Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: msec@securemulticast.org To: Mark Baugher From: Hugh Harney In-Reply-To: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.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: Wed, 30 Jul 2003 10:05:58 -0400 Content-Transfer-Encoding: 7bit Mark, I completely agree with this outline on reliable delivery of re-key messages. Hugh On Tuesday, Jul 29, 2003, at 16:49 US/Eastern, Mark Baugher wrote: > Hi, > I have posted two notes to msec about reliable delivery of re-key > messages. We want to discuss the role of reliable multicast in the > MSEC Group Key Management I-D. In outline form, here is what I think > we should say in the I-D. > > 1. The Re-key message may be sent multicast and may be sent using > reliable multicast. > > 2. There are multiple types of reliable multicast protocols and > products that have different properties. > > 3. There are no reliable multicast protocols that are standards - yet. > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose > reliable multicast protocol for the Re-key message but to use existing > products and future standards for reliable multicast service when such > a service is needed for the Re-key message. > > 5. The minimal operational capability of an MSEC group key management > protocol is to support sequencing of the Re-key messages through a > sequence number, which is authenticated along with the Re-key message. > A sender of Re-key messages may re-transmit multiple copies of the > message provided that they have the same sequence number and this > repetition is a rudimentary means of overcoming loss along the network > path. A member who receives the Re-key message will check the > sequence number to detect duplicate and missing Re-key messages. The > member receiver will discard duplicate messages that it receives. > > 6. The group member might be out of synchrony with the GCKS if it > receives a Re-key message having a sequence number that is more than > one greater than the last sequence number processed. This is one > means by which the GCKS member detects that it has missed a Re-key > message. A second means occurs when the application that uses the key > notifies its group key provider, which is the GCKS member. What > action the GCKS member takes is a matter of group policy: The GCKS > member SHOULD log the condition and MAY contact the GCKS to re-run the > re-registration protocol to obtain a fresh group key. The group > policy needs to take into account boundary conditions, such as > re-ordered Re-key messages where rekeying is so frequent that two > messages can get reordered in an IP network. The group key policy > also needs to take into account the potential for denial of service > attacks where an attacker delays or deletes a Re-key message in order > to force a subnetwork or subset of the members to synchronously > contact the GCKS. > > I think we can write a short section based on this outline. > > Mark > > > _______________________________________________ > 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 Thu Jul 31 09:52:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25659 for ; Thu, 31 Jul 2003 09:52:47 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CA64953920; Thu, 31 Jul 2003 09:52: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 F33C3537C6 for ; Thu, 31 Jul 2003 09:51:47 -0400 (EDT) Received: (qmail 47534 invoked by uid 3269); 30 Jul 2003 13:41:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 47531 invoked from network); 30 Jul 2003 13:41:21 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 30 Jul 2003 13:41:21 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00388; Wed, 30 Jul 2003 09:41:16 -0400 (EDT) Message-Id: <200307301341.JAA00388@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: msec@securemulticast.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [MSEC] I-D ACTION:draft-ietf-msec-arch-02.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 30 Jul 2003 09:41:16 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Multicast Security Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-02.txt Pages : 22 Date : 2003-7-30 This document provides a foundation for the protocols developed by the Multicast Security (MSEC) group. The document begins by introducing a Reference Framework, and proceeds to identify functional areas which must be addressed as part of a secure multicast solution. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-arch-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-arch-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-arch-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-7-30095936.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-7-30095936.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 12:35:58 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03588 for ; Thu, 31 Jul 2003 12:35:57 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 25D9753950; Thu, 31 Jul 2003 12:34:29 -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 17CA4537B8 for ; Thu, 31 Jul 2003 12:32:01 -0400 (EDT) Received: (qmail 68015 invoked by uid 3269); 31 Jul 2003 16:32:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68007 invoked from network); 31 Jul 2003 16:32:01 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 31 Jul 2003 16:32:01 -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 h6VGU7V37468; Thu, 31 Jul 2003 12:30:07 -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 h6VGVpa45374; Thu, 31 Jul 2003 12:31:51 -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 MAA35290; Thu, 31 Jul 2003 12:31:51 -0400 From: canetti To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.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: Thu, 31 Jul 2003 12:31:50 -0400 (EDT) Mark, Your outline looks good to me. It well represents the (unfortunately not very well documented) understanding at SMUG, and indeed seems like the right thing to do. See some small remarks inline. Ran On Tue, 29 Jul 2003, Mark Baugher wrote: > Hi, > I have posted two notes to msec about reliable delivery of re-key > messages. We want to discuss the role of reliable multicast in the MSEC > Group Key Management I-D. In outline form, here is what I think we should > say in the I-D. > > 1. The Re-key message may be sent multicast and may be sent using reliable > multicast. > > 2. There are multiple types of reliable multicast protocols and products > that have different properties. > > 3. There are no reliable multicast protocols that are standards - yet. > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose reliable > multicast protocol for the Re-key message but to use existing products and > future standards for reliable multicast service when such a service is > needed for the Re-key message. I'm not sure we should recommend a design. There are many different deployment scenarios, with very different needs. We should mandate the rudimentary design and leave other designs optional. > > 5. The minimal operational capability of an MSEC group key management > protocol is to support sequencing of the Re-key messages through a sequence > number, which is authenticated along with the Re-key message. A sender of > Re-key messages may re-transmit multiple copies of the message provided > that they have the same sequence number and this repetition is a > rudimentary means of overcoming loss along the network path. A member who > receives the Re-key message will check the sequence number to detect > duplicate and missing Re-key messages. The member receiver will discard > duplicate messages that it receives. > > 6. The group member might be out of synchrony with the GCKS if it receives > a Re-key message having a sequence number that is more than one greater > than the last sequence number processed. This is one means by which the > GCKS member detects that it has missed a Re-key message. A second means > occurs when the application that uses the key notifies its group key > provider, which is the GCKS member. What action the GCKS member takes is > a matter of group policy: The GCKS member SHOULD log the condition and MAY > contact the GCKS to re-run the re-registration protocol to obtain a fresh > group key. The group policy needs to take into account boundary > conditions, such as re-ordered Re-key messages where rekeying is so > frequent that two messages can get reordered in an IP network. The group > key policy also needs to take into account the potential for denial of > service attacks where an attacker delays or deletes a Re-key message in > order to force a subnetwork or subset of the members to synchronously > contact the GCKS. > > I think we can write a short section based on this outline. A couple more points: * I think that the decision to mandate only the "rudimentary" reliability mechanism should be well motivated in the text. Also, we can say that this decision may be revisited in few years if/when other mechanisms will become popular/standardized and it will make sense to mandate their implementation. * I think that we're missing a good comparative discussion of GKM algorithms and their salient properties. The fact that SD can easily revover from loss of rekey messages is a point to be highlighted. > > Mark > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 12:43:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03759 for ; Thu, 31 Jul 2003 12:43:33 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2E7B45394F; Thu, 31 Jul 2003 12:41: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 49DD55394F for ; Thu, 31 Jul 2003 12:37:39 -0400 (EDT) Received: (qmail 68974 invoked by uid 3269); 31 Jul 2003 16:37:39 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 68971 invoked from network); 31 Jul 2003 16:37:39 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 31 Jul 2003 16:37: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 h6VGZeV108892; Thu, 31 Jul 2003 12:35:40 -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 h6VGbOa47204; Thu, 31 Jul 2003 12:37:24 -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 MAA35296; Thu, 31 Jul 2003 12:37:24 -0400 From: canetti To: Mark Baugher Cc: Andrea Colegrove , msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030729170159.07399820@mira-sjc5-6.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: Thu, 31 Jul 2003 12:37:23 -0400 (EDT) On Tue, 29 Jul 2003, Mark Baugher wrote: ... If there is interest then I can ping the uthors regarding IP/ second version of the I-D. Ran > > >Didn't the authors of SD provide an I-D a little while back? > > Yes they did. But they let us know that their company had IPR on it and > they would give us an IPR statement in the second revision of the I-D. But > they never did a second revision. > > >I am really largely ignorant of the I-D process, but I thought that the > >"thoughts" presented through the IETF are not encumbered. > > I should take a look at the latest word on this but someone can surely > present to the IETF any invention, system or apparatus for which they have > previously filed a patent without invalidating the patent in any way. > > Mark > > > >--- Andrea > > > > > > > >_______________________________________________ > >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 Jul 31 12:52:52 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03980 for ; Thu, 31 Jul 2003 12:52:51 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id C6285536AA; Thu, 31 Jul 2003 12:52: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 8833A5354E for ; Thu, 31 Jul 2003 12:50:24 -0400 (EDT) Received: (qmail 70819 invoked by uid 3269); 31 Jul 2003 16:50:24 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 70816 invoked from network); 31 Jul 2003 16:50:24 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 31 Jul 2003 16:50:24 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-637.cisco.com [10.21.82.125]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VGoLpq009259; Thu, 31 Jul 2003 09:50:22 -0700 (PDT) Message-Id: <5.1.1.5.2.20030731094401.05e8c148@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: canetti From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: msec@securemulticast.org In-Reply-To: References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 31 Jul 2003 09:50:20 -0700 Ran, My comments are inline. At 12:31 PM 7/31/2003 -0400, canetti wrote: >Mark, > >Your outline looks good to me. It well represents the (unfortunately not >very well documented) understanding at SMUG, and indeed seems >like the right thing to do. See some small remarks inline. > > >Ran > > > >On Tue, 29 Jul 2003, Mark Baugher wrote: > > > Hi, > > I have posted two notes to msec about reliable delivery of re-key > > messages. We want to discuss the role of reliable multicast in the MSEC > > Group Key Management I-D. In outline form, here is what I think we should > > say in the I-D. > > > > 1. The Re-key message may be sent multicast and may be sent using reliable > > multicast. > > > > 2. There are multiple types of reliable multicast protocols and products > > that have different properties. > > > > 3. There are no reliable multicast protocols that are standards - yet. > > > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose > reliable > > multicast protocol for the Re-key message but to use existing products and > > future standards for reliable multicast service when such a service is > > needed for the Re-key message. > >I'm not sure we should recommend a design. There are many different >deployment scenarios, with very different needs. We should mandate the >rudimentary design and leave other designs optional. The question to be answered is should msec key management protocols incorporate a reliable multicast protocol. If we recommend that they don't, then there is nothing for us to do. If we recommend that they do, then we should provide some guidance for reliable multicast in group key management. If we don't say anything, then it seems to me that we are overlooking an important question that has been raised in msec regarding the architecture of msec group key management. > > > > > 5. The minimal operational capability of an MSEC group key management > > protocol is to support sequencing of the Re-key messages through a > sequence > > number, which is authenticated along with the Re-key message. A sender of > > Re-key messages may re-transmit multiple copies of the message provided > > that they have the same sequence number and this repetition is a > > rudimentary means of overcoming loss along the network path. A member who > > receives the Re-key message will check the sequence number to detect > > duplicate and missing Re-key messages. The member receiver will discard > > duplicate messages that it receives. > > > > 6. The group member might be out of synchrony with the GCKS if it > receives > > a Re-key message having a sequence number that is more than one greater > > than the last sequence number processed. This is one means by which the > > GCKS member detects that it has missed a Re-key message. A second means > > occurs when the application that uses the key notifies its group key > > provider, which is the GCKS member. What action the GCKS member takes is > > a matter of group policy: The GCKS member SHOULD log the condition and > MAY > > contact the GCKS to re-run the re-registration protocol to obtain a fresh > > group key. The group policy needs to take into account boundary > > conditions, such as re-ordered Re-key messages where rekeying is so > > frequent that two messages can get reordered in an IP network. The group > > key policy also needs to take into account the potential for denial of > > service attacks where an attacker delays or deletes a Re-key message in > > order to force a subnetwork or subset of the members to synchronously > > contact the GCKS. > > > > I think we can write a short section based on this outline. > >A couple more points: > >* I think that the decision to mandate only the "rudimentary" reliability >mechanism should be well motivated in the text. Also, we can say that this >decision may be revisited in few years if/when other mechanisms will >become popular/standardized and it will make sense to mandate their >implementation. ok. >* I think that we're missing a good comparative discussion of GKM >algorithms and their salient properties. The fact that SD can easily >revover from loss of rekey messages is a point to be highlighted. I don't think it is true that SD can recover from lost rekey messages. Andrea and I just had an exchange on this point. A couple of years ago, J.Staddon made a presentation to GSEC on a mechanism that recovered from lost key management but that's different from an SD tree, which needs to be received in its entirety. I think that the SD tree does not need rekey messages when members are evicted or join the tree, and that's not the same as saying that it is loss resilient. ciao, Mark > > > >Mark > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 13:03:48 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04406 for ; Thu, 31 Jul 2003 13:03:48 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6905A53664; Thu, 31 Jul 2003 13:00:30 -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 0A94753966 for ; Thu, 31 Jul 2003 12:58:30 -0400 (EDT) Received: (qmail 72056 invoked by uid 3269); 31 Jul 2003 16:58:30 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 72051 invoked from network); 31 Jul 2003 16:58:28 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 31 Jul 2003 16:58:28 -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 h6VGuZV116962; Thu, 31 Jul 2003 12:56:35 -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 h6VGwJa44974; Thu, 31 Jul 2003 12:58:19 -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 MAA38530; Thu, 31 Jul 2003 12:58:19 -0400 From: canetti To: Mark Baugher Cc: msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030731094401.05e8c148@mira-sjc5-6.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: Thu, 31 Jul 2003 12:58:19 -0400 (EDT) On Thu, 31 Jul 2003, Mark Baugher wrote: > Ran, > My comments are inline. > > At 12:31 PM 7/31/2003 -0400, canetti wrote: > > >Mark, > > > >Your outline looks good to me. It well represents the (unfortunately not > >very well documented) understanding at SMUG, and indeed seems > >like the right thing to do. See some small remarks inline. > > > > > >Ran > > > > > > > >On Tue, 29 Jul 2003, Mark Baugher wrote: > > > > > Hi, > > > I have posted two notes to msec about reliable delivery of re-key > > > messages. We want to discuss the role of reliable multicast in the MSEC > > > Group Key Management I-D. In outline form, here is what I think we should > > > say in the I-D. > > > > > > 1. The Re-key message may be sent multicast and may be sent using reliable > > > multicast. > > > > > > 2. There are multiple types of reliable multicast protocols and products > > > that have different properties. > > > > > > 3. There are no reliable multicast protocols that are standards - yet. > > > > > > 4. The RECOMMENDED design is to NOT incorporate a special-purpose > > reliable > > > multicast protocol for the Re-key message but to use existing products and > > > future standards for reliable multicast service when such a service is > > > needed for the Re-key message. > > > >I'm not sure we should recommend a design. There are many different > >deployment scenarios, with very different needs. We should mandate the > >rudimentary design and leave other designs optional. > > The question to be answered is should msec key management protocols > incorporate a reliable multicast protocol. If we recommend that they > don't, then there is nothing for us to do. If we recommend that they do, > then we should provide some guidance for reliable multicast in group key > management. If we don't say anything, then it seems to me that we are > overlooking an important question that has been raised in msec regarding > the architecture of msec group key management. We should certainly discuss the relevant arguments pro/con using RMT protocols here. But in the end I'm not sure we should recommend anything (or that our recommendation will be of any value. Each scenario would have its own constraints.) > > > > > > > > > 5. The minimal operational capability of an MSEC group key management > > > protocol is to support sequencing of the Re-key messages through a > > sequence > > > number, which is authenticated along with the Re-key message. A sender of > > > Re-key messages may re-transmit multiple copies of the message provided > > > that they have the same sequence number and this repetition is a > > > rudimentary means of overcoming loss along the network path. A member who > > > receives the Re-key message will check the sequence number to detect > > > duplicate and missing Re-key messages. The member receiver will discard > > > duplicate messages that it receives. > > > > > > 6. The group member might be out of synchrony with the GCKS if it > > receives > > > a Re-key message having a sequence number that is more than one greater > > > than the last sequence number processed. This is one means by which the > > > GCKS member detects that it has missed a Re-key message. A second means > > > occurs when the application that uses the key notifies its group key > > > provider, which is the GCKS member. What action the GCKS member takes is > > > a matter of group policy: The GCKS member SHOULD log the condition and > > MAY > > > contact the GCKS to re-run the re-registration protocol to obtain a fresh > > > group key. The group policy needs to take into account boundary > > > conditions, such as re-ordered Re-key messages where rekeying is so > > > frequent that two messages can get reordered in an IP network. The group > > > key policy also needs to take into account the potential for denial of > > > service attacks where an attacker delays or deletes a Re-key message in > > > order to force a subnetwork or subset of the members to synchronously > > > contact the GCKS. > > > > > > I think we can write a short section based on this outline. > > > >A couple more points: > > > >* I think that the decision to mandate only the "rudimentary" reliability > >mechanism should be well motivated in the text. Also, we can say that this > >decision may be revisited in few years if/when other mechanisms will > >become popular/standardized and it will make sense to mandate their > >implementation. > > ok. > > > >* I think that we're missing a good comparative discussion of GKM > >algorithms and their salient properties. The fact that SD can easily > >revover from loss of rekey messages is a point to be highlighted. > > I don't think it is true that SD can recover from lost rekey > messages. Andrea and I just had an exchange on this point. A couple of > years ago, J.Staddon made a presentation to GSEC on a mechanism that > recovered from lost key management but that's different from an SD tree, > which needs to be received in its entirety. I think that the SD tree does > not need rekey messages when members are evicted or join the tree, and > that's not the same as saying that it is loss resilient. > Yes, you're right that there is a (subset :) difference here. But the end result is similar: there is no need in any reliability mechanisms (not even simple restransmission) Ran > ciao, Mark > > > > > > > >Mark > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://www.pairlist.net/mailman/listinfo/msec > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 13:14:31 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04730 for ; Thu, 31 Jul 2003 13:14:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6A35053814; Thu, 31 Jul 2003 13:13: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 8955C535BD for ; Thu, 31 Jul 2003 13:09:36 -0400 (EDT) Received: (qmail 73976 invoked by uid 3269); 31 Jul 2003 17:09:36 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 73973 invoked from network); 31 Jul 2003 17:09:36 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 31 Jul 2003 17:09:36 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-637.cisco.com [10.21.82.125]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VH9Epq026335; Thu, 31 Jul 2003 10:09:15 -0700 (PDT) Message-Id: <5.1.1.5.2.20030731100154.05e8c318@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: canetti From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: Andrea Colegrove , msec@securemulticast.org In-Reply-To: References: <5.1.1.5.2.20030729170159.07399820@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 31 Jul 2003 10:02:08 -0700 At 12:37 PM 7/31/2003 -0400, canetti wrote: >On Tue, 29 Jul 2003, Mark Baugher wrote: > >... > >If there is interest then I can ping the uthors regarding IP/ second >version of >the I-D. That would be great. thanks, Mark >Ran > > > > > >Didn't the authors of SD provide an I-D a little while back? > > > > Yes they did. But they let us know that their company had IPR on it and > > they would give us an IPR statement in the second revision of the > I-D. But > > they never did a second revision. > > > > >I am really largely ignorant of the I-D process, but I thought that the > > >"thoughts" presented through the IETF are not encumbered. > > > > I should take a look at the latest word on this but someone can surely > > present to the IETF any invention, system or apparatus for which they have > > previously filed a patent without invalidating the patent in any way. > > > > Mark > > > > > > >--- Andrea > > > > > > > > > > > >_______________________________________________ > > >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 Jul 31 14:05:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06524 for ; Thu, 31 Jul 2003 14:05:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id A7FA053670; Thu, 31 Jul 2003 14:04: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 0D45153814 for ; Thu, 31 Jul 2003 14:02:21 -0400 (EDT) Received: (qmail 85984 invoked by uid 3269); 31 Jul 2003 18:02:21 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 85981 invoked from network); 31 Jul 2003 18:02:21 -0000 Received: from cs.gmu.edu (129.174.87.2) by klesh.pair.com with SMTP; 31 Jul 2003 18:02:21 -0000 Received: from tigger (tigger [129.174.87.170]) by cs.gmu.edu (8.12.8+Sun/8.12.2) with ESMTP id h6VI2KKa023809 for ; Thu, 31 Jul 2003 14:02:20 -0400 (EDT) From: "Sanjeev Setia" To: Message-ID: <001601c3578d$e2efd6c0$aa57ae81@tigger> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [MSEC] reliability and secure multicast Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 31 Jul 2003 14:02:20 -0400 Content-Transfer-Encoding: 7bit Hi, My colleagues and I have done some research on customized reliable multicast protocols for secure rekey payload transport and thought I'd contribute our $0.02 to the discussion on this topic. Just a few observations: 1) Customized reliable rekey transport protocols are much more lightweight than generic reliable transport protcols (SRM, RMTP, etc). So if performance (key server bandwidth and key delivery latency) is important then a case can be made for including the custom reliable multicast protocol into the group key management protocol. Of course, this complicates the engineering of the key management protocol so there is a tradeoff involved. But at this stage I believe that the principles (if not the implementation-level issues) of customized reliable rekey transport protocols are reasonably well-explored. 2) Performance and scalability (of the reliable rekey transport) only become an issue if the rekey payload is relatively large (because rekeying is done in a batched fashion and/or the group membership is large and dynamic), and if the network has some level of packet loss. For example, if the packet loss rate is 10^-3 as described in a previous post to this mailing list on this topic last month, then reliable rekey transport is not a major issue and very simple protocols will more than suffice. 3) For a performance comparison of various rekey transport protocols for LKH, see our paper "A Comparative Performance Analysis of Reliable Group Rekey Transport Protocols for Secure Multicast", that appeared in the journal Performance Evaluation, (special issue on Proceedings of Performance 2002, Rome, Italy, Sept 2000) at the URL: http://www.ise.gmu.edu/techrep/2002/02_05.pdf 4) Regarding reliability and the subset difference algorithm, we recently wrote a paper on "Adding Reliable and Self-Healing Key Delivery to the Subset Difference Rekeying Method for Secure Multicast". It will be presented at the Networked Group Communication (NGC 2003) conference in Munich later this year. A preliminary version is available at http://www.cs.gmu.edu/~setia/ngc03.ps Sanjeev Setia _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Jul 31 14:06:34 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06556 for ; Thu, 31 Jul 2003 14:06:34 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id CA73353670; Thu, 31 Jul 2003 14:06: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 B2917535AE for ; Thu, 31 Jul 2003 14:04:57 -0400 (EDT) Received: (qmail 86457 invoked by uid 3269); 31 Jul 2003 18:04:57 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86454 invoked from network); 31 Jul 2003 18:04:57 -0000 Received: from mercury.nac.net (64.21.52.92) by klesh.pair.com with SMTP; 31 Jul 2003 18:04:57 -0000 Received: (qmail 19929 invoked from network); 31 Jul 2003 18:04:54 -0000 Received: from unknown (HELO nsx.garage) (209.123.180.191) by mail.nac.net with SMTP; 31 Jul 2003 18:04:54 -0000 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id h6VFwUe20651; Thu, 31 Jul 2003 11:58:30 -0400 From: George Gross To: Mark Baugher Cc: canetti , Andrea Colegrove , Subject: Re: [MSEC] Next gkmarch I-D In-Reply-To: <5.1.1.5.2.20030731100154.05e8c318@mira-sjc5-6.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: Thu, 31 Jul 2003 11:58:30 -0400 (EDT) Hi, comments inline... br, George On Thu, 31 Jul 2003, Mark Baugher wrote: > At 12:37 PM 7/31/2003 -0400, canetti wrote: > > > >On Tue, 29 Jul 2003, Mark Baugher wrote: > > > >... > > > >If there is interest then I can ping the uthors regarding IP/ second > >version of > >the I-D. > > That would be great. > > thanks, Mark > > > >Ran > > > > > > > > >Didn't the authors of SD provide an I-D a little while back? > > > > > > Yes they did. But they let us know that their company had IPR on it and > > > they would give us an IPR statement in the second revision of the > > I-D. But > > > they never did a second revision. > > > > > > >I am really largely ignorant of the I-D process, but I thought that the > > > >"thoughts" presented through the IETF are not encumbered. > > > > > > I should take a look at the latest word on this but someone can surely > > > present to the IETF any invention, system or apparatus for which they have > > > previously filed a patent without invalidating the patent in any way. These days, no Internet Draft gets published unless it contains the RFC2026 boilerplate pledging compliance to IETF IPR policy. The IPR working group has been refining that policy, and has several drafts out. I would anticipate that several of them will publish as informational RFC this year and will become part of the IETF process too. So a new SDR draft will have to match those IPR guidelines. Wrt/ to Subset Difference Rekeying (SDR) and reliability, I think it is germane to mention a paper I encountered recently: "Adding Reliable and Self-Healing Key Distribution to the Subset Difference Group Re-keying Method for Secure Multicast" by S. Zhu, S. Setia, and S. Jajodia The paper underscores that although SDR is "stateless", it still needs reliable multicast transport. In other words, the stateless property as defined here means that if a group member does get the rekey multicast packet, he/she has all the info needed to acquire the new group key without dependency on state info received in other rekey packets. But members that don't get the rekey packet are out of luck until the next rekey message is sent, unless there is a recovery mechanism. The paper goes on to explain how adding FEC and Batched Key Re-transmission (BKR) to SDR could address the reliablity problem. I largely concur with Mark's outline, in that having the GKM-arch specify the base error recovery is a minimum starting point. However, I would also require that the group policy token have the hooks (i.e. reserved TLV) for describing the group's mandatory RMT protocol and its operating parameters. This finesses the "there are many deployment scenarios..." issues by specifying the extensibility that must be built into the GKM protocol and its policy token. To get this capability, at first sight it seems we need: an RMT protocol identifier space as an IANA consideration for the GKM-arch or else the group policy token spec. thoughts? > > > > > > Mark > > > > > > > > > >--- Andrea > > > > > > > > > > > > > > > >_______________________________________________ > > > >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 Thu Jul 31 15:51:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11821 for ; Thu, 31 Jul 2003 15:51:09 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id B600053646; Thu, 31 Jul 2003 15:50: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 5AD19535DA for ; Thu, 31 Jul 2003 15:48:59 -0400 (EDT) Received: (qmail 6027 invoked by uid 3269); 31 Jul 2003 19:48:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 6022 invoked from network); 31 Jul 2003 19:48:58 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 31 Jul 2003 19:48:58 -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 h6VJkeV63924; Thu, 31 Jul 2003 15:46:40 -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 h6VJmOa48732; Thu, 31 Jul 2003 15:48:24 -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 PAA35196; Thu, 31 Jul 2003 15:48:23 -0400 From: canetti To: George Gross Cc: Mark Baugher , Andrea Colegrove , msec@securemulticast.org Subject: Re: [MSEC] Next gkmarch I-D 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: Thu, 31 Jul 2003 15:48:23 -0400 (EDT) see inline: On Thu, 31 Jul 2003, George Gross wrote: > > These days, no Internet Draft gets published unless it contains the > RFC2026 boilerplate pledging compliance to IETF IPR policy. The IPR > working group has been refining that policy, and has several drafts out. I > would anticipate that several of them will publish as informational RFC > this year and will become part of the IETF process too. > > So a new SDR draft will have to match those IPR guidelines. Ofcourse. There aer still several options there and we should ask them to clarify which one they take. > > Wrt/ to Subset Difference Rekeying (SDR) and reliability, I think it is > germane to mention a paper I encountered recently: > > "Adding Reliable and Self-Healing Key Distribution to the Subset > Difference Group Re-keying Method for Secure Multicast" > > by S. Zhu, S. Setia, and S. Jajodia > > The paper underscores that although SDR is "stateless", it still needs > reliable multicast transport. In other words, the stateless property as > defined here means that if a group member does get the rekey multicast > packet, he/she has all the info needed to acquire the new group key > without dependency on state info received in other rekey packets. But > members that don't get the rekey packet are out of luck until the next > rekey message is sent, unless there is a recovery mechanism. > > The paper goes on to explain how adding FEC and Batched Key > Re-transmission (BKR) to SDR could address the reliablity problem. Thanks for pointing out (and thanks also to Sanjeev for the introduction). It's ofcourse right that even in SDR a group member cannot rekey unless it gets *Some* rekey message. The point was that if one gets lost then the next one suffices. This is very different from schemes (such as FLAMES) where there are no rekey messages and the rekeying is done completely off-line. > > I largely concur with Mark's outline, in that having the GKM-arch specify > the base error recovery is a minimum starting point. However, I would also > require that the group policy token have the hooks (i.e. reserved TLV) for > describing the group's mandatory RMT protocol and its operating > parameters. This finesses the "there are many deployment scenarios..." > issues by specifying the extensibility that must be built into the GKM > protocol and its policy token. I concur. > > To get this capability, at first sight it seems we need: an RMT protocol > identifier space as an IANA consideration for the GKM-arch or else the > group policy token spec. thoughts? Since the GKMARCH document is not standards-track then the policy token document seems like a better place. Ran BTW, another "last recourse" solution for the reliability of rekey messages is to have the GCKS post the current rekey message at some public place (say, a web-site). This way, when all else fails, but before re-registering, a member can try to download the current rekey message from that location. (The posting can ofcourse be replicated for scalability using standard techniques). > > > > > > > > > > Mark > > > > > > > > > > > > >--- Andrea > > > > > > > > > > > > > > > > > > > >_______________________________________________ > > > > >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 Thu Jul 31 16:38:30 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13132 for ; Thu, 31 Jul 2003 16:38:30 -0400 (EDT) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D8215536C3; Thu, 31 Jul 2003 16:38: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 E5AB6536C7 for ; Thu, 31 Jul 2003 16:36:13 -0400 (EDT) Received: (qmail 14581 invoked by uid 3269); 31 Jul 2003 20:36:14 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 14578 invoked from network); 31 Jul 2003 20:36:13 -0000 Received: from sj-core-4.cisco.com (171.68.223.138) by klesh.pair.com with SMTP; 31 Jul 2003 20:36:13 -0000 Received: from cscoamera13263.cisco.com (sjc-vpn4-637.cisco.com [10.21.82.125]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h6VKa5pq026049; Thu, 31 Jul 2003 13:36:06 -0700 (PDT) Message-Id: <5.1.1.5.2.20030730130052.074eb9c8@mira-sjc5-6.cisco.com> X-Sender: mbaugher@mira-sjc5-6.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] Next gkmarch I-D Cc: msec@securemulticast.org In-Reply-To: <3F26E017.3060001@nortelnetworks.com> References: <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> <5.1.1.5.2.20030729134003.074c8e78@mira-sjc5-6.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Thu, 31 Jul 2003 13:36:03 -0700 Lakshminath, At 04:59 PM 7/29/2003 -0400, Lakshminath Dondeti wrote: >Mark and I went back and forth on this topic and decided that we should >take the discussion to the list. So, here is my response. > >+++++++++++ >I have additional thoughts that I was discussing with Thomas, along the >following lines. > >Some of the reliable rekey transport protocols use FEC (which is one of >the RMT experimental track protocols) with NACKs for feedback. There are >two ways (perhaps more) for members to provide feedback to the GCKS. One >is to have a secure feedback channel between the members and the >GCKS. The other is to have members that go out of sync to re-register >with the GCKS to download the latest SAs, but in doing so allow a feedback >message be part of the re-registration request. This will allow the GCKS >to change the FEC encoding parameters. In most cases, applying FEC to the re-key will be indistinguishable from simply resending the re-key message some number of times (re-key messages will often be less than the MTU of the path). I believe there are applications that might benefit from something more complex, such as applications that send LKH or OFT trees. The approach that I propose is to have a reliable multicast service provide this function rather than incorporate it into the group key management system. With this approach, the GCKS does not concern itself with FEC encoding, NACKS, etc. >And yes, these thoughts and discussion should be part of the GKMarch I-D. Hugh agreed with my outline. I think Andrea did once I clarified a couple of things. Are you okay with it? >A general question is whether RM protocols need any special signaling that >need to be part of the MSEC protocols. Feedback (some form of member to >GCKS communication) protection comes to mind. If group key management is to provide keys for an RMT security protocol, then the keys and policies need to be defined for that data-security protocol in the registration protocol. GDOI does this through the SA-TEK payload. If group key management is going to use a secure RM protocol, then there will need to be signaling. How this is done will be specified by the RMT. Unless we plan to incorporate an RMP into group key management, I don't think we have to worry about the signaling yet. ciao, Mark >cheers, >Lakshminath > >++++++++++ > >Mark Baugher wrote: > >>Hi, >> I have posted two notes to msec about reliable delivery of re-key >> messages. We want to discuss the role of reliable multicast in the MSEC >> Group Key Management I-D. In outline form, here is what I think we >> should say in the I-D. >> >>1. The Re-key message may be sent multicast and may be sent using >>reliable multicast. >> >>2. There are multiple types of reliable multicast protocols and products >>that have different properties. >> >>3. There are no reliable multicast protocols that are standards - yet. >> >>4. The RECOMMENDED design is to NOT incorporate a special-purpose >>reliable multicast protocol for the Re-key message but to use existing >>products and future standards for reliable multicast service when such a >>service is needed for the Re-key message. >> >>5. The minimal operational capability of an MSEC group key management >>protocol is to support sequencing of the Re-key messages through a >>sequence number, which is authenticated along with the Re-key message. A >>sender of Re-key messages may re-transmit multiple copies of the message >>provided that they have the same sequence number and this repetition is a >>rudimentary means of overcoming loss along the network path. A member >>who receives the Re-key message will check the sequence number to detect >>duplicate and missing Re-key messages. The member receiver will discard >>duplicate messages that it receives. >> >>6. The group member might be out of synchrony with the GCKS if it >>receives a Re-key message having a sequence number that is more than one >>greater than the last sequence number processed. This is one means by >>which the GCKS member detects that it has missed a Re-key message. A >>second means occurs when the application that uses the key notifies its >>group key provider, which is the GCKS member. What action the GCKS >>member takes is a matter of group policy: The GCKS member SHOULD log the >>condition and MAY contact the GCKS to re-run the re-registration protocol >>to obtain a fresh group key. The group policy needs to take into account >>boundary conditions, such as re-ordered Re-key messages where rekeying is >>so frequent that two messages can get reordered in an IP network. The >>group key policy also needs to take into account the potential for denial >>of service attacks where an attacker delays or deletes a Re-key message >>in order to force a subnetwork or subset of the members to synchronously >>contact the GCKS. >> >>I think we can write a short section based on this outline. >> >>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 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec