From msec-admin@securemulticast.org Sun Mar 2 23:08:48 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25823 for ; Sun, 2 Mar 2003 23:08:47 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id BEBCD535DE; Sun, 2 Mar 2003 23:10:11 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5E3DB5353E for ; Sun, 2 Mar 2003 23:08:53 -0500 (EST) Received: (qmail 37817 invoked by uid 3269); 3 Mar 2003 04:08:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 37814 invoked from network); 3 Mar 2003 04:08:52 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 3 Mar 2003 04:08:52 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id h2348XZ05993; Sun, 2 Mar 2003 23:08:33 -0500 (EST) 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 F1NNAH4R; Sun, 2 Mar 2003 23:08:33 -0500 Received: from nortelnetworks.com (artpt5pp.us.nortel.com [47.140.52.107]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSJVXZYX; Sun, 2 Mar 2003 23:08:32 -0500 Message-ID: <3E62D5B4.10302@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/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrea Colegrove Cc: msec@securemulticast.org References: <3E272FF9.7C098DE1@columbia.sparta.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: GKM Architecture Comments Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sun, 02 Mar 2003 23:10:28 -0500 Content-Transfer-Encoding: 7bit Andrea, We discussed your suggestions and made changes along these lines in the revised version of the I-D. We will be making changes to Sec 6.1 and will include a section comparing GSAKMP, GDOI and MIKEY in a later revision. We can discuss any other outstanding ones in the mailing list or at the meeting. Thanks for your patience. best regards, Lakshminath Andrea Colegrove wrote: > Lakshminath, > Here are the changes to the msec architecture document that I > promised we would send for inclusion in the next draft. Comments and > discussion are welcome. > > Section 2, #3: Key material are delivered securely to members of the > group so that they are secret, authenticated to group members, and > verified as coming from an authorized source. > > Section 2, #4: delete, redundant with #3 > > Section 2, #5: This is not a general requirement, but rather could come > from local group policy. For example, some systems may wish to grant > archival access. Suggest deletion of requirement. > > Section 2, #7: Suggest breaking up this requirement into key management > performance and key management interoperability with applications. > > Section 2, Requirements list addition. "Groups must be capable of > securely recovering from compromise of keys." > > Paragraph after Section 2, #8: The example given is rather tangential. > Suggest removing text after initial statement that group key management > protocols are useful for non-multicast groups. > > Second paragraph after Section 2, #8: "... But for large, single-source > ..." This statement is incorrect. Scalability studies show otherwise. > Please delete from this sentence on to the end of the paragraph. > > Section 3.1, first paragraph: "The main goal of a group key management > protocol is to SECURELY provide the group members with an up-to-date and > TRUSTWORTHY security association (SA), which contains ..." Suggested > additions are in caps -- I am not yelling ;-) > > Section 3.1, (2), last sentence: Change "the GCKS" to "a GCKS" > > Section 3.1, (2), paragraph after second bullet: "The Re-key protocol > ensures that all members receive the re-key information is a timely > manner." Since timely is relative, and since failure to receive is > recoverable with a re-join, suggest removing this statement as it is > vague and inaccurate. > > Section 3.2, first paragraph: TEK, this term implies encryption. How > about DPK = Data Protection Key? > > Section 3.3, Distributed operation sentences dangling at end Suggest > adding "and (4) allowing distributed operation of the GCKS, when ..." > > Section 3.4, Figure 2: SAD and SPD are too IPsec-specific. Control > function isn't really discussed elsewhere and is largely integral to the > GKM, telephony is outside the scope of the WG, etc. Suggest removing > Section 3.4. > > Section 4.0, second paragraph -- GSAKMP is no longer using a > secure-channel protocol. Suggest removing remainder of paragraph after > the first sentence. Add table showing differences in features of GDOI, > GSAKMP, and MIKEY. Not tradeoff analysis, but just introduction to > features. > > General comment -- more telephony discussion. Suggest removing all > references to telephony throughout document. > > Section 4.1, Registration Protocol Message Exchange: Mikey uses > tunnelling, but GDOI reuses design. This is not the same approach. > GSAKMP also reuses design. This section needs reworking to truly > differentiate all approaches. > > Section 5.4: Define implosion -- denial of service against self? > > Section 6.1: First paragraph, Second sentence. "It CAN be distributed > through announcement, other external means, or in-band with the > registration and rekey protocols." > > Section 6.1: First paragraph, Last sentence. Not sure that this makes > sense. > > Section 6.1: Second paragraph: These only true for GDOI and MIKEY, but > are not true as general architectural constructs. GSAKMP provides both > through announcement and through in-band means. Does this discussion > belong in this document? > > Section 6.1, Third Paragraph: "This memo assumes ..." Huh? These are > features of MIKEY and GDOI, but not of the generic architecture. GSAKMP > provides these. > > Section 7: Other areas of the document consider topologies other than > one to many large scale. Shouldn't this section as well? > > Section 8, fifth paragraph, last sentence: A great deal has been > published on group security. > > > --- Andrea and Hugh > > > > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 3 14:08:04 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08077 for ; Mon, 3 Mar 2003 14:08:04 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 208EC535FB; Mon, 3 Mar 2003 14:09:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id D51F453557 for ; Mon, 3 Mar 2003 14:07:45 -0500 (EST) Received: (qmail 84645 invoked by uid 3269); 3 Mar 2003 19:07:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 84642 invoked from network); 3 Mar 2003 19:07:45 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 3 Mar 2003 19:07:45 -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 h23J8E1R007103; Mon, 3 Mar 2003 13:08:15 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h23JAnEx026367; Mon, 3 Mar 2003 13:10:50 -0600 Received: from columbia.sparta.com (everest.columbia.sparta.com [157.185.80.33]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA07396; Mon, 3 Mar 2003 14:07:25 -0500 (EST) Message-ID: <3E63A7E2.A1423EBD@columbia.sparta.com> From: Andrea Colegrove X-Mailer: Mozilla 4.75 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lakshminath Dondeti Cc: msec@securemulticast.org References: <3E272FF9.7C098DE1@columbia.sparta.com> <3E62D5B4.10302@nortelnetworks.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: GKM Architecture Comments Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 03 Mar 2003 14:07:14 -0500 Content-Transfer-Encoding: 7bit Thank you much. I look forward to reading the update. --- Andrea Lakshminath Dondeti wrote: > Andrea, > > We discussed your suggestions and made changes along these lines in the > revised version of the I-D. We will be making changes to Sec 6.1 and > will include a section comparing GSAKMP, GDOI and MIKEY in a later revision. > > We can discuss any other outstanding ones in the mailing list or at the > meeting. Thanks for your patience. > > best regards, > Lakshminath > > Andrea Colegrove wrote: > > Lakshminath, > > Here are the changes to the msec architecture document that I > > promised we would send for inclusion in the next draft. Comments and > > discussion are welcome. > > > > Section 2, #3: Key material are delivered securely to members of the > > group so that they are secret, authenticated to group members, and > > verified as coming from an authorized source. > > > > Section 2, #4: delete, redundant with #3 > > > > Section 2, #5: This is not a general requirement, but rather could come > > from local group policy. For example, some systems may wish to grant > > archival access. Suggest deletion of requirement. > > > > Section 2, #7: Suggest breaking up this requirement into key management > > performance and key management interoperability with applications. > > > > Section 2, Requirements list addition. "Groups must be capable of > > securely recovering from compromise of keys." > > > > Paragraph after Section 2, #8: The example given is rather tangential. > > Suggest removing text after initial statement that group key management > > protocols are useful for non-multicast groups. > > > > Second paragraph after Section 2, #8: "... But for large, single-source > > ..." This statement is incorrect. Scalability studies show otherwise. > > Please delete from this sentence on to the end of the paragraph. > > > > Section 3.1, first paragraph: "The main goal of a group key management > > protocol is to SECURELY provide the group members with an up-to-date and > > TRUSTWORTHY security association (SA), which contains ..." Suggested > > additions are in caps -- I am not yelling ;-) > > > > Section 3.1, (2), last sentence: Change "the GCKS" to "a GCKS" > > > > Section 3.1, (2), paragraph after second bullet: "The Re-key protocol > > ensures that all members receive the re-key information is a timely > > manner." Since timely is relative, and since failure to receive is > > recoverable with a re-join, suggest removing this statement as it is > > vague and inaccurate. > > > > Section 3.2, first paragraph: TEK, this term implies encryption. How > > about DPK = Data Protection Key? > > > > Section 3.3, Distributed operation sentences dangling at end Suggest > > adding "and (4) allowing distributed operation of the GCKS, when ..." > > > > Section 3.4, Figure 2: SAD and SPD are too IPsec-specific. Control > > function isn't really discussed elsewhere and is largely integral to the > > GKM, telephony is outside the scope of the WG, etc. Suggest removing > > Section 3.4. > > > > Section 4.0, second paragraph -- GSAKMP is no longer using a > > secure-channel protocol. Suggest removing remainder of paragraph after > > the first sentence. Add table showing differences in features of GDOI, > > GSAKMP, and MIKEY. Not tradeoff analysis, but just introduction to > > features. > > > > General comment -- more telephony discussion. Suggest removing all > > references to telephony throughout document. > > > > Section 4.1, Registration Protocol Message Exchange: Mikey uses > > tunnelling, but GDOI reuses design. This is not the same approach. > > GSAKMP also reuses design. This section needs reworking to truly > > differentiate all approaches. > > > > Section 5.4: Define implosion -- denial of service against self? > > > > Section 6.1: First paragraph, Second sentence. "It CAN be distributed > > through announcement, other external means, or in-band with the > > registration and rekey protocols." > > > > Section 6.1: First paragraph, Last sentence. Not sure that this makes > > sense. > > > > Section 6.1: Second paragraph: These only true for GDOI and MIKEY, but > > are not true as general architectural constructs. GSAKMP provides both > > through announcement and through in-band means. Does this discussion > > belong in this document? > > > > Section 6.1, Third Paragraph: "This memo assumes ..." Huh? These are > > features of MIKEY and GDOI, but not of the generic architecture. GSAKMP > > provides these. > > > > Section 7: Other areas of the document consider topologies other than > > one to many large scale. Shouldn't this section as well? > > > > Section 8, fifth paragraph, last sentence: A great deal has been > > published on group security. > > > > > > --- Andrea and Hugh > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 7 06:57:21 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22174 for ; Fri, 7 Mar 2003 06:57:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 5685A535DB; Fri, 7 Mar 2003 06:58:03 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 852D2535DB for ; Fri, 7 Mar 2003 06:56:04 -0500 (EST) Received: (qmail 55984 invoked by uid 3269); 7 Mar 2003 11:56:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 55981 invoked from network); 7 Mar 2003 11:56:02 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 7 Mar 2003 11:56:02 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21404; Fri, 7 Mar 2003 06:53:56 -0500 (EST) Message-Id: <200303071153.GAA21404@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-04.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 07 Mar 2003 06:53:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : Group Key Management Architecture Author(s) : L. Dondeti et al. Filename : draft-ietf-msec-gkmarch-04.txt Pages : 32 Date : 2003-3-6 This document presents a 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 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-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-gkmarch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-gkmarch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-6125335.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-gkmarch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-gkmarch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-6125335.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 10 12:47:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05328 for ; Mon, 10 Mar 2003 12:47:29 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 976E3536D4; Mon, 10 Mar 2003 12:48:12 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 0342253574 for ; Mon, 10 Mar 2003 12:47:32 -0500 (EST) Received: (qmail 4050 invoked by uid 3269); 10 Mar 2003 17:47:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 4045 invoked from network); 10 Mar 2003 17:47:31 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 10 Mar 2003 17:47:31 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18sRMc-0006OU-00; Mon, 10 Mar 2003 17:47:02 +0000 Message-ID: <3E6CCF94.4F76B610@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Peter Lough , msec@securemulticast.org Cc: "Kenny, Gavin (Space)" References: <00e101c2b299$32ff0770$7750b99d@SNOWBALL> Content-Type: multipart/alternative; boundary="------------4A135D11735812EB9200BC22" X-Spam-Status: No, hits=-102.0 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,USER_AGENT_MOZILLA_XM, USER_IN_WHITELIST,X_ACCEPT_LANG version=2.44 X-Scanner: exiscan *18sRMc-0006OU-00*A7.cw24n8Mo* (SECM, UniS) Subject: [MSEC] Re: GSAKMP Protocol comments Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 10 Mar 2003 17:47:01 +0000 --------------4A135D11735812EB9200BC22 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Peter, Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks. Our thought at University of Surrey and Logica are as follows: We should separate authentication from authorisation issues between the server and clients. Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks. However the GSAMKP Server might be connected to an AAA Server to check of that the "well known user" is authorised to join the group. Here is our idea and it is open for discussions: Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills). In this way, we minimize the DoS attack possibilities. Of course if the RTJ authentication fails, the GSAKMP server does NOTHING. The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system. Regards Haitham Peter Lough wrote: > Gavin, There is currently work underway here at SPARTA to finalize the > current revision of the GSAKMP document. As I understand, there has > been some comments, from you and others working with you at Logica and > University of Surrey, regarding the inclusion of cookies as an > anti-clogging mechanism as well as the inclusion of additional failure > notification during the group creation phase of the GSAKMP > exchange. We would like to be responsive to these issues in the > current revision and would like you to refresh us on you concerns with > these or any other issues that have arisen. We think the majority of > these discussions will be material to the MSEC community at large and > to that end would like to handle them via those channels. If you > would like to format a response to this and simply send it to MSEC as > well, that might be most useful. We will angle our discussions > through the community as well. Of course we can have any necessary > sidebar discussion. Thanks, Peter LoughSPARTA, Inc. -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ --------------4A135D11735812EB9200BC22 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Peter,

Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks.  Our thought at University of Surrey and Logica are as follows:

We should separate authentication from authorisation issues between the server and clients.  Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks.  However the GSAMKP Server might be connected to an AAA Server to check of  that the "well known user" is authorised to join the group.

Here is our idea and it is open for discussions:  Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills).  In this way, we minimize the DoS attack possibilities.  Of course if the RTJ authentication fails, the GSAKMP server does NOTHING.

The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system.

Regards
Haitham

Peter Lough wrote:

Gavin, There is currently work underway here at SPARTA to finalize the current revision of the GSAKMP document.  As I understand, there has been some comments, from you and others working with you at Logica and University of Surrey, regarding the inclusion of cookies as an anti-clogging mechanism as well as the inclusion of additional failure notification during the group creation phase of the GSAKMP exchange. We would like to be responsive to these issues in the current revision and would like you to refresh us on you concerns with these or any other issues that have arisen.  We think the majority of these discussions will be material to the MSEC community at large and to that end would like to handle them via those channels.  If you would like to format a response to this and simply send it to MSEC as well, that might be most useful.  We will angle our discussions through the community as well.  Of course we can have any necessary sidebar discussion. Thanks, Peter LoughSPARTA, Inc.

--
Dr. Haitham S. Cruickshank

Senior Research Fellow in Communications
Centre for Communication Systems Research (CCSR)
School of Electronics, Computing and Mathematics
University of Surrey
Guildford, Surrey GU2 7XH, UK

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
  --------------4A135D11735812EB9200BC22-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 11:02:01 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24873 for ; Tue, 11 Mar 2003 11:02:01 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6741253731; Tue, 11 Mar 2003 11:02:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1A01E5354E for ; Tue, 11 Mar 2003 11:01:44 -0500 (EST) Received: (qmail 25549 invoked by uid 3269); 11 Mar 2003 16:01:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25546 invoked from network); 11 Mar 2003 16:01:43 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 11 Mar 2003 16:01: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 h2BG3LkD001278; Tue, 11 Mar 2003 10:03:21 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h2BG1ZV4025631; Tue, 11 Mar 2003 10:01:40 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id LAA20481; Tue, 11 Mar 2003 11:01:19 -0500 (EST) Subject: Re: [MSEC] Re: GSAKMP Protocol comments Content-Type: multipart/alternative; boundary=Apple-Mail-2-371801904 Mime-Version: 1.0 (Apple Message framework v551) Cc: Peter Lough , msec@securemulticast.org, "Kenny, Gavin (Space)" To: Haitham Cruickshank From: Hugh Harney In-Reply-To: <3E6CCF94.4F76B610@eim.surrey.ac.uk> Message-Id: X-Mailer: Apple Mail (2.551) 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, 11 Mar 2003 11:01:18 -0500 --Apple-Mail-2-371801904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Haitham, I see your point in desiring a separation between authentication and=20 authorization. It may be useful to send a management message to a user=20= that has passed all the security relevant steps in the GSAKMP RTJ=20 processing, but has not passed a purely administrative step. Your idea of sending an Optional failure notification is interesting.=20 Perhaps we may want to expand this idea to a set of generic management=20= messages. We could use a management message for failure to pay bills,=20 requests for de-registration, audit, or expanded error notifications. Do you have a concept in mind for the structure of these messages? Hugh On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank wrote: > Hi Peter, > > Further to your email below, we would like to discuss the issue of=20 > Failure Notification between GSAKMP Servers and clients and its=20 > relation to DoS attacks.=A0 Our thought at University of Surrey and=20 > Logica are as follows: > > We should separate authentication from authorization issues between=20 > the server and clients.=A0 Authentication procedures with the GSAKMP=20= > client sending Request To Join (RTJ) to the GSAKMP Server is just=20 > authenticating the RTJ message and can be open to DoS attacks.=A0=20 > However the GSAMKP Server might be connected to an AAA Server to check=20= > of=A0 that the "well known user" is authorised to join the group. > > Here is our idea and it is open for discussions:=A0 Is it possible to=20= > have an OPTIONAL Failure Notification messages that sent by the GSAKMP=20= > server only if the user is "well known" but the authorisation=20 > procedure has failed (e.g. the user did not pay his bills).=A0 In this=20= > way, we minimize the DoS attack possibilities.=A0 Of course if the RTJ=20= > authentication fails, the GSAKMP server does NOTHING. > > The alternative is to have a seperate unicast channel for the failure=20= > notifications, outside the GSAKMP system. > > Regards > Haitham > > Peter Lough wrote: > > Gavin,=A0There is currently work underway here at SPARTA to finalize=20= > the current revision of the GSAKMP document.=A0 As I understand, there=20= > has been some comments, from you and others working with you at Logica=20= > and University of Surrey, regarding the inclusion of cookies as an=20 > anti-clogging mechanism as well as the inclusion of additional failure=20= > notification during the group creation phase of the GSAKMP=20 > exchange.=A0We would like to be responsive to these issues in the=20 > current revision and would like you to refresh us on you concerns with=20= > these or any other issues that have arisen.=A0 We think the majority = of=20 > these discussions will be material to the MSEC community at large and=20= > to that end would like to handle them via those channels.=A0 If you=20 > would like to format a response to this and simply send it to MSEC as=20= > well, that might be most useful.=A0 We will angle our discussions=20 > through the community as well.=A0 Of course we can have any necessary=20= > sidebar discussion.=A0Thanks,=A0Peter LoughSPARTA, Inc. > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > =A0 > > Hugh Harney Sparta, = Inc. hh@sparta.com 7075 Samuel = Morse Drive (410) 872-1515 x203 Columbia, MD, = 21046 --Apple-Mail-2-371801904 Content-Type: text/enriched; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Haitham, I see your point in desiring a separation between authentication and authorization. It may be useful to send a management message to a user that has passed all the security relevant steps in the GSAKMP RTJ processing, but has not passed a purely administrative step. Your idea of sending an Optional failure notification is interesting. Perhaps we may want to expand this idea to a set of generic management messages. We could use a management message for failure to pay bills, requests for de-registration, audit, or expanded error notifications. Do you have a concept in mind for the structure of these messages? Hugh On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank wrote: Hi Peter, Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks.=A0 Our thought at University of Surrey and Logica are as follows: We should separate authentication from authorization issues between the server and clients.=A0 Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks.=A0 However the GSAMKP Server might be connected to an AAA Server to check of=A0 that the "well known user" is authorised to join the group. Here is our idea and it is open for discussions:=A0 Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills).=A0 In this way, we minimize the DoS attack possibilities.=A0 Of course if the RTJ authentication fails, the GSAKMP server does NOTHING. The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system. Regards Haitham Peter Lough wrote: = ArialGavin,=A0<= fontfamily>ArialThere is currently work underway here at SPARTA to finalize the current revision of the GSAKMP document.=A0 As I understand, there has been some comments, from you and others working with you at Logica and University of Surrey, regarding the inclusion of cookies as an anti-clogging mechanism as well as the inclusion of additional failure notification during the group creation phase of the GSAKMP = exchange.=A0ArialWe would like to be responsive to these issues in the current revision and would like you to refresh us on you concerns with these or any other issues that have arisen.=A0 We think the majority of these discussions will be material to the MSEC community at large and to that end would like to handle them via those channels.=A0 If you would like to format a response to this and simply send it to MSEC as well, that might be most useful.=A0 We will angle our discussions through the community as well.=A0 Of course we can have any necessary sidebar = discussion.=A0ArialThanks,=A0ArialPeter LoughSPARTA, Inc. -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk = 1999,1999,FFFFhttp://www.ee.surrey.ac.uk/= Personal/H.Cruickshank/ =A0 Hugh Harney = Sparta, Inc. hh@sparta.com 7075 Samuel = Morse Drive (410) 872-1515 x203 Columbia, MD, = 21046 --Apple-Mail-2-371801904-- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 11:58:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27503 for ; Tue, 11 Mar 2003 11:58:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 15C5E53825; Tue, 11 Mar 2003 12:00:11 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A3FAE537C0 for ; Tue, 11 Mar 2003 11:59:28 -0500 (EST) Received: (qmail 35578 invoked by uid 3269); 11 Mar 2003 16:59:28 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35575 invoked from network); 11 Mar 2003 16:59:28 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 11 Mar 2003 16:59:28 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18sn5x-00032O-00; Tue, 11 Mar 2003 16:59:17 +0000 Message-ID: <3E6E15E4.B9EB5206@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney Cc: msec@securemulticast.org, Sunil Iyengar , Peter Lough Subject: Re: [MSEC] Re: GSAKMP Protocol comments References: Content-Type: text/plain; charset=iso-8859-1 X-Spam-Status: No, hits=-102.1 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,NOSPAM_INC,QUOTED_EMAIL_TEXT, REFERENCES,SPAM_PHRASE_01_02,SUPERLONG_LINE, USER_AGENT_MOZILLA_XM,USER_IN_WHITELIST,X_ACCEPT_LANG version=2.44 X-Scanner: exiscan *18sn5x-00032O-00*9aeHkfNxODA* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Tue, 11 Mar 2003 16:59:16 +0000 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA27503 Hi Hugh, Hugh Harney wrote: > Haitham, > > I see your point in desiring a separation between authentication and authorization. It may be useful to send a management message to a user that has passed all the security relevant steps in the GSAKMP RTJ processing, but has not passed a purely administrative step. > > Your idea of sending an Optional failure notification is interesting. Perhaps we may want to expand this idea to a set of generic management messages. We could use a management message for failure to pay bills, requests for de-registration, audit, or expanded error notifications. > > Do you have a concept in mind for the structure of these messages? In GSAKMP- Light draft and within the notification payload, there is a field for Notify Message Type and one of the values is: Unauthorised Request = 19 This can be used by the GSAKMP Server as an OPTIONAL Failure Notification. Is that OK. Haitham & Sunny > > > Hugh > > On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank wrote: > > Hi Peter, > > Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks. Our thought at University of Surrey and Logica are as follows: > > We should separate authentication from authorization issues between the server and clients. Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks. However the GSAMKP Server might be connected to an AAA Server to check of that the "well known user" is authorised to join the group. > > Here is our idea and it is open for discussions: Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills). In this way, we minimize the DoS attack possibilities. Of course if the RTJ authentication fails, the GSAKMP server does NOTHING. > > The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system. > > Regards > Haitham > > Peter Lough wrote: > > Gavin, There is currently work underway here at SPARTA to finalize the current revision of the GSAKMP document. As I understand, there has been some comments, from you and others working with you at Logica and University of Surrey, regarding the inclusion of cookies as an anti-clogging mechanism as well as the inclusion of additional failure notification during the group creation phase of the GSAKMP exchange. We would like to be responsive to these issues in the current revision and would like you to refresh us on you concerns with these or any other issues that have arisen. We think the majority of these discussions will be material to the MSEC community at large and to that end would like to handle them via those channels. If you would like to format a response to this and simply send it to MSEC as well, that might be most useful. We will angle our discussions through the community as well. Of course we can have any necessary sidebar discussion. Thanks, Peter > LoughSPARTA, Inc. > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 12:06:39 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28090 for ; Tue, 11 Mar 2003 12:06:39 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 802095377D; Tue, 11 Mar 2003 12:08:12 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 82B55535EF for ; Tue, 11 Mar 2003 12:06:13 -0500 (EST) Received: (qmail 36716 invoked by uid 3269); 11 Mar 2003 17:06:12 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36713 invoked from network); 11 Mar 2003 17:06:12 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 11 Mar 2003 17:06:12 -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 h2BH82kD004295; Tue, 11 Mar 2003 11:08:02 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h2BH6LV4028361; Tue, 11 Mar 2003 11:06:22 -0600 Received: from SNOWBALL (snowball.columbia.sparta.com [157.185.80.119]) by columbia.sparta.com (8.9.1a/8.9.1) with SMTP id MAA21535; Tue, 11 Mar 2003 12:06:05 -0500 (EST) Message-ID: <008201c2e7f1$16314ee0$7750b99d@SNOWBALL> From: "Peter Lough" To: "Haitham Cruickshank" , "Hugh Harney" Cc: , "Sunil Iyengar" References: <3E6E15E4.B9EB5206@eim.surrey.ac.uk> Subject: Re: [MSEC] Re: GSAKMP Protocol comments MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 11 Mar 2003 12:10:15 -0500 Content-Transfer-Encoding: 7bit I think using the existing Notification payload and extending the types so that additional information can be passed is useful. In addition to: Unauthorized Request = 19 the table might be expanded for example to include: Account Delinquent = 129 or Unauthorized Request could be extended to have an application specific value added. However, as this is used for more detailed information, I think the protocol should allow for that information to be encrypted via the DH exchange that is begun in preparation for the key download. There may be cases where you don't want others with access to that data channel to know that a particular account is delinquent or other specific information about the reason for failure. Encrypting it between the two entities would solve that issue. To do this, the protocol could simply allow a message back from the server with a Key Creation Payload and a Notification Payload encrypted in the resultant KEK. Pete ----- Original Message ----- From: "Haitham Cruickshank" To: "Hugh Harney" Cc: ; "Sunil Iyengar" ; "Peter Lough" Sent: Tuesday, March 11, 2003 11:59 AM Subject: Re: [MSEC] Re: GSAKMP Protocol comments > Hi Hugh, > > Hugh Harney wrote: > > > Haitham, > > > > I see your point in desiring a separation between authentication and authorization. It may be useful to send a management message to a user that has passed all the security relevant steps in the GSAKMP RTJ processing, but has not passed a purely administrative step. > > > > Your idea of sending an Optional failure notification is interesting. Perhaps we may want to expand this idea to a set of generic management messages. We could use a management message for failure to pay bills, requests for de-registration, audit, or expanded error notifications. > > > > Do you have a concept in mind for the structure of these messages? > > In GSAKMP- Light draft and within the notification payload, there is a field for Notify Message Type and one of the values is: > > Unauthorised Request = 19 > > This can be used by the GSAKMP Server as an OPTIONAL Failure Notification. > > Is that OK. > > Haitham & Sunny > > > > > > > Hugh > > > > On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank wrote: > > > > Hi Peter, > > > > Further to your email below, we would like to discuss the issue of Failure Notification between GSAKMP Servers and clients and its relation to DoS attacks. Our thought at University of Surrey and Logica are as follows: > > > > We should separate authentication from authorization issues between the server and clients. Authentication procedures with the GSAKMP client sending Request To Join (RTJ) to the GSAKMP Server is just authenticating the RTJ message and can be open to DoS attacks. However the GSAMKP Server might be connected to an AAA Server to check of that the "well known user" is authorised to join the group. > > > > Here is our idea and it is open for discussions: Is it possible to have an OPTIONAL Failure Notification messages that sent by the GSAKMP server only if the user is "well known" but the authorisation procedure has failed (e.g. the user did not pay his bills). In this way, we minimize the DoS attack possibilities. Of course if the RTJ authentication fails, the GSAKMP server does NOTHING. > > > > The alternative is to have a seperate unicast channel for the failure notifications, outside the GSAKMP system. > > > > Regards > > Haitham > > > > Peter Lough wrote: > > > > Gavin, There is currently work underway here at SPARTA to finalize the current revision of the GSAKMP document. As I understand, there has been some comments, from you and others working with you at Logica and University of Surrey, regarding the inclusion of cookies as an anti-clogging mechanism as well as the inclusion of additional failure notification during the group creation phase of the GSAKMP exchange. We would like to be responsive to these issues in the current revision and would like you to refresh us on you concerns with these or any other issues that have arisen. We think the majority of these discussions will be material to the MSEC community at large and to that end would like to handle them via those channels. If you would like to format a response to this and simply send it to MSEC as well, that might be most useful. We will angle our discussions through the community as well. Of course we can have any necessary sidebar discussion. Thanks, Peter > > LoughSPARTA, Inc. > > > > -- > > Dr. Haitham S. Cruickshank > > > > Senior Research Fellow in Communications > > Centre for Communication Systems Research (CCSR) > > School of Electronics, Computing and Mathematics > > University of Surrey > > Guildford, Surrey GU2 7XH, UK > > > > Tel: +44 1483 686007 (indirect 689844) > > Fax: +44 1483 686011 > > e-mail: H.Cruickshank@surrey.ac.uk > > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > > > Hugh Harney Sparta, Inc. > > hh@sparta.com 7075 Samuel Morse Drive > > (410) 872-1515 x203 Columbia, MD, 21046 > > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 14:28:29 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06278 for ; Tue, 11 Mar 2003 14:28:27 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id D978F53685; Tue, 11 Mar 2003 14:30:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2BBA353685 for ; Tue, 11 Mar 2003 14:28:31 -0500 (EST) Received: (qmail 61046 invoked by uid 3269); 11 Mar 2003 19:28:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61042 invoked from network); 11 Mar 2003 19:28:30 -0000 Received: from smtp014.mail.yahoo.com (216.136.173.58) by klesh.pair.com with SMTP; 11 Mar 2003 19:28:30 -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; 11 Mar 2003 19:28:30 -0000 Message-Id: <5.0.0.25.2.20030311142050.02b90d68@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC Agenda for IETF-56 in San Francisco 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, 11 Mar 2003 14:28:15 -0500 Folks, Here is the Agenda as of today for the MSEC WG meeting at IETF56 in San Francisco in March 2003. Please email Ran/Thomas for corrections/additions. MSEC WG Agenda: --------------- - Review of WG status (T. Hardjono/R. Canetti) 15min - TESLA Update (A. Perrig) 15min - Feedback channel protection (L. Dondeti/T. Hardjono) 15min - GKMA (L. Dondeti/B. Weis) 15min - MESP (R.Canetti/M.Baugher) 15min - DHHMAC for MIKEY Update (M. Euchner) 15min - GSAKMP Update (H. Harney) 15min - GSAKMP Policy Token (H. Harney) 15min - AH/ESP multicast issues (B. Weis/M. Baugher) 15min - Discussion 15min Note that according to the IETF56 agenda, MSEC will meet on: MONDAY, March 17, 2003 1930-2200 Evening Sessions Regards Ran/Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 21:24:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23294 for ; Tue, 11 Mar 2003 21:24:23 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2A928537C7; Tue, 11 Mar 2003 21:26:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 1C870535BD for ; Tue, 11 Mar 2003 21:24:34 -0500 (EST) Received: (qmail 25560 invoked by uid 3269); 12 Mar 2003 02:24:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 25554 invoked from network); 12 Mar 2003 02:24:31 -0000 Received: from smtp016.mail.yahoo.com (216.136.174.113) by klesh.pair.com with SMTP; 12 Mar 2003 02:24:31 -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; 12 Mar 2003 02:24:30 -0000 Message-Id: <5.0.0.25.2.20030311211147.029f95b8@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Cc: canetti@watson.ibm.com, ldondeti@nortelnetworks.com, ldondeti@attbi.com, Pete_Dinsmore@nai.com, thardjono@verisign.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC Final Agenda + continue to GSEC timeslot on Tue 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, 11 Mar 2003 21:24:28 -0500 Folks, Here is the Agenda as of today for the MSEC WG meeting at IETF56 in San Francisco in March 2003. The Agenda is very full, and thus timing is tight. In the likely case that MSEC does not finish its presentations on Monday night, the GSEC co-chairs have kindly allowed us to use some of their time on Tuesday afternoon. (Thanks Pete and Lakshminath). Please email Ran/Thomas for corrections/additions. MSEC WG Agenda: --------------- - Review of WG status (T. Hardjono/R. Canetti) 15min - TESLA Update (A. Perrig) 15min - MESP (R.Canetti/M.Baugher) 15min - AH/ESP multicast issues (B. Weis) 15min - Feedback channel protection (L. Dondeti/T. Hardjono) 15min - GKM Algorithms (L. Dondeti/B. Weis) 15min - GSAKMP Update (H. Harney) 15min - GSAKMP Policy Token (H. Harney) 15min - DHHMAC for MIKEY Update (M. Euchner) 15min - SDP Descriptions (M. Baugher) 15min Note that according to the IETF56 agenda, MSEC will meet on: MONDAY, March 17, 2003 1930-2200 Evening Sessions Here is the GSEC schedule: GSEC TUESDAY, March 18, 2003 1415-1515 Afternoon Sessions II 1545-1645 Afternoon Sessions III IRTF gsec Group Security Research Group Regards Ran/Thomas ---------- _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 21:38:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23594 for ; Tue, 11 Mar 2003 21:38:26 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 6EF49537BB; Tue, 11 Mar 2003 21:40:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id EB3B853694 for ; Tue, 11 Mar 2003 21:39:55 -0500 (EST) Received: (qmail 35729 invoked by uid 3269); 12 Mar 2003 02:39:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35726 invoked from network); 12 Mar 2003 02:39:55 -0000 Received: from smtp018.mail.yahoo.com (216.136.174.115) by klesh.pair.com with SMTP; 12 Mar 2003 02:39:55 -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; 12 Mar 2003 02:39:54 -0000 Message-Id: <5.0.0.25.2.20030311213703.04df6850@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Mark Baugher (by way of Thomas Hardjono ) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] draft-ietf-msec-mesp-01.txt now available 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, 11 Mar 2003 21:39:53 -0500 Folks, Draft draft-ietf-msec-mesp-01.txt is now available on the MSEC website. http://www.securemulticast.org/draft-ietf-msec-mesp-01.txt Its also available on http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-01.txt thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 11 21:42:27 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23678 for ; Tue, 11 Mar 2003 21:42:27 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id DC4A253832; Tue, 11 Mar 2003 21:44:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9E72653836 for ; Tue, 11 Mar 2003 21:42:31 -0500 (EST) Received: (qmail 35961 invoked by uid 3269); 12 Mar 2003 02:42:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35958 invoked from network); 12 Mar 2003 02:42:31 -0000 Received: from smtp017.mail.yahoo.com (216.136.174.114) by klesh.pair.com with SMTP; 12 Mar 2003 02:42:31 -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; 12 Mar 2003 02:42:30 -0000 Message-Id: <5.0.0.25.2.20030311213959.04de23b8@pop.mail.yahoo.com> X-Sender: thardjono@pop.mail.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.0 To: msec@securemulticast.org From: Thomas Hardjono Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Late drafts can be put 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, 11 Mar 2003 21:42:29 -0500 If anyone has a (late) draft they need to make available for the next MSEC meeting in San Francisco, please email me and I can put it up on the msec website. cheers, thomas ------ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Wed Mar 12 10:44:25 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08597 for ; Wed, 12 Mar 2003 10:44:24 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7C45D535D6; Wed, 12 Mar 2003 10:46:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id B49FE535CE for ; Wed, 12 Mar 2003 10:44:59 -0500 (EST) Received: (qmail 59921 invoked by uid 3269); 12 Mar 2003 15:44:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59918 invoked from network); 12 Mar 2003 15:44:59 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 12 Mar 2003 15:44:59 -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 h2CFiukD003147; Wed, 12 Mar 2003 09:44:56 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h2CFipV4025056; Wed, 12 Mar 2003 09:44:51 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id KAA08766; Wed, 12 Mar 2003 10:44:47 -0500 (EST) Subject: Re: [MSEC] Re: GSAKMP Protocol comments Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: "Haitham Cruickshank" , , "Sunil Iyengar" To: "Peter Lough" From: Hugh Harney In-Reply-To: <008201c2e7f1$16314ee0$7750b99d@SNOWBALL> Message-Id: <8DF1E0B7-54A1-11D7-B388-000393DAD548@sparta.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) 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, 12 Mar 2003 10:44:47 -0500 Content-Transfer-Encoding: 7bit Pete and Haitham, I agree the notification payload could be used to send some management information back to a member trying to join a group. I think that the payload should be put into a new class of message. This is a management information class of message. The reason I advocate moving this function to another message class is that it doesn't directly impact the creation of the cryptographic group. We need to keep the key exchange protocol simple, easy to evaluate. The management messages are critical but not cryptographically important. So, let's put them in their own message and give us flexibility in how to use those messages. The management information message could be used to notify a joining member of their state, or it could be used to send group management information between group entities - GC to Subordinate GC, GC to GO. These messages could make use of existing pairwise keys to protect the transmission or they could be sent in the clear or they could be sent using a pairwise secure association. I think this management issue is larger than just the notification to the GM from the GC. I'd like to capture this in the spec in a way that would allow future developers flexibility to use the management message structure. Hugh On Tuesday, Mar 11, 2003, at 12:10 US/Eastern, Peter Lough wrote: > I think using the existing Notification payload and extending the > types so > that additional information can be passed is useful. In addition to: > > Unauthorized Request = 19 > > the table might be expanded for example to include: > > Account Delinquent = 129 > > or Unauthorized Request could be extended to have an application > specific > value added. However, as this is used for more detailed information, I > think the protocol should allow for that information to be encrypted > via the > DH exchange that is begun in preparation for the key download. There > may be > cases where you don't want others with access to that data channel to > know > that a particular account is delinquent or other specific information > about > the reason for failure. Encrypting it between the two entities would > solve > that issue. > > To do this, the protocol could simply allow a message back from the > server > with a Key Creation Payload and a Notification Payload encrypted in the > resultant KEK. > > Pete > ----- Original Message ----- > From: "Haitham Cruickshank" > To: "Hugh Harney" > Cc: ; "Sunil Iyengar" > ; "Peter Lough" > Sent: Tuesday, March 11, 2003 11:59 AM > Subject: Re: [MSEC] Re: GSAKMP Protocol comments > > >> Hi Hugh, >> >> Hugh Harney wrote: >> >>> Haitham, >>> >>> I see your point in desiring a separation between authentication and > authorization. It may be useful to send a management message to a user > that > has passed all the security relevant steps in the GSAKMP RTJ > processing, but > has not passed a purely administrative step. >>> >>> Your idea of sending an Optional failure notification is interesting. > Perhaps we may want to expand this idea to a set of generic management > messages. We could use a management message for failure to pay bills, > requests for de-registration, audit, or expanded error notifications. >>> >>> Do you have a concept in mind for the structure of these messages? >> >> In GSAKMP- Light draft and within the notification payload, there is a > field for Notify Message Type and one of the values is: >> >> Unauthorised Request = 19 >> >> This can be used by the GSAKMP Server as an OPTIONAL Failure >> Notification. >> >> Is that OK. >> >> Haitham & Sunny >> >>> >>> >>> Hugh >>> >>> On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank >>> wrote: >>> >>> Hi Peter, >>> >>> Further to your email below, we would like to discuss the issue >>> of > Failure Notification between GSAKMP Servers and clients and its > relation to > DoS attacks. Our thought at University of Surrey and Logica are as > follows: >>> >>> We should separate authentication from authorization issues >>> between > the server and clients. Authentication procedures with the GSAKMP > client > sending Request To Join (RTJ) to the GSAKMP Server is just > authenticating > the RTJ message and can be open to DoS attacks. However the GSAMKP > Server > might be connected to an AAA Server to check of that the "well known > user" > is authorised to join the group. >>> >>> Here is our idea and it is open for discussions: Is it >>> possible to > have an OPTIONAL Failure Notification messages that sent by the GSAKMP > server only if the user is "well known" but the authorisation > procedure has > failed (e.g. the user did not pay his bills). In this way, we > minimize the > DoS attack possibilities. Of course if the RTJ authentication fails, > the > GSAKMP server does NOTHING. >>> >>> The alternative is to have a seperate unicast channel for the > failure notifications, outside the GSAKMP system. >>> >>> Regards >>> Haitham >>> >>> Peter Lough wrote: >>> >>> Gavin, There is currently work underway here at SPARTA to >>> finalize > the current revision of the GSAKMP document. As I understand, there > has > been some comments, from you and others working with you at Logica and > University of Surrey, regarding the inclusion of cookies as an > anti-clogging > mechanism as well as the inclusion of additional failure notification > during > the group creation phase of the GSAKMP exchange. We would like to be > responsive to these issues in the current revision and would like you > to > refresh us on you concerns with these or any other issues that have > arisen. > We think the majority of these discussions will be material to the MSEC > community at large and to that end would like to handle them via those > channels. If you would like to format a response to this and simply > send it > to MSEC as well, that might be most useful. We will angle our > discussions > through the community as well. Of course we can have any necessary > sidebar > discussion. Thanks, Peter >>> LoughSPARTA, Inc. >>> >>> -- >>> Dr. Haitham S. Cruickshank >>> >>> Senior Research Fellow in Communications >>> Centre for Communication Systems Research (CCSR) >>> School of Electronics, Computing and Mathematics >>> University of Surrey >>> Guildford, Surrey GU2 7XH, UK >>> >>> Tel: +44 1483 686007 (indirect 689844) >>> Fax: +44 1483 686011 >>> e-mail: H.Cruickshank@surrey.ac.uk >>> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >>> >>> >>> Hugh Harney Sparta, Inc. >>> hh@sparta.com 7075 Samuel Morse Drive >>> (410) 872-1515 x203 Columbia, MD, 21046 >> >> -- >> Dr. Haitham S. Cruickshank >> >> Senior Research Fellow in Communications >> Centre for Communication Systems Research (CCSR) >> School of Electronics, Computing and Mathematics >> University of Surrey >> Guildford, Surrey GU2 7XH, UK >> >> Tel: +44 1483 686007 (indirect 689844) >> Fax: +44 1483 686011 >> e-mail: H.Cruickshank@surrey.ac.uk >> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ >> >> >> >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec >> > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > 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 Wed Mar 12 10:58:28 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09274 for ; Wed, 12 Mar 2003 10:58:27 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4EDE55370B; Wed, 12 Mar 2003 11:00:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 98DC6535CE for ; Wed, 12 Mar 2003 10:59:16 -0500 (EST) Received: (qmail 62218 invoked by uid 3269); 12 Mar 2003 15:59:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 62215 invoked from network); 12 Mar 2003 15:59:16 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 12 Mar 2003 15:59:16 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18t8cz-0005wD-00; Wed, 12 Mar 2003 15:58:49 +0000 Message-ID: <3E6F5937.34C40429@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney Cc: Peter Lough , msec@securemulticast.org, Sunil Iyengar Subject: Re: [MSEC] Re: GSAKMP Protocol comments References: <8DF1E0B7-54A1-11D7-B388-000393DAD548@sparta.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-116.2 required=5.5 tests=AWL,EMAIL_ATTRIBUTION,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES,USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *18t8cz-0005wD-00*jYzLB6T5MEM* (SECM, UniS) Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 12 Mar 2003 15:58:47 +0000 Content-Transfer-Encoding: 7bit Hi Hugh again, I fully agree with your proposal. Haitham Hugh Harney wrote: > Pete and Haitham, > > I agree the notification payload could be used to send some management > information back to a member trying to join a group. I think that the > payload should be put into a new class of message. This is a management > information class of message. > > The reason I advocate moving this function to another message class is > that it doesn't directly impact the creation of the cryptographic > group. We need to keep the key exchange protocol simple, easy to > evaluate. The management messages are critical but not > cryptographically important. So, let's put them in their own message > and give us flexibility in how to use those messages. > > The management information message could be used to notify a joining > member of their state, or it could be used to send group management > information between group entities - GC to Subordinate GC, GC to GO. > These messages could make use of existing pairwise keys to protect the > transmission or they could be sent in the clear or they could be sent > using a pairwise secure association. > > I think this management issue is larger than just the notification to > the GM from the GC. I'd like to capture this in the spec in a way that > would allow future developers flexibility to use the management message > structure. > > Hugh > > On Tuesday, Mar 11, 2003, at 12:10 US/Eastern, Peter Lough wrote: > > > I think using the existing Notification payload and extending the > > types so > > that additional information can be passed is useful. In addition to: > > > > Unauthorized Request = 19 > > > > the table might be expanded for example to include: > > > > Account Delinquent = 129 > > > > or Unauthorized Request could be extended to have an application > > specific > > value added. However, as this is used for more detailed information, I > > think the protocol should allow for that information to be encrypted > > via the > > DH exchange that is begun in preparation for the key download. There > > may be > > cases where you don't want others with access to that data channel to > > know > > that a particular account is delinquent or other specific information > > about > > the reason for failure. Encrypting it between the two entities would > > solve > > that issue. > > > > To do this, the protocol could simply allow a message back from the > > server > > with a Key Creation Payload and a Notification Payload encrypted in the > > resultant KEK. > > > > Pete > > ----- Original Message ----- > > From: "Haitham Cruickshank" > > To: "Hugh Harney" > > Cc: ; "Sunil Iyengar" > > ; "Peter Lough" > > Sent: Tuesday, March 11, 2003 11:59 AM > > Subject: Re: [MSEC] Re: GSAKMP Protocol comments > > > > > >> Hi Hugh, > >> > >> Hugh Harney wrote: > >> > >>> Haitham, > >>> > >>> I see your point in desiring a separation between authentication and > > authorization. It may be useful to send a management message to a user > > that > > has passed all the security relevant steps in the GSAKMP RTJ > > processing, but > > has not passed a purely administrative step. > >>> > >>> Your idea of sending an Optional failure notification is interesting. > > Perhaps we may want to expand this idea to a set of generic management > > messages. We could use a management message for failure to pay bills, > > requests for de-registration, audit, or expanded error notifications. > >>> > >>> Do you have a concept in mind for the structure of these messages? > >> > >> In GSAKMP- Light draft and within the notification payload, there is a > > field for Notify Message Type and one of the values is: > >> > >> Unauthorised Request = 19 > >> > >> This can be used by the GSAKMP Server as an OPTIONAL Failure > >> Notification. > >> > >> Is that OK. > >> > >> Haitham & Sunny > >> > >>> > >>> > >>> Hugh > >>> > >>> On Monday, Mar 10, 2003, at 12:47 US/Eastern, Haitham Cruickshank > >>> wrote: > >>> > >>> Hi Peter, > >>> > >>> Further to your email below, we would like to discuss the issue > >>> of > > Failure Notification between GSAKMP Servers and clients and its > > relation to > > DoS attacks. Our thought at University of Surrey and Logica are as > > follows: > >>> > >>> We should separate authentication from authorization issues > >>> between > > the server and clients. Authentication procedures with the GSAKMP > > client > > sending Request To Join (RTJ) to the GSAKMP Server is just > > authenticating > > the RTJ message and can be open to DoS attacks. However the GSAMKP > > Server > > might be connected to an AAA Server to check of that the "well known > > user" > > is authorised to join the group. > >>> > >>> Here is our idea and it is open for discussions: Is it > >>> possible to > > have an OPTIONAL Failure Notification messages that sent by the GSAKMP > > server only if the user is "well known" but the authorisation > > procedure has > > failed (e.g. the user did not pay his bills). In this way, we > > minimize the > > DoS attack possibilities. Of course if the RTJ authentication fails, > > the > > GSAKMP server does NOTHING. > >>> > >>> The alternative is to have a seperate unicast channel for the > > failure notifications, outside the GSAKMP system. > >>> > >>> Regards > >>> Haitham > >>> > >>> Peter Lough wrote: > >>> > >>> Gavin, There is currently work underway here at SPARTA to > >>> finalize > > the current revision of the GSAKMP document. As I understand, there > > has > > been some comments, from you and others working with you at Logica and > > University of Surrey, regarding the inclusion of cookies as an > > anti-clogging > > mechanism as well as the inclusion of additional failure notification > > during > > the group creation phase of the GSAKMP exchange. We would like to be > > responsive to these issues in the current revision and would like you > > to > > refresh us on you concerns with these or any other issues that have > > arisen. > > We think the majority of these discussions will be material to the MSEC > > community at large and to that end would like to handle them via those > > channels. If you would like to format a response to this and simply > > send it > > to MSEC as well, that might be most useful. We will angle our > > discussions > > through the community as well. Of course we can have any necessary > > sidebar > > discussion. Thanks, Peter > >>> LoughSPARTA, Inc. > >>> > >>> -- > >>> Dr. Haitham S. Cruickshank > >>> > >>> Senior Research Fellow in Communications > >>> Centre for Communication Systems Research (CCSR) > >>> School of Electronics, Computing and Mathematics > >>> University of Surrey > >>> Guildford, Surrey GU2 7XH, UK > >>> > >>> Tel: +44 1483 686007 (indirect 689844) > >>> Fax: +44 1483 686011 > >>> e-mail: H.Cruickshank@surrey.ac.uk > >>> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > >>> > >>> > >>> Hugh Harney Sparta, Inc. > >>> hh@sparta.com 7075 Samuel Morse Drive > >>> (410) 872-1515 x203 Columbia, MD, 21046 > >> > >> -- > >> Dr. Haitham S. Cruickshank > >> > >> Senior Research Fellow in Communications > >> Centre for Communication Systems Research (CCSR) > >> School of Electronics, Computing and Mathematics > >> University of Surrey > >> Guildford, Surrey GU2 7XH, UK > >> > >> Tel: +44 1483 686007 (indirect 689844) > >> Fax: +44 1483 686011 > >> e-mail: H.Cruickshank@surrey.ac.uk > >> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > >> > >> > >> > >> _______________________________________________ > >> msec mailing list > >> msec@securemulticast.org > >> http://www.pairlist.net/mailman/listinfo/msec > >> > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://www.pairlist.net/mailman/listinfo/msec > > > > > Hugh Harney Sparta, Inc. > hh@sparta.com 7075 Samuel Morse Drive > (410) 872-1515 x203 Columbia, MD, 21046 -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 14 11:22:22 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01210 for ; Fri, 14 Mar 2003 11:22:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 717C05394D; Fri, 14 Mar 2003 11:24:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2E8CC53938 for ; Fri, 14 Mar 2003 11:22:15 -0500 (EST) Received: (qmail 33904 invoked by uid 3269); 14 Mar 2003 16:22:15 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 33900 invoked from network); 14 Mar 2003 16:22:15 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 14 Mar 2003 16:22:15 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h2EGMDn51198; Fri, 14 Mar 2003 11:22:13 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h2EGMD769566; Fri, 14 Mar 2003 11:22:13 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id LAA31708; Fri, 14 Mar 2003 11:22:12 -0500 From: Ran Canetti Message-Id: <200303141622.LAA31708@ornavella.watson.ibm.com> To: msec@securemulticast.org Cc: jis@mit.edu, smb@research.att.com Subject: [MSEC] MSEC recharter 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, 14 Mar 2003 11:22:12 -0500 Folks, As you know, the deadlines for the milestones in the original MSEC charter are long gone. We were thus asked by the ADs to recharter the group with reasonable deadlines. Below is a proposal. BTW, we also used this opportunity to add a clause saying that we'll also investigate distributed architectures and the many-to-many case, albeit without specific/dedicated deliverables on these issues. Comments are welcome. We'll also discuss this issue at the msec meeting this monday night as SFO. Best, Thomas and Ran The full modified-charter is below. The essential changes are as follows: (1) Addition of new paragraph: "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." (2) New timeline GOALS AND MILESTONES DONE Working Group Last Call on GDOI Protocol. DONE Working Group Last Call on MIKEY Protocol. Mar 03 WG Last Call on Group Key Management Architecture draft Jul 03 WG Last Call on Security Requirements draft and MSEC Architecture draft. Nov 03 WG Last Call on Group Security Policy Architecture draft and Source Authentication draft. Nov 03 WG Last Call on MESP (Multicast ESP) draft. Nov 03 WG Last call on MESP-TESLA draft. Mar 04 WG Last Call on GSAKMP-Light protocol. Jul 04 WG disband or re-charter for other work items. Here is the full modified-charter: ---------------------------------------------------------------------------- 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. Mar 03 WG Last Call on Group Key Management Architecture draft Jul 03 WG Last Call on Security Requirements draft and MSEC Architecture draft. Nov 03 WG Last Call on Group Security Policy Architecture draft and Source Authentication draft. Nov 03 WG Last Call on MESP (Multicast ESP) draft. Nov 03 WG Last call on MESP-TESLA draft. Mar 04 WG Last Call on GSAKMP-Light protocol. Jul 04 WG disband or re-charter for other work items. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sat Mar 15 21:08:53 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA01997 for ; Sat, 15 Mar 2003 21:08:52 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1AA94536E0; Sat, 15 Mar 2003 21:09:18 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id DAD6A53746 for ; Sat, 15 Mar 2003 21:06:55 -0500 (EST) Received: (qmail 36372 invoked by uid 3269); 16 Mar 2003 02:06:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 36369 invoked from network); 16 Mar 2003 02:06:55 -0000 Received: from zcars0m9.nortelnetworks.com (47.129.242.157) by klesh.pair.com with SMTP; 16 Mar 2003 02:06:55 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars0m9.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2G26qN04078 for ; Sat, 15 Mar 2003 21:06:52 -0500 (EST) 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 F1NNDF5X; Sat, 15 Mar 2003 21:06:51 -0500 Received: from nortelnetworks.com (artpt5qp.us.nortel.com [47.140.52.140]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id FSJVYGMW; Sat, 15 Mar 2003 21:06:51 -0500 Message-ID: <3E73DBA4.2010108@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/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] draft-ietf-msec-mesp-01.txt now available on msec website References: <5.0.0.25.2.20030311213703.04df6850@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: Sat, 15 Mar 2003 21:04:20 -0500 Content-Transfer-Encoding: 7bit Mark et. al., Sec 4.1.2 of the new MESP I-D specifies: "MESP internal authentication is either RSA-SHA1 or TESLA." Are RSA-SHA1 and TESLA examples as in Sec 4.2, which seems to be more accommodating in stating "... a key management protocol such as GDOI, GSAKMP ..."? regards, Lakshminath Mark Baugher (by way of Thomas Hardjono ) wrote: > > Folks, > > Draft draft-ietf-msec-mesp-01.txt is now available on the MSEC website. > http://www.securemulticast.org/draft-ietf-msec-mesp-01.txt > > Its also available on > http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-01.txt > > thomas > ------ > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Sun Mar 16 01:53:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07264 for ; Sun, 16 Mar 2003 01:53:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 2D637535B5; Sun, 16 Mar 2003 01:53:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 89CDA53569 for ; Sun, 16 Mar 2003 01:50:53 -0500 (EST) Received: (qmail 1434 invoked by uid 3269); 16 Mar 2003 06:50:53 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1431 invoked from network); 16 Mar 2003 06:50:53 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 16 Mar 2003 06:50:53 -0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2G6ojhs001923; Sat, 15 Mar 2003 22:50:46 -0800 (PST) Received: from cscoamera13263.mbaugher.com (sjc-vpn1-430.cisco.com [10.21.97.174]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.2.1-GA) with ESMTP id ACI32709; Sat, 15 Mar 2003 22:50:43 -0800 (PST) Message-Id: <5.1.1.5.2.20030315224719.021cac60@agora.rdrop.com> X-Sender: mbaugher@agora.rdrop.com X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 To: Lakshminath Dondeti From: Mark Baugher Subject: Re: [MSEC] draft-ietf-msec-mesp-01.txt now available on msec website Cc: msec@securemulticast.org In-Reply-To: <3E73DBA4.2010108@nortelnetworks.com> References: <5.0.0.25.2.20030311213703.04df6850@pop.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sat, 15 Mar 2003 22:50:42 -0800 Lakshminath, At 09:04 PM 3/15/2003 -0500, Lakshminath Dondeti wrote: >Mark et. al., > >Sec 4.1.2 of the new MESP I-D specifies: > >"MESP internal authentication is either RSA-SHA1 or TESLA." > >Are RSA-SHA1 and TESLA examples as in Sec 4.2, which seems to be more >accommodating in stating "... a key management protocol such as GDOI, >GSAKMP ..."? Yes. Section 6.0 gives RSA-SHA1 and TESLA TLV values to the INT transforms for GDOI, GSAKMP, ... Best regards, Mark >regards, >Lakshminath > >Mark Baugher (by way of Thomas Hardjono ) wrote: >>Folks, >>Draft draft-ietf-msec-mesp-01.txt is now available on the MSEC website. >>http://www.securemulticast.org/draft-ietf-msec-mesp-01.txt >>Its also available on >>http://www.rdrop.com/users/mbaugher/I-D/draft-ietf-msec-mesp-01.txt >>thomas >>------ >> >>_______________________________________________ >>msec mailing list >>msec@securemulticast.org >>http://www.pairlist.net/mailman/listinfo/msec > > > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://www.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 18 07:44:24 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09707 for ; Tue, 18 Mar 2003 07:44:23 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 96F8853722; Tue, 18 Mar 2003 07:46:05 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 709E753577 for ; Tue, 18 Mar 2003 07:45:20 -0500 (EST) Received: (qmail 3566 invoked by uid 3269); 18 Mar 2003 12:45:20 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 3563 invoked from network); 18 Mar 2003 12:45:20 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 18 Mar 2003 12:45:20 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18vGSs-0002DB-00; Tue, 18 Mar 2003 12:45:10 +0000 Message-ID: <3E7714D4.77F10664@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Hugh Harney , Peter Lough Cc: msec group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-112.2 required=5.5 tests=AWL,BAYES_01,USER_IN_WHITELIST version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *18vGSs-0002DB-00*56S9NPLDV7k* (SECM, UniS) Subject: [MSEC] GSAKMP - rekeying - synchronisation 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, 18 Mar 2003 12:45:09 +0000 Content-Transfer-Encoding: 7bit Hi Hugh and Peter, We have a small question regarding the synchronisation between a secure multicast group members after a rekeying event. This is a general concept for GSAKMP and GDOI, however I will ask the question in context of GSAKMP. The question is: After the GSAKMP server sends a server-rekey message to all GSAKMP clients to update their traffic keys (such as member leaving or joining, etc..), how the traffic sender (multicast source) and the multicast traffic receivers will synchronise the use of the new keys that has been just distributed by the GSAKMP server ?. In the context of using GSAKMP with IPSEC, one idea is to use the traffic key-handle (which is distributed by the GSAKMP server with the key itself) as the SPI (Security Parameter Index) in IPSEC. If this is correct, then a server re-key message received by the GSAKMP client means a new IPSEC key and new SPI as well (new security association). In this case, re-synchronisation is not a problem as more. Any comments on this are welcome. Haitham & the Surrey team. -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Tue Mar 18 13:22:45 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22170 for ; Tue, 18 Mar 2003 13:22:44 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4403B5366B; Tue, 18 Mar 2003 13:24:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 158C0536CE for ; Tue, 18 Mar 2003 13:22:08 -0500 (EST) Received: (qmail 57297 invoked by uid 3269); 18 Mar 2003 18:22:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 57294 invoked from network); 18 Mar 2003 18:22:07 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 18 Mar 2003 18:22:07 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18vLiW-0002yF-00; Tue, 18 Mar 2003 18:21:40 +0000 Message-ID: <3E7763B4.8CF160D3@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: msec group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-115.0 required=5.5 tests=AWL,BAYES_01,ORIGINAL_MESSAGE,USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *18vLiW-0002yF-00*pjrASOTnKnc* (SECM, UniS) Subject: [MSEC] [Fwd: GSAKMP - rekeying - synchronisation] 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, 18 Mar 2003 18:21:40 +0000 Content-Transfer-Encoding: 7bit -------- Original Message -------- Subject: GSAKMP - rekeying - synchronisation Date: Tue, 18 Mar 2003 12:45:09 +0000 From: Haitham Cruickshank Organization: CCSR To: Hugh Harney , Peter Lough CC: msec group Hi Hugh and Peter, We have a small question regarding the synchronisation between a secure multicast group members after a rekeying event. This is a general concept for GSAKMP and GDOI, however I will ask the question in context of GSAKMP. The question is: After the GSAKMP server sends a server-rekey message to all GSAKMP clients to update their traffic keys (such as member leaving or joining, etc..), how the traffic sender (multicast source) and the multicast traffic receivers will synchronise the use of the new keys that has been just distributed by the GSAKMP server ?. In the context of using GSAKMP with IPSEC, one idea is to use the traffic key-handle (which is distributed by the GSAKMP server with the key itself) as the SPI (Security Parameter Index) in IPSEC. If this is correct, then a server re-key message received by the GSAKMP client means a new IPSEC key and new SPI as well (new security association). In this case, re-synchronisation is not a problem as more. Any comments on this are welcome. Haitham & the Surrey team. -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 20 07:30:26 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15559 for ; Thu, 20 Mar 2003 07:30:21 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 40EC2536AC; Thu, 20 Mar 2003 07:29:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2328F53673 for ; Thu, 20 Mar 2003 07:26:03 -0500 (EST) Received: (qmail 99312 invoked by uid 3269); 20 Mar 2003 12:26:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99309 invoked from network); 20 Mar 2003 12:26:03 -0000 Received: from prue.eim.surrey.ac.uk (131.227.76.5) by klesh.pair.com with SMTP; 20 Mar 2003 12:26:03 -0000 Received: from ccsrnrpc16.ee.surrey.ac.uk ([131.227.88.65] helo=eim.surrey.ac.uk) by prue.eim.surrey.ac.uk with esmtp (Exim 3.33 #4) id 18vz7G-0002iv-00 for msec@securemulticast.org; Thu, 20 Mar 2003 12:25:50 +0000 Message-ID: <3E79B34E.6CE0CD07@eim.surrey.ac.uk> From: Haitham Cruickshank Organization: CCSR X-Mailer: Mozilla 4.76 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: msec group Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-114.5 required=5.5 tests=AWL,BAYES_01,ORIGINAL_MESSAGE,USER_IN_WHITELIST autolearn=ham version=2.50 X-Spam-Checker-Version: SpamAssassin 2.50 (1.173-2003-02-20-exp) X-Scanner: exiscan *18vz7G-0002iv-00*iycz51wdyYs* (SECM, UniS) Subject: [MSEC] [Fwd: [Fwd: GSAKMP - rekeying - synchronisation]] 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, 20 Mar 2003 12:25:50 +0000 Content-Transfer-Encoding: 7bit Hi All, Was there a problem with the msec mailing list in the last few days ?. Haitham -------- Original Message -------- Subject: [Fwd: GSAKMP - rekeying - synchronisation] Date: Tue, 18 Mar 2003 18:21:40 +0000 From: Haitham Cruickshank Organization: CCSR To: msec group -------- Original Message -------- Subject: GSAKMP - rekeying - synchronisation Date: Tue, 18 Mar 2003 12:45:09 +0000 From: Haitham Cruickshank Organization: CCSR To: Hugh Harney , Peter Lough CC: msec group Hi Hugh and Peter, We have a small question regarding the synchronisation between a secure multicast group members after a rekeying event. This is a general concept for GSAKMP and GDOI, however I will ask the question in context of GSAKMP. The question is: After the GSAKMP server sends a server-rekey message to all GSAKMP clients to update their traffic keys (such as member leaving or joining, etc..), how the traffic sender (multicast source) and the multicast traffic receivers will synchronise the use of the new keys that has been just distributed by the GSAKMP server ?. In the context of using GSAKMP with IPSEC, one idea is to use the traffic key-handle (which is distributed by the GSAKMP server with the key itself) as the SPI (Security Parameter Index) in IPSEC. If this is correct, then a server re-key message received by the GSAKMP client means a new IPSEC key and new SPI as well (new security association). In this case, re-synchronisation is not a problem as more. Any comments on this are welcome. Haitham & the Surrey team. -- Dr. Haitham S. Cruickshank Senior Research Fellow in Communications Centre for Communication Systems Research (CCSR) School of Electronics, Computing and Mathematics University of Surrey Guildford, Surrey GU2 7XH, UK Tel: +44 1483 686007 (indirect 689844) Fax: +44 1483 686011 e-mail: H.Cruickshank@surrey.ac.uk http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Thu Mar 20 22:33:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20123 for ; Thu, 20 Mar 2003 22:33:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7E30B5375C; Thu, 20 Mar 2003 22:35:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 2DD9A5384D for ; Thu, 20 Mar 2003 22:32:43 -0500 (EST) Received: (qmail 38886 invoked by uid 3269); 21 Mar 2003 03:32:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 38883 invoked from network); 21 Mar 2003 03:32:43 -0000 Received: from igw2.watson.ibm.com (129.34.20.6) by klesh.pair.com with SMTP; 21 Mar 2003 03:32:43 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h2L3Whn163264 for ; Thu, 20 Mar 2003 22:32:43 -0500 Received: from ornavella.watson.ibm.com (ornavella.watson.ibm.com [9.2.16.80]) by sp1n293en1.watson.ibm.com (8.11.6/8.11.4) with ESMTP id h2L3Whl63702 for ; Thu, 20 Mar 2003 22:32:43 -0500 Received: (from canetti@localhost) by ornavella.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) id WAA35190 for msec@securemulticast.org; Thu, 20 Mar 2003 22:32:42 -0500 From: Ran Canetti Message-Id: <200303210332.WAA35190@ornavella.watson.ibm.com> To: msec@securemulticast.org Subject: [MSEC] Comments on GSAKMP lite 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, 20 Mar 2003 22:32:42 -0500 Folks, I enclose a summary of a discussion I had with Hugh and Andrea in SFO where I raised some issues regarding the GSAKMP-lite document. In general, I felt that the protocol is good (modulo the points below) and the document is well written. However, the points below seem to require addressing. Best, Ran * One editorial point was the lack of a "Security considerations" section. Beyond being a formal requirement, such a section is a great place to discuss many security issues relating to GSAKMP. (some examples can be extracted from the remarks below.) * DOS resilience: In the current protocol, the first message (coming from the joining member) contains a Diffie-Hellman exponent. the GCKS needs to compute the DH secret before sending the response message. This requires a modular exponentiation - which is a costly operation. Thus, a naive implementation of a GCKS is highly susceptible to DOS attack that floods the GCKS with bogus DH exponents and causes the GCKS to do a costly exponentiation in response to each one. Andrea pointed out that if the GCKS has a list of "acceptable group members" then the GCKS could reject bogus join requests without doing the exponentiation. But such lists are not always available, and furthermore verifying that a join request really comes from an acceptable member involves verifying certificates, which is costly by itself. Therefore I think it would be a very good idea to add an anti-DOS mechanism to the protocol. One such mechanism, that is currently used in IKEv2, is to add a optional cookie exchange between message 1 and 2. the exchange will be turned on by the GCKS whenever it feels it is under DOS attack. * Currently the third message (the ACK message sent by the member) is digitally signed by the member. Instead of signing, it is enough to MAC this message using a key derived from the agreed DH key. This will save an unnecessary and costly signature generation and verification. (Derivation of an additional MAC key is easy - just extend the derivation of the encryption key (used in message 2) to derive also a MAC key.) * Recall the attack that Cathy Meadows found against a prior version of GDOI: It was possible to use a signature generated by the GCKS in the registration protocol to spoof a rekey message (and vice versa). The solution in GDOI was to add reserved values to the signed texts that make it clear in which context a signature is generated. A similar mechanism should be done explicitly in GSAKMP, to avoid similar attacks. Apparently there are currently such values in the GSAKMP message headers; but these should be made explicit and it should be made sure that the values are actually signed. * Another concern was to add the identity of the GCKS to the signed text in the join request. This may mitigate the damage caused by a rogoue GCKS in a distributed architecture. Hugh pointed out that there may be interoperabiltiy advantages in NOT doing that. I'm interested to hear what other people have to say about this traddeoff. In any case, the issue should probably be discussed in the security considerations section. * Regarding the order of encyption and signature in the key download message: It wasnt clear to me whther the intention was first to encrypt the polcy token and key download payloads, and then sign the ciphertexts (along with the other fields to be signed), or alternatively to encrypt the signature. I strongly vote for the first method - since the second method does not guarantee the secrecy of the data. (See for instance the attack in [K01].) * The current draft specifies "minimum fields to be included un der the signature" in the three messages. For sake of unambiguity, it would be better to specify these fields deterministically - without allowing for potentially additional signed fields. * Some additional work needs to be done in order to make GSAKMP compatible with TESLA. The main issue is to augment GSAKMP so that it will be possible to piggyback a time synchronization exchange on the GSAKMP messages. I will not get into more details here; this should probably be done in cooperation with the authors of the TESLA drafts. * I think it will be a very good idea to discuss in the security considerations section why the protocol may be secure. This is especially in place since the current version is doing things from scratch, and does not use off-the-shelf (and hopefully analyzed) key exchange protocols. Here is my 2c towars this goal. The basic exchange in the registration protocol can be regarded as a variant of the ISO 9798-3 protocol, which is sketched below. The policy token and the group keys are then encrypted using a key derived from the agreed DH secret. The ISO 9798-3 protocol was analyzed in [CK01]. The ISO 9798-3 protocol: A->B: A,N_a,g^a B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A) A->B: SIG_a(N_a,N_b,g^a,g^b,A,B) A salient point about this protocol is that each party signs, in addition to the nonces and the two public DH exponents, also the identity of the peer. (If the peer's identity is not signed then the protocol is completely broken.) In the context of GSAKMP the identity of "B" is the group ID. [Note though that this relates only to a small part of the GSAKMP protocol. Full analysis should include the entire protocol, including the rekey messages and group evolution over time.] [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols and Their Use for Building Secure Channels", Eurocrypt 01. Available at http://eprint.iacr.org/2001/040. [K01] H. Krawczyk, "On the order of encryption and authentication, or how secure is SSL", Crypto 01. _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 21 13:45:47 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22240 for ; Fri, 21 Mar 2003 13:45:47 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 1D1FE538DC; Fri, 21 Mar 2003 13:44:25 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 70410538D2 for ; Fri, 21 Mar 2003 13:43:00 -0500 (EST) Received: (qmail 90761 invoked by uid 3269); 21 Mar 2003 18:43:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90758 invoked from network); 21 Mar 2003 18:43:00 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 21 Mar 2003 18:43:00 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2LIgks19183; Fri, 21 Mar 2003 13:42:46 -0500 (EST) 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 HB8ALLXL; Fri, 21 Mar 2003 13:42:45 -0500 Received: from nortelnetworks.com (asc4t1kj.us.nortel.com [47.81.5.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HBX3B8ZW; Fri, 21 Mar 2003 13:42:45 -0500 Message-ID: <3E7B5D0A.9080308@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/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ran Canetti Cc: msec@securemulticast.org Subject: Re: [MSEC] Comments on GSAKMP lite References: <200303210332.WAA35190@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 13:42:18 -0500 Content-Transfer-Encoding: 7bit Ran, First of all many thanks for the quick analysis. I have a couple of comments. I too talked to Hugh and Andrea at the GSEC meeting and noted that the GSAKMP I-D needs more detail on, for example, how keys are derived. In general, I would like the document to contain sufficient detail so an engineer can implement the protocol by reading it. On a side note, while implementing GDOI, while I asked Brian for additional details a few times, I could refer to ISAKMP and IKE RFCs for insights and rationale. Finally, I agree with you that the document needs explanations on the protections offered and not offered, in a detailed security considerations section. best regards, Lakshminath Ran Canetti wrote: > Folks, > > I enclose a summary of a discussion I had with Hugh and Andrea in SFO > where I raised some issues regarding the GSAKMP-lite document. In general, > I felt that the protocol is good (modulo the points below) and the document > is well written. However, the points below seem to require addressing. > > Best, > > Ran > > > > * One editorial point was the lack of a "Security considerations" section. > Beyond being a formal requirement, such a section is a great place to > discuss many security issues relating to GSAKMP. (some examples can be > extracted from the remarks below.) > > * DOS resilience: In the current protocol, the first message (coming from > the joining member) contains a Diffie-Hellman exponent. the GCKS needs > to compute the DH secret before sending the response message. This requires > a modular exponentiation - which is a costly operation. Thus, a naive > implementation of a GCKS is highly susceptible to DOS attack that floods > the GCKS with bogus DH exponents and causes the GCKS to do a costly > exponentiation in response to each one. Andrea pointed out that if the GCKS > has a list of "acceptable group members" then the GCKS could > reject bogus join requests without doing the exponentiation. > But such lists are not always available, and furthermore verifying that a > join request really comes from an acceptable member involves verifying > certificates, which is costly by itself. > > Therefore I think it would be a very good idea to add an anti-DOS mechanism > to the protocol. One such mechanism, that is currently used in IKEv2, is to > add a optional cookie exchange between message 1 and 2. the exchange will be > turned on by the GCKS whenever it feels it is under DOS attack. > > * Currently the third message (the ACK message sent by the member) is > digitally signed by the member. Instead of signing, it is enough to MAC this > message using a key derived from the agreed DH key. This will save an > unnecessary and costly signature generation and verification. > (Derivation of an additional MAC key is easy - just extend the derivation > of the encryption key (used in message 2) to derive also a MAC key.) > > * Recall the attack that Cathy Meadows found against a prior version of > GDOI: It was possible to use a signature generated by the GCKS in the > registration protocol to spoof a rekey message (and vice versa). The > solution in GDOI was to add reserved values to the signed texts that > make it clear in which context a signature is generated. > A similar mechanism should be done explicitly in GSAKMP, to avoid similar > attacks. Apparently there are currently such values in the GSAKMP message > headers; but these should be made explicit and it should be made sure that > the values are actually signed. > > * Another concern was to add the identity of the GCKS to the signed text > in the join request. This may mitigate the damage caused by a rogoue GCKS in > a distributed architecture. Hugh pointed out that there may be > interoperabiltiy advantages in NOT doing that. I'm interested to hear what > other people have to say about this traddeoff. In any case, the issue should > probably be discussed in the security considerations section. > > * Regarding the order of encyption and signature in the key download > message: It wasnt clear to me whther the intention was first to encrypt the > polcy token and key download payloads, and then sign the ciphertexts (along > with the other fields to be signed), or alternatively to encrypt the > signature. I strongly vote for the first method - since the second method > does not guarantee the secrecy of the data. (See for instance the attack > in [K01].) > > * The current draft specifies "minimum fields to be included un der the > signature" in the three messages. For sake of unambiguity, it would be > better to specify these fields deterministically - without allowing > for potentially additional signed fields. > > * Some additional work needs to be done in order to make GSAKMP compatible > with TESLA. The main issue is to augment GSAKMP so that it will be possible to > piggyback a time synchronization exchange on the GSAKMP messages. I will not > get into more details here; this should probably be done in cooperation > with the authors of the TESLA drafts. > > * I think it will be a very good idea to discuss in the security considerations > section why the protocol may be secure. This is especially in place since > the current version is doing things from scratch, and does not use > off-the-shelf (and hopefully analyzed) key exchange protocols. > > Here is my 2c towars this goal. The basic exchange in the registration protocol > can be regarded as a variant of the ISO 9798-3 protocol, which is sketched > below. The policy token and the group keys are then encrypted using a key > derived from the agreed DH secret. The ISO 9798-3 protocol was analyzed in > [CK01]. > > The ISO 9798-3 protocol: > > A->B: A,N_a,g^a > B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A) > A->B: SIG_a(N_a,N_b,g^a,g^b,A,B) > > A salient point about this protocol is that each party signs, in > addition to the nonces and the two public DH exponents, also the > identity of the peer. (If the peer's identity is not signed then > the protocol is completely broken.) In the context of GSAKMP the > identity of "B" is the group ID. > > [Note though that this relates only to a small part of the GSAKMP protocol. > Full analysis should include the entire protocol, including the rekey > messages and group evolution over time.] > > > > [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols > and Their Use for Building Secure Channels", Eurocrypt 01. > Available at http://eprint.iacr.org/2001/040. > > > [K01] H. Krawczyk, "On the order of encryption and authentication, or > how secure is SSL", Crypto 01. > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 21 13:47:51 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22306 for ; Fri, 21 Mar 2003 13:47:51 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 56AC5538E0; Fri, 21 Mar 2003 13:44:35 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 79FA8538D2 for ; Fri, 21 Mar 2003 13:43:45 -0500 (EST) Received: (qmail 90866 invoked by uid 3269); 21 Mar 2003 18:43:45 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90863 invoked from network); 21 Mar 2003 18:43:45 -0000 Received: from zcars04f.nortelnetworks.com (47.129.242.57) by klesh.pair.com with SMTP; 21 Mar 2003 18:43:45 -0000 Received: from zbl6c012.us.nortel.com (zbl6c012.corpeast.baynetworks.com [132.245.205.62]) by zcars04f.nortelnetworks.com (Switch-2.2.5/Switch-2.2.0) with ESMTP id h2LIhhs19263 for ; Fri, 21 Mar 2003 13:43:43 -0500 (EST) 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 HB8ALLXR; Fri, 21 Mar 2003 13:43:42 -0500 Received: from nortelnetworks.com (asc4t1kj.us.nortel.com [47.81.5.157]) by zbl6c002.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HBX3B8ZY; Fri, 21 Mar 2003 13:43:42 -0500 Message-ID: <3E7B5D46.8040004@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/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Subject: DoS protection in Re: [MSEC] Comments on GSAKMP lite References: <200303210332.WAA35190@ornavella.watson.ibm.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 13:43:18 -0500 Content-Transfer-Encoding: 7bit Considering the remote access application, IKEv2 was designed to protect the Responder from DoS attacks. For key download protocols, this attack is all the more important, as the GCKS is always the Responder. Furthermore, it is quite possible that Registration requests arrive at a GCKS closer together (to each other) than remote access requests at an IPsec gateway. Thus, the GCKS may not be able to differentiate between an attack and a high volume of legitimate requests. Instead of the 3/5 message option (Ran's suggestion), why not make GSAKMP an always 5 message protocol. regards, Lakshminath Ran Canetti wrote: > * DOS resilience: In the current protocol, the first message (coming from > the joining member) contains a Diffie-Hellman exponent. the GCKS needs > to compute the DH secret before sending the response message. This requires > a modular exponentiation - which is a costly operation. Thus, a naive > implementation of a GCKS is highly susceptible to DOS attack that floods > the GCKS with bogus DH exponents and causes the GCKS to do a costly > exponentiation in response to each one. Andrea pointed out that if the GCKS > has a list of "acceptable group members" then the GCKS could > reject bogus join requests without doing the exponentiation. > But such lists are not always available, and furthermore verifying that a > join request really comes from an acceptable member involves verifying > certificates, which is costly by itself. > > Therefore I think it would be a very good idea to add an anti-DOS mechanism > to the protocol. One such mechanism, that is currently used in IKEv2, is to > add a optional cookie exchange between message 1 and 2. the exchange will be > turned on by the GCKS whenever it feels it is under DOS attack. > > * Currently the third message (the ACK message sent by the member) is > digitally signed by the member. Instead of signing, it is enough to MAC this > message using a key derived from the agreed DH key. This will save an > unnecessary and costly signature generation and verification. > (Derivation of an additional MAC key is easy - just extend the derivation > of the encryption key (used in message 2) to derive also a MAC key.) > > * Recall the attack that Cathy Meadows found against a prior version of > GDOI: It was possible to use a signature generated by the GCKS in the > registration protocol to spoof a rekey message (and vice versa). The > solution in GDOI was to add reserved values to the signed texts that > make it clear in which context a signature is generated. > A similar mechanism should be done explicitly in GSAKMP, to avoid similar > attacks. Apparently there are currently such values in the GSAKMP message > headers; but these should be made explicit and it should be made sure that > the values are actually signed. > > * Another concern was to add the identity of the GCKS to the signed text > in the join request. This may mitigate the damage caused by a rogoue GCKS in > a distributed architecture. Hugh pointed out that there may be > interoperabiltiy advantages in NOT doing that. I'm interested to hear what > other people have to say about this traddeoff. In any case, the issue should > probably be discussed in the security considerations section. > > * Regarding the order of encyption and signature in the key download > message: It wasnt clear to me whther the intention was first to encrypt the > polcy token and key download payloads, and then sign the ciphertexts (along > with the other fields to be signed), or alternatively to encrypt the > signature. I strongly vote for the first method - since the second method > does not guarantee the secrecy of the data. (See for instance the attack > in [K01].) > > * The current draft specifies "minimum fields to be included un der the > signature" in the three messages. For sake of unambiguity, it would be > better to specify these fields deterministically - without allowing > for potentially additional signed fields. > > * Some additional work needs to be done in order to make GSAKMP compatible > with TESLA. The main issue is to augment GSAKMP so that it will be possible to > piggyback a time synchronization exchange on the GSAKMP messages. I will not > get into more details here; this should probably be done in cooperation > with the authors of the TESLA drafts. > > * I think it will be a very good idea to discuss in the security considerations > section why the protocol may be secure. This is especially in place since > the current version is doing things from scratch, and does not use > off-the-shelf (and hopefully analyzed) key exchange protocols. > > Here is my 2c towars this goal. The basic exchange in the registration protocol > can be regarded as a variant of the ISO 9798-3 protocol, which is sketched > below. The policy token and the group keys are then encrypted using a key > derived from the agreed DH secret. The ISO 9798-3 protocol was analyzed in > [CK01]. > > The ISO 9798-3 protocol: > > A->B: A,N_a,g^a > B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A) > A->B: SIG_a(N_a,N_b,g^a,g^b,A,B) > > A salient point about this protocol is that each party signs, in > addition to the nonces and the two public DH exponents, also the > identity of the peer. (If the peer's identity is not signed then > the protocol is completely broken.) In the context of GSAKMP the > identity of "B" is the group ID. > > [Note though that this relates only to a small part of the GSAKMP protocol. > Full analysis should include the entire protocol, including the rekey > messages and group evolution over time.] > > > > [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols > and Their Use for Building Secure Channels", Eurocrypt 01. > Available at http://eprint.iacr.org/2001/040. > > > [K01] H. Krawczyk, "On the order of encryption and authentication, or > how secure is SSL", Crypto 01. > > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 21 14:32:37 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23965 for ; Fri, 21 Mar 2003 14:32:37 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9CD77535AC; Fri, 21 Mar 2003 14:34:02 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 5AD905375A for ; Fri, 21 Mar 2003 14:32:18 -0500 (EST) Received: (qmail 99724 invoked by uid 3269); 21 Mar 2003 19:32:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 99721 invoked from network); 21 Mar 2003 19:32:18 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 21 Mar 2003 19:32:18 -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 h2LJWnkD017651; Fri, 21 Mar 2003 13:32:49 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h2LJXTV4020245; Fri, 21 Mar 2003 13:33:29 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id OAA25903; Fri, 21 Mar 2003 14:32:11 -0500 (EST) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: msec group To: Haitham Cruickshank From: Hugh Harney In-Reply-To: <3E7714D4.77F10664@eim.surrey.ac.uk> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Subject: [MSEC] Re: GSAKMP - rekeying - synchronisation 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, 21 Mar 2003 14:32:16 -0500 Content-Transfer-Encoding: 7bit Haitham, I'm sorry I was at the IETF last week and was distracted. The problem of group synchronisation for encryption and decryption is a well known problem. The solution is not perfect. We can allow an encryptor to use the old key k for a period of time t1. The decryptors will hopefully get the new key k* before the encryptor starts using the new key for transmission at t1+1. If the decryptors get k* before t1 they can store it and decrypt on k or k*. If the decryptor does not get k* by t1+1, there is a problem. Some traffic will be lost due to the decryptors inability to decrypt traffic encrypted in k*. Due to the unreliable nature of group communications, this problem is difficult to deal with gracefully. I think that the responsibility for staying in synch lies with the decryptor. If the decryptor detects that it lost synch, it re-joins the group. This is the simplest mode of operation. If we require all members of the group to notify the receipt and processing of a rekey message we would bring the multicast group to it's knees. thanks Hugh On Tuesday, Mar 18, 2003, at 07:45 US/Eastern, Haitham Cruickshank wrote: > Hi Hugh and Peter, > > We have a small question regarding the synchronization between a secure > multicast group members after a rekeying event. This is a general > concept for GSAKMP and GDOI, however I will ask the question in context > of GSAKMP. > > The question is: After the GSAKMP server sends a server-rekey message > to > all GSAKMP clients to update their traffic keys (such as member leaving > or joining, etc..), how the traffic sender (multicast source) and the > multicast traffic receivers will synchronise the use of the new keys > that has been just distributed by the GSAKMP server ?. > > In the context of using GSAKMP with IPSEC, one idea is to use the > traffic key-handle (which is distributed by the GSAKMP server with the > key itself) as the SPI (Security Parameter Index) in IPSEC. If this > is correct, then a server re-key message received by the GSAKMP client > means a new IPSEC key and new SPI as well (new security association). > In this case, re-synchronisation is not a problem as more. > > Any comments on this are welcome. > > Haitham & the Surrey team. > -- > Dr. Haitham S. Cruickshank > > Senior Research Fellow in Communications > Centre for Communication Systems Research (CCSR) > School of Electronics, Computing and Mathematics > University of Surrey > Guildford, Surrey GU2 7XH, UK > > Tel: +44 1483 686007 (indirect 689844) > Fax: +44 1483 686011 > e-mail: H.Cruickshank@surrey.ac.uk > http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ > > > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Fri Mar 21 15:37:09 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26791 for ; Fri, 21 Mar 2003 15:37:09 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 4B7DF537B8; Fri, 21 Mar 2003 15:38:21 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4E4FF53569 for ; Fri, 21 Mar 2003 15:37:42 -0500 (EST) Received: (qmail 12242 invoked by uid 3269); 21 Mar 2003 20:37:42 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12239 invoked from network); 21 Mar 2003 20:37:42 -0000 Received: from m5.sparta.com (157.185.61.1) by klesh.pair.com with SMTP; 21 Mar 2003 20:37:42 -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 h2LKcBkD019996; Fri, 21 Mar 2003 14:38:11 -0600 Received: from columbia.sparta.com (columbia.sparta.com [157.185.80.205]) by beta5.sparta.com (8.12.5/8.12.5) with ESMTP id h2LKcpV4022392; Fri, 21 Mar 2003 14:38:52 -0600 Received: from sparta.com (dhcp-9.columbia.sparta.com [157.185.80.20]) by columbia.sparta.com (8.9.1a/8.9.1) with ESMTP id PAA27054; Fri, 21 Mar 2003 15:37:33 -0500 (EST) Subject: Re: DoS protection in Re: [MSEC] Comments on GSAKMP lite Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v551) Cc: msec@securemulticast.org To: Lakshminath Dondeti From: Hugh Harney In-Reply-To: <3E7B5D46.8040004@nortelnetworks.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.551) Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Fri, 21 Mar 2003 15:37:38 -0500 Content-Transfer-Encoding: 7bit Lakshminath, I see architectures where groups could be created within protected enviroments and would never need the cookie exchange to prevent DOS. I also think that "normal" operation may well use the 3 message protocol instead of requiring the additional delay imposed by a two message cookie exchange. I'd like to point out that GSAKMP can distribute the key dissemination function to several subordinate GC/KSs. This distributed operation avoids having an over worked centralized point of service / failure for group key distribution. Any one GC/KS or subordinate GC/KS should be able to determine when it is under attack and switch to cookie mode. I'd like to keep the 3 message protocol as the core with an optional 5 message version for periods where there is stress. Hugh On Friday, Mar 21, 2003, at 13:43 US/Eastern, Lakshminath Dondeti wrote: > Considering the remote access application, IKEv2 was designed to > protect the Responder from DoS attacks. For key download protocols, > this attack is all the more important, as the GCKS is always the > Responder. Furthermore, it is quite possible that Registration > requests arrive at a GCKS closer together (to each other) than remote > access requests at an IPsec gateway. Thus, the GCKS may not be able > to differentiate between an attack and a high volume of legitimate > requests. > > Instead of the 3/5 message option (Ran's suggestion), why not make > GSAKMP an always 5 message protocol. > > regards, > Lakshminath > > Ran Canetti wrote: > >> * DOS resilience: In the current protocol, the first message (coming >> from >> the joining member) contains a Diffie-Hellman exponent. the GCKS >> needs to compute the DH secret before sending the response message. >> This requires >> a modular exponentiation - which is a costly operation. Thus, a naive >> implementation of a GCKS is highly susceptible to DOS attack that >> floods the GCKS with bogus DH exponents and causes the GCKS to do a >> costly exponentiation in response to each one. Andrea pointed out >> that if the GCKS >> has a list of "acceptable group members" then the GCKS could reject >> bogus join requests without doing the exponentiation. But such lists >> are not always available, and furthermore verifying that a >> join request really comes from an acceptable member involves verifying >> certificates, which is costly by itself. >> Therefore I think it would be a very good idea to add an anti-DOS >> mechanism >> to the protocol. One such mechanism, that is currently used in IKEv2, >> is to >> add a optional cookie exchange between message 1 and 2. the exchange >> will be >> turned on by the GCKS whenever it feels it is under DOS attack. >> * Currently the third message (the ACK message sent by the member) is >> digitally signed by the member. Instead of signing, it is enough to >> MAC this >> message using a key derived from the agreed DH key. This will save an >> unnecessary and costly signature generation and verification. >> (Derivation of an additional MAC key is easy - just extend the >> derivation of the encryption key (used in message 2) to derive also a >> MAC key.) >> * Recall the attack that Cathy Meadows found against a prior version >> of >> GDOI: It was possible to use a signature generated by the GCKS in the >> registration protocol to spoof a rekey message (and vice versa). The >> solution in GDOI was to add reserved values to the signed texts that >> make it clear in which context a signature is generated. >> A similar mechanism should be done explicitly in GSAKMP, to avoid >> similar >> attacks. Apparently there are currently such values in the GSAKMP >> message >> headers; but these should be made explicit and it should be made sure >> that >> the values are actually signed. >> * Another concern was to add the identity of the GCKS to the signed >> text >> in the join request. This may mitigate the damage caused by a rogoue >> GCKS in >> a distributed architecture. Hugh pointed out that there may be >> interoperabiltiy advantages in NOT doing that. I'm interested to hear >> what >> other people have to say about this traddeoff. In any case, the issue >> should >> probably be discussed in the security considerations section. >> * Regarding the order of encyption and signature in the key download >> message: It wasnt clear to me whther the intention was first to >> encrypt the >> polcy token and key download payloads, and then sign the ciphertexts >> (along >> with the other fields to be signed), or alternatively to encrypt the >> signature. I strongly vote for the first method - since the second >> method >> does not guarantee the secrecy of the data. (See for instance the >> attack >> in [K01].) * The current draft specifies "minimum fields to be >> included un der the >> signature" in the three messages. For sake of unambiguity, it would >> be better to specify these fields deterministically - without >> allowing for potentially additional signed fields. >> * Some additional work needs to be done in order to make GSAKMP >> compatible >> with TESLA. The main issue is to augment GSAKMP so that it will be >> possible to piggyback a time synchronization exchange on the GSAKMP >> messages. I will not >> get into more details here; this should probably be done in >> cooperation >> with the authors of the TESLA drafts. >> * I think it will be a very good idea to discuss in the security >> considerations >> section why the protocol may be secure. This is especially in place >> since >> the current version is doing things from scratch, and does not use >> off-the-shelf (and hopefully analyzed) key exchange protocols. >> Here is my 2c towars this goal. The basic exchange in the >> registration protocol can be regarded as a variant of the ISO 9798-3 >> protocol, which is sketched below. The policy token and the group >> keys are then encrypted using a key derived from the agreed DH >> secret. The ISO 9798-3 protocol was analyzed in >> [CK01]. >> The ISO 9798-3 protocol: >> A->B: A,N_a,g^a >> B->A: B,N_b,g^b,SIG_b(N_a,N_b,g^a,g^b,B,A) >> A->B: SIG_a(N_a,N_b,g^a,g^b,A,B) >> A salient point about this protocol is that each party signs, in >> addition to the nonces and the two public DH exponents, also the >> identity of the peer. (If the peer's identity is not signed then >> the protocol is completely broken.) In the context of GSAKMP the >> identity of "B" is the group ID. >> [Note though that this relates only to a small part of the GSAKMP >> protocol. >> Full analysis should include the entire protocol, including the rekey >> messages and group evolution over time.] >> [CK01] Canetti and Krawczyk, "Analysis of Key-Exchange Protocols >> and Their Use for Building Secure Channels", Eurocrypt 01. >> Available at http://eprint.iacr.org/2001/040. >> [K01] H. Krawczyk, "On the order of encryption and >> authentication, or >> how secure is SSL", Crypto 01. >> _______________________________________________ >> msec mailing list >> msec@securemulticast.org >> http://www.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://www.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec From msec-admin@securemulticast.org Mon Mar 24 07:26:41 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12305 for ; Mon, 24 Mar 2003 07:26:41 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id E5D83536EC; Mon, 24 Mar 2003 07:28:24 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 4C7F1535B1 for ; Mon, 24 Mar 2003 07:27:59 -0500 (EST) Received: (qmail 59803 invoked by uid 3269); 24 Mar 2003 12:27:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 59800 invoked from network); 24 Mar 2003 12:27:59 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 24 Mar 2003 12:27: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 HAA12161; Mon, 24 Mar 2003 07:25:39 -0500 (EST) Message-Id: <200303241225.HAA12161@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-mesp-01.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Mon, 24 Mar 2003 07:25:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : MESP: A Multicast Framework for the IPsec ESP Author(s) : M. Baugher, R. Canetti Filename : draft-ietf-msec-mesp-01.txt Pages : 13 Date : 2003-3-21 Multicast ESP (MESP) is a framework for multicast data-origin authentication using the IPsec Encapsulating Security Payload (ESP) protocol. The MESP framework combines group-secrecy, group- authentication, and source-authentication transforms in an ESP packet. MESP uses a message authentication code for group authentication to protect a digital signature, TESLA timed MAC, or other multicast source-authentication transform. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-msec-mesp-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-mesp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-mesp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-21155057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-mesp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-mesp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-21155057.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 Mar 26 07:18:13 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22684 for ; Wed, 26 Mar 2003 07:18:13 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 83937536D4; Wed, 26 Mar 2003 07:20:04 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id A8F135369B for ; Wed, 26 Mar 2003 07:19:18 -0500 (EST) Received: (qmail 58860 invoked by uid 3269); 26 Mar 2003 12:19:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 58857 invoked from network); 26 Mar 2003 12:19:18 -0000 Received: from odin.ietf.org (HELO ietf.org) (132.151.1.176) by klesh.pair.com with SMTP; 26 Mar 2003 12:19:18 -0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22638; Wed, 26 Mar 2003 07:16:56 -0500 (EST) Message-Id: <200303261216.HAA22638@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-00.txt Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 07:16:56 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multicast Security Working Group of the IETF. Title : The Multicast Security (MSEC) Architecture Author(s) : T. Hardjono, B. Weis Filename : draft-ietf-msec-arch-00.txt Pages : 21 Date : 2003-3-25 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-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-msec-arch-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-msec-arch-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-3-25141441.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-msec-arch-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-msec-arch-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-3-25141441.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 Mar 26 13:49:08 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06993 for ; Wed, 26 Mar 2003 13:49:08 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 9170C537E2; Wed, 26 Mar 2003 13:48:14 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 9F45153536 for ; Wed, 26 Mar 2003 13:46:37 -0500 (EST) Received: (qmail 18150 invoked by uid 3269); 26 Mar 2003 18:46:37 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 18147 invoked from network); 26 Mar 2003 18:46:37 -0000 Received: from sj-core-5.cisco.com (171.71.177.238) by klesh.pair.com with SMTP; 26 Mar 2003 18:46:37 -0000 Received: from cisco.com ([128.107.176.94]) by sj-core-5.cisco.com (8.12.6/8.12.6) with ESMTP id h2QIkYHp001489 for ; Wed, 26 Mar 2003 10:46:35 -0800 (PST) Message-ID: <3E81F58A.723C7CAE@cisco.com> From: Brian Weis X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: msec@securemulticast.org Subject: Re: [MSEC] I-D ACTION:draft-ietf-msec-arch-00.txt References: <200303261216.HAA22638@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Wed, 26 Mar 2003 10:46:34 -0800 Content-Transfer-Encoding: 7bit This draft was presented at the IETF 55 in Atlanta, but there was a delay in getting it submitted to IETF. If you have any comments, please post them to the list or send them to the authors. We'll be creating a -01 version with minor updates soon. Thanks, Brian Internet-Drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Multicast Security Working Group of the IETF. > > Title : The Multicast Security (MSEC) Architecture > Author(s) : T. Hardjono, B. Weis > Filename : draft-ietf-msec-arch-00.txt > Pages : 21 > Date : 2003-3-25 > > 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-00.txt > > To remove yourself from the IETF Announcement list, send a message to > ietf-announce-request with the word unsubscribe in the body of the message. > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-ietf-msec-arch-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-msec-arch-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. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <2003-3-25141441.I-D@ietf.org> -- 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 Sat Mar 29 04:02:35 2003 Received: from pairlist.net (pairlist.net [216.92.1.92]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17236 for ; Sat, 29 Mar 2003 04:02:34 -0500 (EST) Received: from pairlist.net (localhost.pair.com [127.0.0.1]) by pairlist.net (Postfix) with ESMTP id 7A93F536E6; Sat, 29 Mar 2003 04:04:16 -0500 (EST) Delivered-To: msec@pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by pairlist.net (Postfix) with SMTP id 45ED6535CE for ; Sat, 29 Mar 2003 04:02:29 -0500 (EST) Received: (qmail 74132 invoked by uid 3269); 29 Mar 2003 09:02:29 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 74129 invoked from network); 29 Mar 2003 09:02:27 -0000 Received: from unknown (HELO itsky.com.cn) (211.153.20.96) by klesh.pair.com with SMTP; 29 Mar 2003 09:02:27 -0000 Received: (smail 12987 invoked by uid 511); 29 Mar 2003 07:59:31 -0000 Received: from unknown (HELO lion) (free@61.48.8.161) by 0 with SMTP; 29 Mar 2003 07:59:31 -0000 From: "zen" To: "msec@securemulticast.org" Cc: "gsec@lists.tislabs.com" X-mailer: Foxmail 4.2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 7bit Message-Id: <20030329090229.45ED6535CE@pairlist.net> Subject: [MSEC] a question about UMAC Sender: msec-admin@securemulticast.org Errors-To: msec-admin@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.0 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF Multicast Security (MSEC) WG list List-Unsubscribe: , List-Archive: Date: Sat, 29 Mar 2003 17:6:42 +0800 Content-Transfer-Encoding: 7bit Hi,folks, Who know about written by J.Black and H.Krawczyk? In the last part of this paper-Directions,they said: "An interesting possibility is to restructure UMAC so that a receiver can verify a tag to various forgery probabilities|e.g., changing UMAC-MMX-60 to allow tags to be verified, at increasing cost, to forging probabilities of ...Such a feature is particularly attractive for authenticating broadcasts to receivers of different security policies or computational capabilities." What is it mean? It can be used in multicast for authentication? How to restructure UMAC for it? Where is the reference on it? If you know it ,tell me.Thank you very much. I hope to use it in my multicast research work. Best, Zen _______________________________________________ msec mailing list msec@securemulticast.org http://www.pairlist.net/mailman/listinfo/msec