From msec-bounces@securemulticast.org Sun Jul 02 04:36:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwxRf-0004IN-BF for msec-archive@lists.ietf.org; Sun, 02 Jul 2006 04:36:47 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwxRe-0001An-3p for msec-archive@lists.ietf.org; Sun, 02 Jul 2006 04:36:47 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C94312C192; Sun, 2 Jul 2006 04:36:43 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 7EDC12C108 for ; Sun, 2 Jul 2006 04:36:42 -0400 (EDT) Received: (qmail 51075 invoked by uid 3269); 2 Jul 2006 08:36:41 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 51066 invoked from network); 2 Jul 2006 08:36:41 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Jul 2006 08:36:41 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id E946268365 for ; Sun, 2 Jul 2006 04:36:40 -0400 (EDT) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k628ab5F011920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2006 01:36:38 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-28.qualcomm.com [10.50.76.28]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k628aaAZ010897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Jul 2006 01:36:37 -0700 (PDT) Message-Id: <7.0.1.0.2.20060702012529.05dc84a8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 02 Jul 2006 01:36:28 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@csail.mit.edu Subject: [MSEC] MSEC agenda (draft proposal) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Status: O Folks, Taking all factors into consideration, I am proposing the following agenda. Please let us know if you have comments or suggestions. I realize that I am behind on writing some reviews and responses to emails; I will try and get to that next week! Thanks for your patience. regards, Lakshminath MSEC Agenda at IETF-66, Montreal (First draft): * MSEC Working Group Status: 10 minutes (Ran and I will request that all the editors/authors send a 1 page summary of their drafts' status which we can present to the group). * Discussion on Cryptographic Algorithm Agility and related updates: 10 minutes GDOI Update is a subtopic here. And we need the analyses for other MSEC protocols finished/discussed at this meeting. * MSEC and IPsec work: 10 minutes MSEC-IPsec extensions * MIKEY related updates/discussion: 15 minutes MIKEY applicability Discussion on further MIKEY work * New topics: 15 minutes RMT security work proposal and its impact on MSEC work Composite groups _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Jul 02 04:43:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwxYM-0004SK-50 for msec-archive@lists.ietf.org; Sun, 02 Jul 2006 04:43:42 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwxYK-00037m-Ry for msec-archive@lists.ietf.org; Sun, 02 Jul 2006 04:43:42 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id A7B182C1CD; Sun, 2 Jul 2006 04:43:40 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id 5C1602C108 for ; Sun, 2 Jul 2006 04:43:38 -0400 (EDT) Received: (qmail 52060 invoked by uid 3269); 2 Jul 2006 08:43:38 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52057 invoked from network); 2 Jul 2006 08:43:38 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 2 Jul 2006 08:43:38 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 10811683A8 for ; Sun, 2 Jul 2006 04:43:37 -0400 (EDT) Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k628hZlw012439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 2 Jul 2006 01:43:36 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-28.qualcomm.com [10.50.76.28]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k628hX8q011815 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Jul 2006 01:43:34 -0700 (PDT) Message-Id: <7.0.1.0.2.20060702014250.047d29c0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 02 Jul 2006 01:43:29 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Subject: Re: [MSEC] MSEC agenda (draft proposal) In-Reply-To: <7.0.1.0.2.20060702012529.05dc84a8@qualcomm.com> References: <7.0.1.0.2.20060702012529.05dc84a8@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@csail.mit.edu X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Status: O Here is a reference link for the RMT related topic in the proposed agenda: http://www1.ietf.org/mail-archive/web/rmt/current/msg00737.html cheers, Lakshminath At 01:36 AM 7/2/2006, Lakshminath Dondeti wrote: >Folks, > >Taking all factors into consideration, I am proposing the following >agenda. Please let us know if you have comments or suggestions. > >I realize that I am behind on writing some reviews and responses to >emails; I will try and get to that next week! Thanks for your patience. > >regards, >Lakshminath > >MSEC Agenda at IETF-66, Montreal (First draft): > > >* MSEC Working Group Status: 10 minutes > >(Ran and I will request that all the editors/authors send a 1 page >summary of their drafts' status which we can present to the group). > >* Discussion on Cryptographic Algorithm Agility and related >updates: 10 minutes > >GDOI Update is a subtopic here. >And we need the analyses for other MSEC protocols finished/discussed >at this meeting. > >* MSEC and IPsec work: 10 minutes > >MSEC-IPsec extensions > >* MIKEY related updates/discussion: 15 minutes > >MIKEY applicability >Discussion on further MIKEY work > >* New topics: 15 minutes > >RMT security work proposal and its impact on MSEC work >Composite groups > >_______________________________________________ >msec mailing list >msec@securemulticast.org >http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jul 03 15:26:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxU48-0003D9-7s for msec-archive@lists.ietf.org; Mon, 03 Jul 2006 15:26:40 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxU46-0000Y6-UX for msec-archive@lists.ietf.org; Mon, 03 Jul 2006 15:26:40 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 880BE2C97E; Mon, 3 Jul 2006 15:26:38 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id B4C5E2C928 for ; Mon, 3 Jul 2006 15:26:36 -0400 (EDT) Received: (qmail 42640 invoked by uid 3269); 3 Jul 2006 18:19:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 42636 invoked from network); 3 Jul 2006 18:19:08 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 3 Jul 2006 18:19:08 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id 29DF3E9DC4 for ; Mon, 3 Jul 2006 14:19:08 -0400 (EDT) Received: from web31814.mail.mud.yahoo.com (web31814.mail.mud.yahoo.com [68.142.206.167]) by mailwash15.pair.com (Postfix) with SMTP id DBBBCE9DBD for ; Mon, 3 Jul 2006 14:19:07 -0400 (EDT) Received: (qmail 34939 invoked by uid 60001); 3 Jul 2006 18:19:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=POfStV7QxJUhwtPi3kqbEcKffE4bhNN6TAy9F3oHlXtftpshy2+QDIXS4KUAfBEZbN6ufd2iTjtT5gs6wcDl2vYjtYFtzwFUuKg843JAOWztfFjk3JiLB2n6LZCQRIy1GzhpiUkCDIIpzHcJnT9ydVpoz6lg261EWdt+FZOtTBo= ; Message-ID: <20060703181907.34937.qmail@web31814.mail.mud.yahoo.com> Received: from [70.103.105.27] by web31814.mail.mud.yahoo.com via HTTP; Mon, 03 Jul 2006 11:19:07 PDT Date: Mon, 3 Jul 2006 11:19:07 -0700 (PDT) From: Thomas Hardjono To: MSEC MSEC MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Subject: [MSEC] Testing - pls ignore X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Status: O Testing - pls ignore _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From nobody@gd.solo10.com Mon Jul 03 20:16:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxYaM-0007C5-U6 for msec-archive@ietf.org; Mon, 03 Jul 2006 20:16:15 -0400 Received: from gd.solo10.com ([69.57.142.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxYaK-0006Cj-GX for msec-archive@ietf.org; Mon, 03 Jul 2006 20:16:14 -0400 Received: from nobody by gd.solo10.com with local (Exim 4.52) id 1FxYaI-0001dJ-5i for msec-archive@ietf.org; Tue, 04 Jul 2006 02:16:10 +0200 To: msec-archive@ietf.org Subject: Reminder: Confirm Your Credit or Debit Card Content-Type: text/html; charset=us-ascii From: PayPal Reply-to: PayPal Content-Transfer-Encoding: 7bit X-Accept-Language: en-us, en Message-Id: Date: Tue, 04 Jul 2006 02:16:10 +0200 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gd.solo10.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [99 504] / [47 12] X-AntiAbuse: Sender Address Domain - gd.solo10.com X-Source: X-Source-Args: /usr/local/apache/bin/httpd -DSSL X-Source-Dir: nature-vip.com:/public_html/tienda/images X-Spam-Score: 4.6 (++++) X-Scan-Signature: c2e58d9873012c90703822e287241385 Status: O
PayPal


Reminder: Confirm Your Credit or Debit Card

Dear Customer,

This is a reminder that we need you to confirm your Credit or Debit Card.

PayPal will never reveal any of your financial information. From industry-leading security to extensive protection programs, PayPal is always working to safeguard you and your account. Only you can initiate transactions using your bank account, PayPal will remind you via email whenever there is a fund transfer from your account.


How To Confirm Your Credit or Debit Card

PayPal has made two small deposits into the bank account you registered. These deposits should appear on your Account Statement.

Log in to your PayPal account and enter the exact financial information required.

Why Confirm Your Credit or Debit Card?

It increases security
When you enter your exact financial information, you confirm that you are the owner of this bank account. This is because only you as the owner would have access to the exact amounts of the 2 deposits PayPal sent. This process increases the safety of the entire PayPal payments network.
Your PayPal account will become verified
Your PayPal account becomes verified once you confirm your financial information. With a verified account, there is no limit on the amount of money you can send through PayPal when you choose to make these payments using funds from your bank account.

When you confirm your financial information:
  • You will improve your reputation by letting others know you're a confirmed, Verfied member of the PayPal community
  • Your sending limit will be removed
  • You will be able to fund purchases directly from your checking or savings account, in addition to using credit cards
  • You will be able to add funds to your PayPal account directly from your bank account
  • You will be able to send money to friends, family, and PayPal Personal Account holders
From msec-bounces@securemulticast.org Tue Jul 04 11:04:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxmSF-0000bA-P9 for msec-archive@lists.ietf.org; Tue, 04 Jul 2006 11:04:47 -0400 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxmSD-0001wT-GA for msec-archive@lists.ietf.org; Tue, 04 Jul 2006 11:04:47 -0400 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 289062C8AA; Tue, 4 Jul 2006 11:04:45 -0400 (EDT) X-Original-To: msec@lists6.securemulticast.org Delivered-To: msec@six.pairlist.net Received: from klesh.pair.com (klesh.pair.com [209.68.2.45]) by six.pairlist.net (Postfix) with SMTP id CF0F12C8EF for ; Tue, 4 Jul 2006 11:04:43 -0400 (EDT) Received: (qmail 78118 invoked by uid 3269); 4 Jul 2006 15:04:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 78115 invoked from network); 4 Jul 2006 15:04:43 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 4 Jul 2006 15:04:43 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id B2119E9D6B for ; Tue, 4 Jul 2006 11:04:43 -0400 (EDT) Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by mailwash15.pair.com (Postfix) with ESMTP id 53657E9D51 for ; Tue, 4 Jul 2006 11:04:43 -0400 (EDT) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k64F4eW9026846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Jul 2006 08:04:41 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-73.qualcomm.com [10.50.77.73]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k64F4cDf028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 4 Jul 2006 08:04:39 -0700 (PDT) Message-Id: <7.0.1.0.2.20060704080311.04724670@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 04 Jul 2006 08:04:43 -0700 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@csail.mit.edu Subject: [MSEC] MSEC Agenda is online X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Status: O Folks, The MSEC agenda is online: http://www3.ietf.org/proceedings/06jul/agenda/msec.htm. Please feel free to make suggestions for changes to the agenda. Ran and Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 07 17:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy1P-00058S-8w; Fri, 07 Jul 2006 17:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy1N-00058N-Uy for msec@ietf.org; Fri, 07 Jul 2006 17:37:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyy1M-0000rj-KT for msec@ietf.org; Fri, 07 Jul 2006 17:37:57 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k67LbsCf017897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Jul 2006 14:37:55 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k67LbqcW009541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Jul 2006 14:37:54 -0700 (PDT) Message-Id: <7.0.1.0.2.20060707143728.06ca9200@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Jul 2006 14:37:52 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [MSEC] Testing the new list ... please ignore ... Thanks. X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 07 17:38:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy1P-00058S-8w; Fri, 07 Jul 2006 17:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyy1N-00058N-Uy for msec@ietf.org; Fri, 07 Jul 2006 17:37:57 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyy1M-0000rj-KT for msec@ietf.org; Fri, 07 Jul 2006 17:37:57 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k67LbsCf017897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Jul 2006 14:37:55 -0700 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k67LbqcW009541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 7 Jul 2006 14:37:54 -0700 (PDT) Message-Id: <7.0.1.0.2.20060707143728.06ca9200@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Fri, 07 Jul 2006 14:37:52 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [MSEC] Testing the new list ... please ignore ... Thanks. X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Jul 08 07:22:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAsp-0007Dh-Qg; Sat, 08 Jul 2006 07:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAso-0007Db-SS for MSEC@ietf.org; Sat, 08 Jul 2006 07:21:58 -0400 Received: from mail.hust.edu.cn ([202.114.0.240]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FzAsn-0007g4-4G for MSEC@ietf.org; Sat, 08 Jul 2006 07:21:58 -0400 Received: from localhost (mail.hust.edu.cn [127.0.0.1]) by mail.hust.edu.cn (4U Message Server) with ESMTP id 02B9DEBC1C4 for ; Sat, 8 Jul 2006 19:31:59 +0800 (CST) Received: from wwd (unknown [211.69.197.122]) by mail.hust.edu.cn (4U Message Server) with ESMTP id C2422EBC1CF for ; Sat, 8 Jul 2006 19:31:57 +0800 (CST) Date: Sat, 8 Jul 2006 19:21:43 +0800 From: "=?gb2312?B?zfXOwLar?=" To: "MSEC" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060708113157.C2422EBC1CF@mail.hust.edu.cn> X-Virus-Scanned: by AMaViS 0.3.12 X-Spam-Score: 1.7 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [MSEC] (no subject) X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006272549==" Errors-To: msec-bounces@ietf.org --===============1006272549== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 anVzdCB0ZXN0ISBwbHMgaWdub3JlIQ0KoaGhoaGhoaGhoaGhd2FuZ3dkQG1haWwuaHVzdC5lZHUu Y24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNi0wNy0wOA0K --===============1006272549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1006272549==-- From msec-bounces@ietf.org Sat Jul 08 07:22:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAsp-0007Dh-Qg; Sat, 08 Jul 2006 07:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzAso-0007Db-SS for MSEC@ietf.org; Sat, 08 Jul 2006 07:21:58 -0400 Received: from mail.hust.edu.cn ([202.114.0.240]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FzAsn-0007g4-4G for MSEC@ietf.org; Sat, 08 Jul 2006 07:21:58 -0400 Received: from localhost (mail.hust.edu.cn [127.0.0.1]) by mail.hust.edu.cn (4U Message Server) with ESMTP id 02B9DEBC1C4 for ; Sat, 8 Jul 2006 19:31:59 +0800 (CST) Received: from wwd (unknown [211.69.197.122]) by mail.hust.edu.cn (4U Message Server) with ESMTP id C2422EBC1CF for ; Sat, 8 Jul 2006 19:31:57 +0800 (CST) Date: Sat, 8 Jul 2006 19:21:43 +0800 From: "=?gb2312?B?zfXOwLar?=" To: "MSEC" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20060708113157.C2422EBC1CF@mail.hust.edu.cn> X-Virus-Scanned: by AMaViS 0.3.12 X-Spam-Score: 1.7 (+) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Cc: Subject: [MSEC] (no subject) X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1006272549==" Errors-To: msec-bounces@ietf.org --===============1006272549== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 anVzdCB0ZXN0ISBwbHMgaWdub3JlIQ0KoaGhoaGhoaGhoaGhd2FuZ3dkQG1haWwuaHVzdC5lZHUu Y24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNi0wNy0wOA0K --===============1006272549== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1006272549==-- From msec-bounces@ietf.org Sun Jul 09 01:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS7o-0004qu-Nw; Sun, 09 Jul 2006 01:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS7n-0004qp-8R for msec@ietf.org; Sun, 09 Jul 2006 01:46:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS7l-0000qP-UN for msec@ietf.org; Sun, 09 Jul 2006 01:46:35 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k695kWc3002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Jul 2006 22:46:33 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k695kVhm026207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 8 Jul 2006 22:46:31 -0700 (PDT) Message-Id: <7.0.1.0.2.20060708223339.04a6ef10@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-Priority: 2 (High) Date: Sat, 08 Jul 2006 22:46:33 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MSEC] MSEC presentations (some of them) are online now ... X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, Thanks to Steffen, George and Vincent, we have some of the presentation for our Tuesday meeting online now. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Please review the slides, the agenda and send comments to the list. This is also a good time to post reviews of current drafts to the list. Some new work items are being proposed (please see the MSEC status slide set). Folks not attending the meeting are especially encouraged to chime in on those ASAP. Thanks in advance! cheers, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 01:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS7o-0004qu-Nw; Sun, 09 Jul 2006 01:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzS7n-0004qp-8R for msec@ietf.org; Sun, 09 Jul 2006 01:46:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzS7l-0000qP-UN for msec@ietf.org; Sun, 09 Jul 2006 01:46:35 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k695kWc3002153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Jul 2006 22:46:33 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k695kVhm026207 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 8 Jul 2006 22:46:31 -0700 (PDT) Message-Id: <7.0.1.0.2.20060708223339.04a6ef10@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-Priority: 2 (High) Date: Sat, 08 Jul 2006 22:46:33 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MSEC] MSEC presentations (some of them) are online now ... X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi all, Thanks to Steffen, George and Vincent, we have some of the presentation for our Tuesday meeting online now. https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Please review the slides, the agenda and send comments to the list. This is also a good time to post reviews of current drafts to the list. Some new work items are being proposed (please see the MSEC status slide set). Folks not attending the meeting are especially encouraged to chime in on those ASAP. Thanks in advance! cheers, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 01:49:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSAe-0008H2-K8; Sun, 09 Jul 2006 01:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSAd-0008Gx-Ry for msec@ietf.org; Sun, 09 Jul 2006 01:49:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzSAb-0001aW-Gz for msec@ietf.org; Sun, 09 Jul 2006 01:49:31 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k695nSX3029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Jul 2006 22:49:28 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k695nRuS026858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 8 Jul 2006 22:49:28 -0700 (PDT) Message-Id: <7.0.1.0.2.20060708224636.03ff3c68@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-Priority: 1 (Highest) Date: Sat, 08 Jul 2006 22:49:29 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Need 2 scribes X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, We need 2 or more people to take minutes for the MSEC meeting. It's for 1 hr and so it should be relatively painless. Without minute takers we cannot have a meeting, so please consider volunteering (The sooner the better). Thanks in advance! regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 01:49:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSAe-0008H2-K8; Sun, 09 Jul 2006 01:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzSAd-0008Gx-Ry for msec@ietf.org; Sun, 09 Jul 2006 01:49:31 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzSAb-0001aW-Gz for msec@ietf.org; Sun, 09 Jul 2006 01:49:31 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k695nSX3029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 8 Jul 2006 22:49:28 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k695nRuS026858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 8 Jul 2006 22:49:28 -0700 (PDT) Message-Id: <7.0.1.0.2.20060708224636.03ff3c68@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 X-Priority: 1 (Highest) Date: Sat, 08 Jul 2006 22:49:29 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Need 2 scribes X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, We need 2 or more people to take minutes for the MSEC meeting. It's for 1 hr and so it should be relatively painless. Without minute takers we cannot have a meeting, so please consider volunteering (The sooner the better). Thanks in advance! regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 03:11:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzTRe-0004Gx-HN; Sun, 09 Jul 2006 03:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzTRc-0004FN-RO for msec@ietf.org; Sun, 09 Jul 2006 03:11:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzTRb-0005Gx-BI for msec@ietf.org; Sun, 09 Jul 2006 03:11:08 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k697B54Q011268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Jul 2006 00:11:06 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k697B37r003616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 Jul 2006 00:11:04 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709000945.040fe718@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 00:11:17 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [MSEC] Modified Agenda and MSEC Status presentation posted X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, I rearranged things in the Agenda to focus on topics that need to be discussed. I moved the TESLA spec discussion to within the drafts' status discussion to allow more time for other topics. cheers, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 03:11:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzTRe-0004Gx-HN; Sun, 09 Jul 2006 03:11:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzTRc-0004FN-RO for msec@ietf.org; Sun, 09 Jul 2006 03:11:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzTRb-0005Gx-BI for msec@ietf.org; Sun, 09 Jul 2006 03:11:08 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k697B54Q011268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Jul 2006 00:11:06 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k697B37r003616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 Jul 2006 00:11:04 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709000945.040fe718@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 00:11:17 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [MSEC] Modified Agenda and MSEC Status presentation posted X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, I rearranged things in the Agenda to focus on topics that need to be discussed. I moved the TESLA spec discussion to within the drafts' status discussion to allow more time for other topics. cheers, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 05:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzVMG-0003F6-1C; Sun, 09 Jul 2006 05:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzVMD-0003F1-Pg for msec@ietf.org; Sun, 09 Jul 2006 05:13:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzVMC-0005Zu-F8 for msec@ietf.org; Sun, 09 Jul 2006 05:13:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k699DbCi023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Jul 2006 02:13:37 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k699DUHj014033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Jul 2006 02:13:31 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709020313.044b45f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 02:13:31 -0700 To: "'IETF-RTPSEC'" From: Lakshminath Dondeti In-Reply-To: <01c201c6a04b$f64de810$c6f0200a@amer.cisco.com> References: <01c201c6a04b$f64de810$c6f0200a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: msec@ietf.org, canetti@csail.mit.edu Subject: [MSEC] MIKEYv2 slides X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi folks, The RTPsec agenda is focused on the requirements and discussion on architectural issues in SRTP keying, and rightly so. Unfortunately, that leaves no time for discussion on new protocols. Among them is MIKEYv2, which I started working on, making some guesses on the requirements, expected to come out of the RTPsec work. One of the motivations is to see how MIKEY might look like if we started addressing the barriers for deployment of that protocol, while reusing the messages and payloads as much as possible. Another suggestion in redesigning MIKEY was to re-use SIGMA and ideas from the derivative IKEv2 and GKDP protocols, to support unicast as well as group key management. The work belongs in MSEC as much as it does in RTPsec. There will be a brief presentation and discussion at the MSEC meeting (Tuesday 1850-1950, Room 513B) on this. Below is a link to the first draft of the slides I am going to use. Please send reviews and questions so I might revise them to make them more informative. http://www3.ietf.org/proceedings/06jul/slides/msec-4.ppt Thanks in advance. regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 05:13:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzVMG-0003F6-1C; Sun, 09 Jul 2006 05:13:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzVMD-0003F1-Pg for msec@ietf.org; Sun, 09 Jul 2006 05:13:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzVMC-0005Zu-F8 for msec@ietf.org; Sun, 09 Jul 2006 05:13:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k699DbCi023772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Jul 2006 02:13:37 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-134.qualcomm.com [10.50.76.134]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k699DUHj014033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 9 Jul 2006 02:13:31 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709020313.044b45f0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 02:13:31 -0700 To: "'IETF-RTPSEC'" From: Lakshminath Dondeti In-Reply-To: <01c201c6a04b$f64de810$c6f0200a@amer.cisco.com> References: <01c201c6a04b$f64de810$c6f0200a@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: msec@ietf.org, canetti@csail.mit.edu Subject: [MSEC] MIKEYv2 slides X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi folks, The RTPsec agenda is focused on the requirements and discussion on architectural issues in SRTP keying, and rightly so. Unfortunately, that leaves no time for discussion on new protocols. Among them is MIKEYv2, which I started working on, making some guesses on the requirements, expected to come out of the RTPsec work. One of the motivations is to see how MIKEY might look like if we started addressing the barriers for deployment of that protocol, while reusing the messages and payloads as much as possible. Another suggestion in redesigning MIKEY was to re-use SIGMA and ideas from the derivative IKEv2 and GKDP protocols, to support unicast as well as group key management. The work belongs in MSEC as much as it does in RTPsec. There will be a brief presentation and discussion at the MSEC meeting (Tuesday 1850-1950, Room 513B) on this. Below is a link to the first draft of the slides I am going to use. Please send reviews and questions so I might revise them to make them more informative. http://www3.ietf.org/proceedings/06jul/slides/msec-4.ppt Thanks in advance. regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 22:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzlma-0005s0-TY; Sun, 09 Jul 2006 22:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzlmZ-0005rv-2E for msec@ietf.org; Sun, 09 Jul 2006 22:45:59 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzlmX-0007da-Nv for msec@ietf.org; Sun, 09 Jul 2006 22:45:59 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6A2juWQ006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Jul 2006 19:45:57 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-124.qualcomm.com [10.50.76.124]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6A2jpCN017433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 Jul 2006 19:45:55 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709194330.080cfc00@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 19:45:51 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Moved to the new list X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, You may have noticed that I have been posting to msec@ietf.org. We'll phase out msec@securemulticast.org pretty soon. Please use the new list for MSEC discussions. I will ask the Secretariat to update the MSEC WG page to reflect the changes. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sun Jul 09 22:46:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fzlma-0005s0-TY; Sun, 09 Jul 2006 22:46:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzlmZ-0005rv-2E for msec@ietf.org; Sun, 09 Jul 2006 22:45:59 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzlmX-0007da-Nv for msec@ietf.org; Sun, 09 Jul 2006 22:45:59 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6A2juWQ006031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sun, 9 Jul 2006 19:45:57 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-124.qualcomm.com [10.50.76.124]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6A2jpCN017433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 9 Jul 2006 19:45:55 -0700 (PDT) Message-Id: <7.0.1.0.2.20060709194330.080cfc00@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 09 Jul 2006 19:45:51 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Moved to the new list X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, You may have noticed that I have been posting to msec@ietf.org. We'll phase out msec@securemulticast.org pretty soon. Please use the new list for MSEC discussions. I will ask the Secretariat to update the MSEC WG page to reflect the changes. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 11 09:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ib5-0003xc-Bv; Tue, 11 Jul 2006 09:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ib4-0003xX-Rh for msec@ietf.org; Tue, 11 Jul 2006 09:48:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ib3-0008Li-H9 for msec@ietf.org; Tue, 11 Jul 2006 09:48:18 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6BDmGs0014487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 06:48:16 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-177.qualcomm.com [10.50.76.177]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6BDmEkP022089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Jul 2006 06:48:15 -0700 (PDT) Message-Id: <7.0.1.0.2.20060711064611.07405430@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Jul 2006 06:48:13 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Need scribe X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, I need a scribe. Without 2 volunteers to take minutes, we *cannot* have the meeting. BTW, the meeting materials page has been updated. regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 11 09:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ib5-0003xc-Bv; Tue, 11 Jul 2006 09:48:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ib4-0003xX-Rh for msec@ietf.org; Tue, 11 Jul 2006 09:48:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Ib3-0008Li-H9 for msec@ietf.org; Tue, 11 Jul 2006 09:48:18 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6BDmGs0014487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 11 Jul 2006 06:48:16 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-177.qualcomm.com [10.50.76.177]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6BDmEkP022089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Tue, 11 Jul 2006 06:48:15 -0700 (PDT) Message-Id: <7.0.1.0.2.20060711064611.07405430@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 11 Jul 2006 06:48:13 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [MSEC] Need scribe X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, I need a scribe. Without 2 volunteers to take minutes, we *cannot* have the meeting. BTW, the meeting materials page has been updated. regards, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 11 11:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ju2-0005PM-FR; Tue, 11 Jul 2006 11:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ju0-0005PH-LV for msec@ietf.org; Tue, 11 Jul 2006 11:11:56 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0Jty-00073V-Cj for msec@ietf.org; Tue, 11 Jul 2006 11:11:56 -0400 Received: (qmail 19919 invoked by uid 0); 11 Jul 2006 11:11:54 -0400 Received: from 209.123.118.212 by smtp-out2.oct (envelope-from , uid 0) with qmail-scanner-1.25 (clamdscan: 0.88.2/1523. f-prot: 4.6.6/3.16.14. Clear:RC:1(209.123.118.212):. Processed in 0.285244 secs); 11 Jul 2006 15:11:54 -0000 Received: from unknown (HELO webmail.nac.net) (209.123.118.212) by smtp-out2.oct.nac.net with SMTP; 11 Jul 2006 11:11:53 -0400 Received: from 132.219.22.180 (SquirrelMail authenticated user gmgross) by webmail.nac.net with HTTP; Tue, 11 Jul 2006 11:11:53 -0400 (EDT) Message-ID: <32844.132.219.22.180.1152630713.squirrel@webmail.nac.net> In-Reply-To: References: Date: Tue, 11 Jul 2006 11:11:53 -0400 (EDT) From: gmgross@nac.net To: H.Cruickshank@surrey.ac.uk User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: msec@ietf.org Subject: [MSEC] Re: MSEC draft - Composite Cryptographic Groups X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Haithem, > Hi George, > Here are some late comments about your draft > (draft-gross-msec-ipsec-composite-group-00): > > I feel the issue of Composite Cryptographic Groups real and has to be > addressed for large groups. For example in IP satellite networks, the > groups can very large and distributed over multiple administrative domains > with various security and general policy requirements. yes, security domain (or nation specific) specific policy is another motivation for composite groups. In the context of satellite, a spot beam antenna aimed at each sub-group could minimize the bandwidth consumed. > > I feel the current draft lack some details about the Composite Group > Distributor (CGD). For example, the location of the CGD: It can be > within the group speaker domain, or other subgroup domains. May be one or > two diagrams can clarify that. I will see what I can do in the way of adding some "typewriter/ASCII art" ;o) internal details of CGD are implementation dependent, I am not sure that would be advisible. OTOH, if the externally visible behavior needs more detail, I would welcome a suggestion from you about what you need clarified.... > > Another general multicast issue is that the group speaker sends to a > certain IP multicast address and the receivers subscribe to a different IP > multicast address (at least in IPsec transport mode), where the CGD make > the change of destination address. I wonder if there are any other > operational implications of such design. Other than the nuisance of making debugging abit more complex, it is hard to say. getting operational experience with composite groups is one of the reasons that I'm suggesting that it be placed on experimental RFC track. thx for the review! br, George P.S. note that MSEC is on a new mail list alias > > Haitham > > > > > ---- > Dr. Haitham S. Cruickshank > Lecturer > 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@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 11 11:12:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ju2-0005PM-FR; Tue, 11 Jul 2006 11:11:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Ju0-0005PH-LV for msec@ietf.org; Tue, 11 Jul 2006 11:11:56 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0Jty-00073V-Cj for msec@ietf.org; Tue, 11 Jul 2006 11:11:56 -0400 Received: (qmail 19919 invoked by uid 0); 11 Jul 2006 11:11:54 -0400 Received: from 209.123.118.212 by smtp-out2.oct (envelope-from , uid 0) with qmail-scanner-1.25 (clamdscan: 0.88.2/1523. f-prot: 4.6.6/3.16.14. Clear:RC:1(209.123.118.212):. Processed in 0.285244 secs); 11 Jul 2006 15:11:54 -0000 Received: from unknown (HELO webmail.nac.net) (209.123.118.212) by smtp-out2.oct.nac.net with SMTP; 11 Jul 2006 11:11:53 -0400 Received: from 132.219.22.180 (SquirrelMail authenticated user gmgross) by webmail.nac.net with HTTP; Tue, 11 Jul 2006 11:11:53 -0400 (EDT) Message-ID: <32844.132.219.22.180.1152630713.squirrel@webmail.nac.net> In-Reply-To: References: Date: Tue, 11 Jul 2006 11:11:53 -0400 (EDT) From: gmgross@nac.net To: H.Cruickshank@surrey.ac.uk User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: msec@ietf.org Subject: [MSEC] Re: MSEC draft - Composite Cryptographic Groups X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Haithem, > Hi George, > Here are some late comments about your draft > (draft-gross-msec-ipsec-composite-group-00): > > I feel the issue of Composite Cryptographic Groups real and has to be > addressed for large groups. For example in IP satellite networks, the > groups can very large and distributed over multiple administrative domains > with various security and general policy requirements. yes, security domain (or nation specific) specific policy is another motivation for composite groups. In the context of satellite, a spot beam antenna aimed at each sub-group could minimize the bandwidth consumed. > > I feel the current draft lack some details about the Composite Group > Distributor (CGD). For example, the location of the CGD: It can be > within the group speaker domain, or other subgroup domains. May be one or > two diagrams can clarify that. I will see what I can do in the way of adding some "typewriter/ASCII art" ;o) internal details of CGD are implementation dependent, I am not sure that would be advisible. OTOH, if the externally visible behavior needs more detail, I would welcome a suggestion from you about what you need clarified.... > > Another general multicast issue is that the group speaker sends to a > certain IP multicast address and the receivers subscribe to a different IP > multicast address (at least in IPsec transport mode), where the CGD make > the change of destination address. I wonder if there are any other > operational implications of such design. Other than the nuisance of making debugging abit more complex, it is hard to say. getting operational experience with composite groups is one of the reasons that I'm suggesting that it be placed on experimental RFC track. thx for the review! br, George P.S. note that MSEC is on a new mail list alias > > Haitham > > > > > ---- > Dr. Haitham S. Cruickshank > Lecturer > 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@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 14:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jfR-0001XS-Ey; Wed, 12 Jul 2006 14:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jfP-0001Wj-6r for msec@ietf.org; Wed, 12 Jul 2006 14:42:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jfN-0003Hk-SX for msec@ietf.org; Wed, 12 Jul 2006 14:42:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CIgUgc030059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 11:42:31 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CIgRdY024364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 11:42:29 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 11:42:23 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Russ Housley , canetti@csail.mit.edu Subject: [MSEC] TESLA documents X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, It looks like we need to think through the TESLA document organization a bit more: ++++++++++++ Option 1: RFC 4082 (with Errata) -- TESLA introduction RFC 4383 -- TESLA-SRTP Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is currently dead Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would be similar to 4383, but for IPsec. ++++++++++++++++ +++++++++++++ Option 2: Revise RFC 4082 -- TESLA Specification Keep RFC 4383 as is Write draft-ietf-msec-ipsec-tesla +++++++++++++++ I think Option 2 is most logical and has the fewest TESLA-related RFCs. I would like to hear others' opinions. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 14:42:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jfR-0001XS-Ey; Wed, 12 Jul 2006 14:42:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jfP-0001Wj-6r for msec@ietf.org; Wed, 12 Jul 2006 14:42:35 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jfN-0003Hk-SX for msec@ietf.org; Wed, 12 Jul 2006 14:42:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CIgUgc030059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 11:42:31 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CIgRdY024364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 11:42:29 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 11:42:23 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Russ Housley , canetti@csail.mit.edu Subject: [MSEC] TESLA documents X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, It looks like we need to think through the TESLA document organization a bit more: ++++++++++++ Option 1: RFC 4082 (with Errata) -- TESLA introduction RFC 4383 -- TESLA-SRTP Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is currently dead Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would be similar to 4383, but for IPsec. ++++++++++++++++ +++++++++++++ Option 2: Revise RFC 4082 -- TESLA Specification Keep RFC 4383 as is Write draft-ietf-msec-ipsec-tesla +++++++++++++++ I think Option 2 is most logical and has the fewest TESLA-related RFCs. I would like to hear others' opinions. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 14:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jru-0003eM-OW; Wed, 12 Jul 2006 14:55:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jrt-0003du-Gk for msec@ietf.org; Wed, 12 Jul 2006 14:55:29 -0400 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jrr-0005jn-7h for msec@ietf.org; Wed, 12 Jul 2006 14:55:29 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k6CItxff004152; Wed, 12 Jul 2006 14:56:03 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k6CItIh694096; Wed, 12 Jul 2006 14:55:18 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k6CItEK624270; Wed, 12 Jul 2006 14:55:18 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k6CIr51i015441; Wed, 12 Jul 2006 14:53:05 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k6CItEJ26864; Wed, 12 Jul 2006 14:55:14 -0400 Date: Wed, 12 Jul 2006 14:55:13 -0400 (EDT) From: canetti To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents In-Reply-To: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> Message-ID: References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org I agree. Need to add that 4082 is informational, while 4383 and the to-be tesla-ipsec are standards track. (actually, tesla-esp is a better name than tesla-ipsec.) Ran On Wed, 12 Jul 2006, Lakshminath Dondeti wrote: > Folks, > > It looks like we need to think through the TESLA document > organization a bit more: > > ++++++++++++ > Option 1: > > RFC 4082 (with Errata) -- TESLA introduction > > RFC 4383 -- TESLA-SRTP > > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is currently dead > > Write a new draft draft-ietf-msec-mesp (old expired draft) -- this > would be similar to 4383, but for IPsec. > ++++++++++++++++ > > +++++++++++++ > Option 2: > > Revise RFC 4082 -- TESLA Specification > > Keep RFC 4383 as is > > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ > > I think Option 2 is most logical and has the fewest TESLA-related > RFCs. I would like to hear others' opinions. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 14:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jru-0003eM-OW; Wed, 12 Jul 2006 14:55:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jrt-0003du-Gk for msec@ietf.org; Wed, 12 Jul 2006 14:55:29 -0400 Received: from igw2.watson.ibm.com ([129.34.20.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jrr-0005jn-7h for msec@ietf.org; Wed, 12 Jul 2006 14:55:29 -0400 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.13.1/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k6CItxff004152; Wed, 12 Jul 2006 14:56:03 -0400 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k6CItIh694096; Wed, 12 Jul 2006 14:55:18 -0400 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k6CItEK624270; Wed, 12 Jul 2006 14:55:18 -0400 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k6CIr51i015441; Wed, 12 Jul 2006 14:53:05 -0400 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k6CItEJ26864; Wed, 12 Jul 2006 14:55:14 -0400 Date: Wed, 12 Jul 2006 14:55:13 -0400 (EDT) From: canetti To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents In-Reply-To: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> Message-ID: References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org I agree. Need to add that 4082 is informational, while 4383 and the to-be tesla-ipsec are standards track. (actually, tesla-esp is a better name than tesla-ipsec.) Ran On Wed, 12 Jul 2006, Lakshminath Dondeti wrote: > Folks, > > It looks like we need to think through the TESLA document > organization a bit more: > > ++++++++++++ > Option 1: > > RFC 4082 (with Errata) -- TESLA introduction > > RFC 4383 -- TESLA-SRTP > > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is currently dead > > Write a new draft draft-ietf-msec-mesp (old expired draft) -- this > would be similar to 4383, but for IPsec. > ++++++++++++++++ > > +++++++++++++ > Option 2: > > Revise RFC 4082 -- TESLA Specification > > Keep RFC 4383 as is > > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ > > I think Option 2 is most logical and has the fewest TESLA-related > RFCs. I would like to hear others' opinions. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 15:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kdA-0000oM-Iq; Wed, 12 Jul 2006 15:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kd9-0000oE-Nb for msec@ietf.org; Wed, 12 Jul 2006 15:44:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jwX-0000nI-2K for msec@ietf.org; Wed, 12 Jul 2006 15:00:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0jlZ-0000SR-Iw for msec@ietf.org; Wed, 12 Jul 2006 14:48:59 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CImmgc031059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 11:48:49 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CImjEh019027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 11:48:46 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712114239.06d30570@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 11:48:41 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.5 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: canetti@csail.mit.edu Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, At the MSEC meeting yesterday, George's composite group work was well received, well really two supporting statements and no objections. I would like to hear from the list as to whether there is interest in co-authoring and/or reviewing that work. The proposal is to make it a MSEC work item in the Experimental track. Please let us know your opinions on this before July 26th, 2006. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 12 15:44:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kdA-0000oM-Iq; Wed, 12 Jul 2006 15:44:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kd9-0000oE-Nb for msec@ietf.org; Wed, 12 Jul 2006 15:44:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jwX-0000nI-2K for msec@ietf.org; Wed, 12 Jul 2006 15:00:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0jlZ-0000SR-Iw for msec@ietf.org; Wed, 12 Jul 2006 14:48:59 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CImmgc031059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 11:48:49 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-91.qualcomm.com [10.50.76.91]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CImjEh019027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 11:48:46 -0700 (PDT) Message-Id: <7.0.1.0.2.20060712114239.06d30570@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 12 Jul 2006 11:48:41 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.5 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: canetti@csail.mit.edu Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, At the MSEC meeting yesterday, George's composite group work was well received, well really two supporting statements and no objections. I would like to hear from the list as to whether there is interest in co-authoring and/or reviewing that work. The proposal is to make it a MSEC work item in the Experimental track. Please let us know your opinions on this before July 26th, 2006. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 09:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Wb-0002dn-9F; Thu, 13 Jul 2006 09:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zc2-0004lz-V3 for msec@ietf.org; Thu, 13 Jul 2006 07:44:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zc2-00087A-T0 for msec@ietf.org; Thu, 13 Jul 2006 07:44:10 -0400 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0zak-000567-5x for msec@ietf.org; Thu, 13 Jul 2006 07:42:52 -0400 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 12:42:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track Date: Thu, 13 Jul 2006 12:40:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track Thread-Index: Acal67DW9RXN4eIXR0yOCR4+77BIUwAhXyci From: To: , X-OriginalArrivalTime: 13 Jul 2006 11:42:46.0706 (UTC) FILETIME=[75F3B920:01C6A671] X-Spam-Score: -2.6 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-Mailman-Approved-At: Thu, 13 Jul 2006 09:46:40 -0400 Cc: canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507140053==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1507140053== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A671.75800EBB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A671.75800EBB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lakshminath and George, =20 I think this work is very interesting. I can co-author this draft, if = possible. =20 Haitham =20 ---- Dr. Haitham S. Cruickshank=20 Lecturer=20 Communications Centre for Communication Systems Research (CCSR)=20 School of Electronics, Computing and Mathematics=20 University of Surrey, Guildford, Surrey GU2 7XH, UK=20 =20 Tel: +44 1483 686007 (indirect 689844)=20 Fax: +44 1483 686011=20 e-mail: H.Cruickshank@surrey.ac.uk=20 http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20 ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wed 12/07/2006 19:48 To: msec@ietf.org Cc: canetti@csail.mit.edu Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group = as a WG item in the Exp track Folks, At the MSEC meeting yesterday, George's composite group work was well received, well really two supporting statements and no objections. I would like to hear from the list as to whether there is interest in co-authoring and/or reviewing that work. The proposal is to make it a MSEC work item in the Experimental track. Please let us know your opinions on this before July 26th, 2006. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec ------_=_NextPart_001_01C6A671.75800EBB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as = a WG item in the Exp track=0A= =0A= =0A=
=0A=
Hi Lakshminath =0A= and George,
=0A=
 
=0A=
I think this work is very interesting.  I can = co-author this =0A= draft, if possible.
=0A=
 
=0A=
Haitham
=0A=
 
=0A=
=0A=
=0A=
----
=0A=
Dr. Haitham S. =0A= Cruickshank
=0A=
Lecturer =0A=
=0A=
Communications =0A= Centre for Communication Systems Research (CCSR)
=0A=
School of =0A= Electronics, Computing and Mathematics
=0A=
University of =0A= Surrey, Guildford, =0A= Surrey GU2 7XH, =0A= UK
=0A=
 
=0A=
Tel: +44 1483 =0A= 686007 (indirect 689844)
=0A=
Fax: +44 1483 =0A= 686011
=0A=
e-mail: H.Cruickshank@surrey.ac.uk
=0A=
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ =0A=
=0A=

=0A=
=0A= From: Lakshminath Dondeti =0A= [mailto:ldondeti@qualcomm.com]
Sent: Wed 12/07/2006 =0A= 19:48
To: msec@ietf.org
Cc: =0A= canetti@csail.mit.edu
Subject: [MSEC] Consensus call: =0A= draft-gross-msec-ipsec-composite-group as a WG item in the Exp =0A= track

=0A=
=0A=

Folks,

At the MSEC meeting yesterday, George's = composite =0A= group work was well
received, well really two supporting statements = and no =0A= objections.  I
would like to hear from the list as to whether = there is =0A= interest in
co-authoring and/or reviewing that work.

The = proposal is =0A= to make it a MSEC work item in the Experimental
track.  Please = let us =0A= know your opinions on this before July 26th, =0A= 2006.

thanks,
Lakshminath


__________________________= _____________________
MSEC =0A= mailing list
MSEC@ietf.org
https://www1.ietf.or= g/mailman/listinfo/msec

=0A= =0A= =0A= ------_=_NextPart_001_01C6A671.75800EBB-- --===============1507140053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1507140053==-- From msec-bounces@ietf.org Thu Jul 13 09:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Wb-0002dn-9F; Thu, 13 Jul 2006 09:46:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zc2-0004lz-V3 for msec@ietf.org; Thu, 13 Jul 2006 07:44:10 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zc2-00087A-T0 for msec@ietf.org; Thu, 13 Jul 2006 07:44:10 -0400 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0zak-000567-5x for msec@ietf.org; Thu, 13 Jul 2006 07:42:52 -0400 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 12:42:46 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track Date: Thu, 13 Jul 2006 12:40:45 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track Thread-Index: Acal67DW9RXN4eIXR0yOCR4+77BIUwAhXyci From: To: , X-OriginalArrivalTime: 13 Jul 2006 11:42:46.0706 (UTC) FILETIME=[75F3B920:01C6A671] X-Spam-Score: -2.6 (--) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f X-Mailman-Approved-At: Thu, 13 Jul 2006 09:46:40 -0400 Cc: canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1507140053==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1507140053== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A671.75800EBB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A671.75800EBB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lakshminath and George, =20 I think this work is very interesting. I can co-author this draft, if = possible. =20 Haitham =20 ---- Dr. Haitham S. Cruickshank=20 Lecturer=20 Communications Centre for Communication Systems Research (CCSR)=20 School of Electronics, Computing and Mathematics=20 University of Surrey, Guildford, Surrey GU2 7XH, UK=20 =20 Tel: +44 1483 686007 (indirect 689844)=20 Fax: +44 1483 686011=20 e-mail: H.Cruickshank@surrey.ac.uk=20 http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20 ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wed 12/07/2006 19:48 To: msec@ietf.org Cc: canetti@csail.mit.edu Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group = as a WG item in the Exp track Folks, At the MSEC meeting yesterday, George's composite group work was well received, well really two supporting statements and no objections. I would like to hear from the list as to whether there is interest in co-authoring and/or reviewing that work. The proposal is to make it a MSEC work item in the Experimental track. Please let us know your opinions on this before July 26th, 2006. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec ------_=_NextPart_001_01C6A671.75800EBB Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as = a WG item in the Exp track=0A= =0A= =0A=
=0A=
Hi Lakshminath =0A= and George,
=0A=
 
=0A=
I think this work is very interesting.  I can = co-author this =0A= draft, if possible.
=0A=
 
=0A=
Haitham
=0A=
 
=0A=
=0A=
=0A=
----
=0A=
Dr. Haitham S. =0A= Cruickshank
=0A=
Lecturer =0A=
=0A=
Communications =0A= Centre for Communication Systems Research (CCSR)
=0A=
School of =0A= Electronics, Computing and Mathematics
=0A=
University of =0A= Surrey, Guildford, =0A= Surrey GU2 7XH, =0A= UK
=0A=
 
=0A=
Tel: +44 1483 =0A= 686007 (indirect 689844)
=0A=
Fax: +44 1483 =0A= 686011
=0A=
e-mail: H.Cruickshank@surrey.ac.uk
=0A=
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ =0A=
=0A=

=0A=
=0A= From: Lakshminath Dondeti =0A= [mailto:ldondeti@qualcomm.com]
Sent: Wed 12/07/2006 =0A= 19:48
To: msec@ietf.org
Cc: =0A= canetti@csail.mit.edu
Subject: [MSEC] Consensus call: =0A= draft-gross-msec-ipsec-composite-group as a WG item in the Exp =0A= track

=0A=
=0A=

Folks,

At the MSEC meeting yesterday, George's = composite =0A= group work was well
received, well really two supporting statements = and no =0A= objections.  I
would like to hear from the list as to whether = there is =0A= interest in
co-authoring and/or reviewing that work.

The = proposal is =0A= to make it a MSEC work item in the Experimental
track.  Please = let us =0A= know your opinions on this before July 26th, =0A= 2006.

thanks,
Lakshminath


__________________________= _____________________
MSEC =0A= mailing list
MSEC@ietf.org
https://www1.ietf.or= g/mailman/listinfo/msec

=0A= =0A= =0A= ------_=_NextPart_001_01C6A671.75800EBB-- --===============1507140053== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1507140053==-- From msec-bounces@ietf.org Thu Jul 13 11:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Eo-0003Hp-Iv; Thu, 13 Jul 2006 11:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Ee-00031Q-FN for msec@ietf.org; Thu, 13 Jul 2006 11:36:16 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G133P-0001NK-O7 for msec@ietf.org; Thu, 13 Jul 2006 11:24:41 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6DFOct8028298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 08:24:39 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-225.qualcomm.com [10.50.72.225]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6DFOapo007485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jul 2006 08:24:37 -0700 (PDT) Message-Id: <7.0.1.0.2.20060713071959.03dcdd10@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 13 Jul 2006 08:24:47 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [MSEC] MSEC summary ... for review X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org +++++++ MSEC is making progress at a decent clip, although we'd like to accelerate a bit to meet the milestones. IPsec extensions work is almost finished. A revision is expected in the next few weeks and we will finally be ready to send it to the IPsec list for review. One of the things that has been done is to remove the topic of Composite Groups which is not quite central to that effort of extending 4301 for multicast. MIKEY applicability work is in progress. There is cross pollination of MIKEY work between MSEC and RTPsec now and that's good. There is new work on Composite groups. The idea is that the secure group comprises two or more groups that support different cryptographic properties. We have a few folks who want to investigate this work and experiment with it. If we have consensus for it, we'll make that a MSEC WG item. RMT's NORM protocol security considerations are a priority for them. They are considering IPsec and designing a transport layer security encapsulation mechanism for NORM protocols. Data confidentiality and integrity are the requirements. We have a TESLA-NORM work item already. There is an exercise underway to figure out how best to address their requirement. The interested parties were asked to produce a problem statement and results of analysis of whether using IPsec or designing a transport layer security mechanism makes sense. Finally, we are working on finishing up the TESLA specification work. ++++++++ Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 11:36:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Eo-0003Hp-Iv; Thu, 13 Jul 2006 11:36:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G13Ee-00031Q-FN for msec@ietf.org; Thu, 13 Jul 2006 11:36:16 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G133P-0001NK-O7 for msec@ietf.org; Thu, 13 Jul 2006 11:24:41 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6DFOct8028298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 08:24:39 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-72-225.qualcomm.com [10.50.72.225]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6DFOapo007485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jul 2006 08:24:37 -0700 (PDT) Message-Id: <7.0.1.0.2.20060713071959.03dcdd10@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 13 Jul 2006 08:24:47 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [MSEC] MSEC summary ... for review X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org +++++++ MSEC is making progress at a decent clip, although we'd like to accelerate a bit to meet the milestones. IPsec extensions work is almost finished. A revision is expected in the next few weeks and we will finally be ready to send it to the IPsec list for review. One of the things that has been done is to remove the topic of Composite Groups which is not quite central to that effort of extending 4301 for multicast. MIKEY applicability work is in progress. There is cross pollination of MIKEY work between MSEC and RTPsec now and that's good. There is new work on Composite groups. The idea is that the secure group comprises two or more groups that support different cryptographic properties. We have a few folks who want to investigate this work and experiment with it. If we have consensus for it, we'll make that a MSEC WG item. RMT's NORM protocol security considerations are a priority for them. They are considering IPsec and designing a transport layer security encapsulation mechanism for NORM protocols. Data confidentiality and integrity are the requirements. We have a TESLA-NORM work item already. There is an exercise underway to figure out how best to address their requirement. The interested parties were asked to produce a problem statement and results of analysis of whether using IPsec or designing a transport layer security mechanism makes sense. Finally, we are working on finishing up the TESLA specification work. ++++++++ Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 13:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14jn-0006XK-12; Thu, 13 Jul 2006 13:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14jl-0006XF-5R for msec@ietf.org; Thu, 13 Jul 2006 13:12:29 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14jk-0007sH-PK for msec@ietf.org; Thu, 13 Jul 2006 13:12:29 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6DHCRtP020396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 10:12:27 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-56.qualcomm.com [10.50.76.56]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6DHCI6V009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jul 2006 10:12:25 -0700 (PDT) Message-Id: <7.0.1.0.2.20060713100955.06ebb008@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 13 Jul 2006 10:11:44 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [MSEC] Draft minutes, thanks to Brian Weis X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, Please review the minutes below. I plan to upload them on Monday evening Pacific TZ. Thanks again to Brian Weis for taking the minutes. regards, Lakshminath ++++++++++ Laksminath presented an overview of the working group status, including the list of RFCs recently published and work in progress. Russ asked about the TESLA document organization. There used to be seperate documents describing the TELSA protocol description, and one applying it to IPsec, whereas now they have been combined in one draft. He suggested returning to the original organization, where the TELSA protocol description is an Informational document, and the IPsec one a Standards Track document. The hash function agility analysis has not completed for all MSEC protocols, in particular MIKEY and GSAKMP. Vincent Roca presented a draft "The Use of TESLA in the ALC and NORM Protocols" (draft-ietf-msec-tesla-for-alc-norm-00.txt). This version aims to be a full TELSA building block in the RMT framewrok, and it proposed new message formats. George Gross wondered if the this document could share a generic header with some other work, and there will be a discussion on the working group mailing list on this topic. Sheela Rowles presented the draft "Updates to the Group Domain of Interpretation (GDOI)" (draft-ietf-msec-gdoi-update-00.txt). In Dallas it was pointed out that we used he key wrong, and David Mcgrew pointed out a better way. Now if PFS is used in GDOI, the draft uses a NIST derived key derivation function to choose a key from the Diffie-Hellman shared secret. Also, more text was added regarding authorization. This is to mitigate the Meadow/Pavolvic attack. The mitigation method differes whether or not the GDOI CERT/POP payloads are used. She also mentioned in that the authors are planning to incorporate a proposed change to the POP hash computation that stops the attack altogether. However, the authorization text is still useful guidance. Stephan Fries presented the draft "On the applicability of various MIKEY modes and extensions" (draft-ietf-msec-mikey-applicability-01.txt). This draft describes the existing options for key management given in MIKEY as well as extensions to MIKEY. There have been two versions since last IETF. The authors feel that the draft is ready for working group last call. Lakshminath asked for more use cases to be included in the document (e.g., conferencing scenarios, particularyly XCON working group scenarios). Lakshminath presented a proposal for using MIKEY to at yesterdays RTPSEC BOF. There were a number of decision points made in the BOF, but requirements are ongoing. Until they are complete there is no point in adding more details to the proposal, but he did describe it a set of slides to give a flavor of what MIKEY in what media path would look like, see the slides. He also mentioned that RTPSEC said that group keying was not its first priority because voice conferencing is usaully point-to-point. Brian Weis presented "Multicast Extensions to the Security Architecture for the Internet Protocol (draft-ietf-msec-ipsec-extensions-02.txt). There were some minor terminology changes, and some changes based on comments posted to the mailing list. The next version will be sent to the IPsec mailing list for comments, with a following draft expected to go go to working group last call. George Gross presented his individual submission "Multicast IP Security Composite Cryptographic Groups" (draft-gross-msec-ipsec-composite-group-00.txt). This work was extracted from the multicast IPsec extensions draft, and it describes the problem of an IP multicast stream being needing to be sent to different sub-groups of receivers, where each sub-group has a unique IPsec policy. For example, if two sets of recievers cannot support the same cryptographic algorithms but need to receive the same data. George asked the MSEC working group to take this on, with the target being published as an Experimental protocol. Both Lakshminath and Brian agreed. George Gross also discussed some RMT working group security work and its impact on MSEC protocols. Several RMT protocol building blocks are approaching final standardization phase but still need to find answers for seom DoS and message alteration issues. _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 13:12:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14jn-0006XK-12; Thu, 13 Jul 2006 13:12:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G14jl-0006XF-5R for msec@ietf.org; Thu, 13 Jul 2006 13:12:29 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G14jk-0007sH-PK for msec@ietf.org; Thu, 13 Jul 2006 13:12:29 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6DHCRtP020396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jul 2006 10:12:27 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-56.qualcomm.com [10.50.76.56]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6DHCI6V009168 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jul 2006 10:12:25 -0700 (PDT) Message-Id: <7.0.1.0.2.20060713100955.06ebb008@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Thu, 13 Jul 2006 10:11:44 -0700 To: msec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [MSEC] Draft minutes, thanks to Brian Weis X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Folks, Please review the minutes below. I plan to upload them on Monday evening Pacific TZ. Thanks again to Brian Weis for taking the minutes. regards, Lakshminath ++++++++++ Laksminath presented an overview of the working group status, including the list of RFCs recently published and work in progress. Russ asked about the TESLA document organization. There used to be seperate documents describing the TELSA protocol description, and one applying it to IPsec, whereas now they have been combined in one draft. He suggested returning to the original organization, where the TELSA protocol description is an Informational document, and the IPsec one a Standards Track document. The hash function agility analysis has not completed for all MSEC protocols, in particular MIKEY and GSAKMP. Vincent Roca presented a draft "The Use of TESLA in the ALC and NORM Protocols" (draft-ietf-msec-tesla-for-alc-norm-00.txt). This version aims to be a full TELSA building block in the RMT framewrok, and it proposed new message formats. George Gross wondered if the this document could share a generic header with some other work, and there will be a discussion on the working group mailing list on this topic. Sheela Rowles presented the draft "Updates to the Group Domain of Interpretation (GDOI)" (draft-ietf-msec-gdoi-update-00.txt). In Dallas it was pointed out that we used he key wrong, and David Mcgrew pointed out a better way. Now if PFS is used in GDOI, the draft uses a NIST derived key derivation function to choose a key from the Diffie-Hellman shared secret. Also, more text was added regarding authorization. This is to mitigate the Meadow/Pavolvic attack. The mitigation method differes whether or not the GDOI CERT/POP payloads are used. She also mentioned in that the authors are planning to incorporate a proposed change to the POP hash computation that stops the attack altogether. However, the authorization text is still useful guidance. Stephan Fries presented the draft "On the applicability of various MIKEY modes and extensions" (draft-ietf-msec-mikey-applicability-01.txt). This draft describes the existing options for key management given in MIKEY as well as extensions to MIKEY. There have been two versions since last IETF. The authors feel that the draft is ready for working group last call. Lakshminath asked for more use cases to be included in the document (e.g., conferencing scenarios, particularyly XCON working group scenarios). Lakshminath presented a proposal for using MIKEY to at yesterdays RTPSEC BOF. There were a number of decision points made in the BOF, but requirements are ongoing. Until they are complete there is no point in adding more details to the proposal, but he did describe it a set of slides to give a flavor of what MIKEY in what media path would look like, see the slides. He also mentioned that RTPSEC said that group keying was not its first priority because voice conferencing is usaully point-to-point. Brian Weis presented "Multicast Extensions to the Security Architecture for the Internet Protocol (draft-ietf-msec-ipsec-extensions-02.txt). There were some minor terminology changes, and some changes based on comments posted to the mailing list. The next version will be sent to the IPsec mailing list for comments, with a following draft expected to go go to working group last call. George Gross presented his individual submission "Multicast IP Security Composite Cryptographic Groups" (draft-gross-msec-ipsec-composite-group-00.txt). This work was extracted from the multicast IPsec extensions draft, and it describes the problem of an IP multicast stream being needing to be sent to different sub-groups of receivers, where each sub-group has a unique IPsec policy. For example, if two sets of recievers cannot support the same cryptographic algorithms but need to receive the same data. George asked the MSEC working group to take this on, with the target being published as an Experimental protocol. Both Lakshminath and Brian agreed. George Gross also discussed some RMT working group security work and its impact on MSEC protocols. Several RMT protocol building blocks are approaching final standardization phase but still need to find answers for seom DoS and message alteration issues. _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 21:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CUF-00009h-CF; Thu, 13 Jul 2006 21:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CUD-0008Rt-HN for msec@ietf.org; Thu, 13 Jul 2006 21:28:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1CUC-0002HD-7y for msec@ietf.org; Thu, 13 Jul 2006 21:28:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2006 18:28:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6E1StqO014165; Thu, 13 Jul 2006 18:28:55 -0700 Received: from [142.131.134.73] (sjc-vpn4-731.cisco.com [10.21.82.219]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6E1SsJi020198; Thu, 13 Jul 2006 18:28:54 -0700 (PDT) Message-ID: <44B6F360.7090106@cisco.com> Date: Thu, 13 Jul 2006 18:29:04 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1254; t=1152840535; x=1153704535; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:Re=3A=20[MSEC]=20TESLA=20documents; X=v=3Dcisco.com=3B=20h=3DJLetoO2tM52f+GBsqyhv8bB+vn8=3D; b=Xopt8mEAQ0r312ewZGB7TR8UzrnK5qw98nHNXkRiZEaN29h5t9P5LKnesU15B200LiJBYAid +aDwh/zksDOwR6TDxgYqjaNPyguGT0Bi/1RzQZ/ySnk9DMLBGSJMo2Xv; Authentication-Results: sj-dkim-4.cisco.com; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org I have no objection to option 2, as long as there is consensus that RFC 4082 is actually a definitive protocol definition. Brian Lakshminath Dondeti wrote: > Folks, > > It looks like we need to think through the TESLA document organization a > bit more: > > ++++++++++++ > Option 1: > > RFC 4082 (with Errata) -- TESLA introduction > > RFC 4383 -- TESLA-SRTP > > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is > currently dead > > Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would > be similar to 4383, but for IPsec. > ++++++++++++++++ > > +++++++++++++ > Option 2: > > Revise RFC 4082 -- TESLA Specification > > Keep RFC 4383 as is > > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ > > I think Option 2 is most logical and has the fewest TESLA-related RFCs. > I would like to hear others' opinions. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 13 21:29:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CUF-00009h-CF; Thu, 13 Jul 2006 21:28:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1CUD-0008Rt-HN for msec@ietf.org; Thu, 13 Jul 2006 21:28:57 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1CUC-0002HD-7y for msec@ietf.org; Thu, 13 Jul 2006 21:28:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2006 18:28:56 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6E1StqO014165; Thu, 13 Jul 2006 18:28:55 -0700 Received: from [142.131.134.73] (sjc-vpn4-731.cisco.com [10.21.82.219]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6E1SsJi020198; Thu, 13 Jul 2006 18:28:54 -0700 (PDT) Message-ID: <44B6F360.7090106@cisco.com> Date: Thu, 13 Jul 2006 18:29:04 -0700 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: a=rsa-sha1; q=dns; l=1254; t=1152840535; x=1153704535; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:Brian=20Weis=20 |Subject:Re=3A=20[MSEC]=20TESLA=20documents; X=v=3Dcisco.com=3B=20h=3DJLetoO2tM52f+GBsqyhv8bB+vn8=3D; b=Xopt8mEAQ0r312ewZGB7TR8UzrnK5qw98nHNXkRiZEaN29h5t9P5LKnesU15B200LiJBYAid +aDwh/zksDOwR6TDxgYqjaNPyguGT0Bi/1RzQZ/ySnk9DMLBGSJMo2Xv; Authentication-Results: sj-dkim-4.cisco.com; header.From=bew@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org I have no objection to option 2, as long as there is consensus that RFC 4082 is actually a definitive protocol definition. Brian Lakshminath Dondeti wrote: > Folks, > > It looks like we need to think through the TESLA document organization a > bit more: > > ++++++++++++ > Option 1: > > RFC 4082 (with Errata) -- TESLA introduction > > RFC 4383 -- TESLA-SRTP > > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is > currently dead > > Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would > be similar to 4383, but for IPsec. > ++++++++++++++++ > > +++++++++++++ > Option 2: > > Revise RFC 4082 -- TESLA Specification > > Keep RFC 4383 as is > > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ > > I think Option 2 is most logical and has the fewest TESLA-related RFCs. > I would like to hear others' opinions. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > -- Brian Weis Advanced Security Development, Security Technology Group, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Jul 15 11:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mV1-0003u7-0I; Sat, 15 Jul 2006 11:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mUz-0003tu-8O for msec@ietf.org; Sat, 15 Jul 2006 11:56:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mUx-0008BT-Tj for msec@ietf.org; Sat, 15 Jul 2006 11:56:09 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6FFu4na023432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2006 08:56:05 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-22.qualcomm.com [10.50.76.22]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6FFu2aW020008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Jul 2006 08:56:03 -0700 (PDT) Message-Id: <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 15 Jul 2006 08:56:03 -0700 To: Brian Weis From: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents In-Reply-To: <44B6F360.7090106@cisco.com> References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> <44B6F360.7090106@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org At 06:29 PM 7/13/2006, Brian Weis wrote: >I have no objection to option 2, as long as there is consensus that >RFC 4082 is actually a definitive protocol definition. Brian, The proposal is to revise 4082 to make it a protocol specification. regards, Lakshminath >Brian > >Lakshminath Dondeti wrote: >>Folks, >>It looks like we need to think through the TESLA document >>organization a bit more: >>++++++++++++ >>Option 1: >>RFC 4082 (with Errata) -- TESLA introduction >>RFC 4383 -- TESLA-SRTP >>Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is >>currently dead >>Write a new draft draft-ietf-msec-mesp (old expired draft) -- this >>would be similar to 4383, but for IPsec. >>++++++++++++++++ >>+++++++++++++ >>Option 2: >>Revise RFC 4082 -- TESLA Specification >>Keep RFC 4383 as is >>Write draft-ietf-msec-ipsec-tesla >>+++++++++++++++ >>I think Option 2 is most logical and has the fewest TESLA-related RFCs. >>I would like to hear others' opinions. >>thanks, >>Lakshminath >> >>_______________________________________________ >>MSEC mailing list >>MSEC@ietf.org >>https://www1.ietf.org/mailman/listinfo/msec > > >-- >Brian Weis >Advanced Security Development, Security Technology Group, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Jul 15 11:56:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mV1-0003u7-0I; Sat, 15 Jul 2006 11:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mUz-0003tu-8O for msec@ietf.org; Sat, 15 Jul 2006 11:56:09 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mUx-0008BT-Tj for msec@ietf.org; Sat, 15 Jul 2006 11:56:09 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6FFu4na023432 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 15 Jul 2006 08:56:05 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-76-22.qualcomm.com [10.50.76.22]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6FFu2aW020008 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 15 Jul 2006 08:56:03 -0700 (PDT) Message-Id: <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 15 Jul 2006 08:56:03 -0700 To: Brian Weis From: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents In-Reply-To: <44B6F360.7090106@cisco.com> References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> <44B6F360.7090106@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org At 06:29 PM 7/13/2006, Brian Weis wrote: >I have no objection to option 2, as long as there is consensus that >RFC 4082 is actually a definitive protocol definition. Brian, The proposal is to revise 4082 to make it a protocol specification. regards, Lakshminath >Brian > >Lakshminath Dondeti wrote: >>Folks, >>It looks like we need to think through the TESLA document >>organization a bit more: >>++++++++++++ >>Option 1: >>RFC 4082 (with Errata) -- TESLA introduction >>RFC 4383 -- TESLA-SRTP >>Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is >>currently dead >>Write a new draft draft-ietf-msec-mesp (old expired draft) -- this >>would be similar to 4383, but for IPsec. >>++++++++++++++++ >>+++++++++++++ >>Option 2: >>Revise RFC 4082 -- TESLA Specification >>Keep RFC 4383 as is >>Write draft-ietf-msec-ipsec-tesla >>+++++++++++++++ >>I think Option 2 is most logical and has the fewest TESLA-related RFCs. >>I would like to hear others' opinions. >>thanks, >>Lakshminath >> >>_______________________________________________ >>MSEC mailing list >>MSEC@ietf.org >>https://www1.ietf.org/mailman/listinfo/msec > > >-- >Brian Weis >Advanced Security Development, Security Technology Group, Cisco Systems >Telephone: +1 408 526 4796 >Email: bew@cisco.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 18 10:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r2f-0005Cb-Qu; Tue, 18 Jul 2006 10:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r2e-000535-Hi for msec@ietf.org; Tue, 18 Jul 2006 10:59:20 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2r2d-0005Fe-4y for msec@ietf.org; Tue, 18 Jul 2006 10:59:20 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k6IExAhA009687; Tue, 18 Jul 2006 16:59:10 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k6IEx90t011013; Tue, 18 Jul 2006 16:59:10 +0200 (MEST) Message-ID: <44BCF73E.3010209@inrialpes.fr> Date: Tue, 18 Jul 2006 16:59:10 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> <44B6F360.7090106@cisco.com> <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 18 Jul 2006 16:59:11 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Lakshminath and al, > The proposal is to revise 4082 to make it a protocol specification. In that case, do you plan to extend RFC 4082 significantly or will you keep it more or less as it is today (with clarifications/corrections when needed)? In particular, do you plan to specify with enough details the following mechanisms: - key chain switch (not mentioned at all); - indirect time synchronization mechanism and upper delay bound calculation (only general guidelines are provided); Will this specification also include the various possible packet formats or not (in general it's typically the kind of information expected from a spec)? I see we have some in the the oether ipsec-tesla I-D, but perhaps you'll move them back to the specification I-D? What are your plans and how generic do you want to keep the (revised RFC4082) specs? Anyway, since several features will be shared with our TESLA for ALC/NORM I-D, we definitively need to synchronize. I also guess that it's too early to comment draft-dondeti-msec-ipsec-tesla-00 (since you explained it was only a very preliminary version)... Tell me if I'm wrong. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 18 10:59:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r2f-0005Cb-Qu; Tue, 18 Jul 2006 10:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2r2e-000535-Hi for msec@ietf.org; Tue, 18 Jul 2006 10:59:20 -0400 Received: from mx-serv.inrialpes.fr ([194.199.18.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2r2d-0005Fe-4y for msec@ietf.org; Tue, 18 Jul 2006 10:59:20 -0400 Received: from dwimmerlaik.inrialpes.fr (dwimmerlaik.inrialpes.fr [194.199.18.72]) by mx-serv.inrialpes.fr (8.13.6/8.13.0) with ESMTP id k6IExAhA009687; Tue, 18 Jul 2006 16:59:10 +0200 (MEST) Received: from [194.199.24.100] (iseran.inrialpes.fr [194.199.24.100]) by dwimmerlaik.inrialpes.fr (8.13.6/8.11.3/ImagV2) with ESMTP id k6IEx90t011013; Tue, 18 Jul 2006 16:59:10 +0200 (MEST) Message-ID: <44BCF73E.3010209@inrialpes.fr> Date: Tue, 18 Jul 2006 16:59:10 +0200 From: Vincent Roca User-Agent: Thunderbird 1.5.0.4 (X11/20060516) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [MSEC] TESLA documents References: <7.0.1.0.2.20060712112435.06f84fc8@qualcomm.com> <44B6F360.7090106@cisco.com> <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> In-Reply-To: <7.0.1.0.2.20060715085307.06e6d9d8@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0.2 (mx-serv.inrialpes.fr [194.199.18.100]); Tue, 18 Jul 2006 16:59:11 +0200 (MEST) X-mx-serv-inrialpes-fr-MailScanner-Information: Please contact postmaster@inrialpes.fr for more information X-mx-serv-inrialpes-fr-MailScanner: Found to be clean X-mx-serv-inrialpes-fr-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=0, requis 6) X-mx-serv-inrialpes-fr-MailScanner-From: vincent.roca@inrialpes.fr X-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: msec@ietf.org, Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hello Lakshminath and al, > The proposal is to revise 4082 to make it a protocol specification. In that case, do you plan to extend RFC 4082 significantly or will you keep it more or less as it is today (with clarifications/corrections when needed)? In particular, do you plan to specify with enough details the following mechanisms: - key chain switch (not mentioned at all); - indirect time synchronization mechanism and upper delay bound calculation (only general guidelines are provided); Will this specification also include the various possible packet formats or not (in general it's typically the kind of information expected from a spec)? I see we have some in the the oether ipsec-tesla I-D, but perhaps you'll move them back to the specification I-D? What are your plans and how generic do you want to keep the (revised RFC4082) specs? Anyway, since several features will be shared with our TESLA for ALC/NORM I-D, we definitively need to synchronize. I also guess that it's too early to comment draft-dondeti-msec-ipsec-tesla-00 (since you explained it was only a very preliminary version)... Tell me if I'm wrong. Cheers, Vincent _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 18 17:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x2k-0001HB-J0; Tue, 18 Jul 2006 17:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Kil-0006He-NK for msec@ietf.org; Fri, 14 Jul 2006 06:16:31 -0400 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Kij-0002q4-62 for msec@ietf.org; Fri, 14 Jul 2006 06:16:31 -0400 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:15:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] TESLA documents Date: Fri, 14 Jul 2006 11:10:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] TESLA documents Thread-Index: Acal4zT/E+3aQBwtQ+252af+TiN6agBSpDIV From: To: , X-OriginalArrivalTime: 14 Jul 2006 10:15:01.0592 (UTC) FILETIME=[5E1CD580:01C6A72E] X-Spam-Score: 0.2 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Tue, 18 Jul 2006 17:23:49 -0400 Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1686435156==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1686435156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A72E.5DB010B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A72E.5DB010B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lakshminath, =20 It seems that option 2 is the best choice.=20 =20 Ideally the Tesla-introduction and Tesla-spec documents should = complement each other. =20 Haitham =20 ---- Dr. Haitham S. Cruickshank=20 Lecturer=20 Communications Centre for Communication Systems Research (CCSR)=20 School of Electronics, Computing and Mathematics=20 University of Surrey, Guildford, Surrey GU2 7XH, UK=20 =20 Tel: +44 1483 686007 (indirect 689844)=20 Fax: +44 1483 686011=20 e-mail: H.Cruickshank@surrey.ac.uk=20 http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20 ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wed 12/07/2006 19:42 To: msec@ietf.org Cc: Russ Housley; canetti@csail.mit.edu Subject: [MSEC] TESLA documents Folks, It looks like we need to think through the TESLA document organization a bit more: ++++++++++++ Option 1: RFC 4082 (with Errata) -- TESLA introduction RFC 4383 -- TESLA-SRTP Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is = currently dead Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would be similar to 4383, but for IPsec. ++++++++++++++++ +++++++++++++ Option 2: Revise RFC 4082 -- TESLA Specification Keep RFC 4383 as is Write draft-ietf-msec-ipsec-tesla +++++++++++++++ I think Option 2 is most logical and has the fewest TESLA-related RFCs. I would like to hear others' opinions. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec ------_=_NextPart_001_01C6A72E.5DB010B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [MSEC] TESLA documents=0A= =0A= =0A=
=0A=
Hi =0A= Lakshminath,
=0A=
 
=0A=
It seems that option 2 is the best choice.
=0A=
 
=0A=
Ideally the Tesla-introduction and Tesla-spec documents = should =0A= complement each other.
=0A=
 
=0A=
Haitham
=0A=
 
=0A=
=0A=
=0A=
----
=0A=
Dr. Haitham S. =0A= Cruickshank
=0A=
Lecturer =0A=
=0A=
Communications =0A= Centre for Communication Systems Research (CCSR)
=0A=
School of =0A= Electronics, Computing and Mathematics
=0A=
University of =0A= Surrey, Guildford, =0A= Surrey GU2 7XH, =0A= UK
=0A=
 
=0A=
Tel: +44 1483 =0A= 686007 (indirect 689844)
=0A=
Fax: +44 1483 =0A= 686011
=0A=
e-mail: H.Cruickshank@surrey.ac.uk
=0A=
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ =0A=
=0A=

=0A=
=0A= From: Lakshminath Dondeti =0A= [mailto:ldondeti@qualcomm.com]
Sent: Wed 12/07/2006 =0A= 19:42
To: msec@ietf.org
Cc: Russ Housley; =0A= canetti@csail.mit.edu
Subject: [MSEC] TESLA =0A= documents

=0A=
=0A=

Folks,

It looks like we need to think through = the TESLA =0A= document
organization a bit more:

++++++++++++
Option = 1:

RFC =0A= 4082 (with Errata)  --  TESLA introduction

RFC =0A= 4383           &nb= sp;         =0A= --  TESLA-SRTP

Revive draft-ietf-msec-tesla-spec (Proposed =0A= Standard)   which is currently dead

Write a new draft =0A= draft-ietf-msec-mesp (old expired draft) -- this
would be similar to = 4383, =0A= but for IPsec.
++++++++++++++++

+++++++++++++
Option =0A= 2:

Revise RFC 4082     --  TESLA =0A= Specification

Keep RFC 4383 as is

Write =0A= draft-ietf-msec-ipsec-tesla
+++++++++++++++

I think Option 2 = is most =0A= logical and has the fewest TESLA-related
RFCs.  I would like to = hear =0A= others' =0A= opinions.

thanks,
Lakshminath


______________________= _________________________
MSEC =0A= mailing list
MSEC@ietf.org
https://www1.ietf.or= g/mailman/listinfo/msec

=0A= =0A= =0A= ------_=_NextPart_001_01C6A72E.5DB010B8-- --===============1686435156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1686435156==-- From msec-bounces@ietf.org Tue Jul 18 17:23:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2x2k-0001HB-J0; Tue, 18 Jul 2006 17:23:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Kil-0006He-NK for msec@ietf.org; Fri, 14 Jul 2006 06:16:31 -0400 Received: from ads40.surrey.ac.uk ([131.227.102.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Kij-0002q4-62 for msec@ietf.org; Fri, 14 Jul 2006 06:16:31 -0400 Received: from EVS-EC1-NODE1.surrey.ac.uk ([131.227.102.136]) by ads40.surrey.ac.uk with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 11:15:01 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [MSEC] TESLA documents Date: Fri, 14 Jul 2006 11:10:46 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] TESLA documents Thread-Index: Acal4zT/E+3aQBwtQ+252af+TiN6agBSpDIV From: To: , X-OriginalArrivalTime: 14 Jul 2006 10:15:01.0592 (UTC) FILETIME=[5E1CD580:01C6A72E] X-Spam-Score: 0.2 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd X-Mailman-Approved-At: Tue, 18 Jul 2006 17:23:49 -0400 Cc: X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1686435156==" Errors-To: msec-bounces@ietf.org This is a multi-part message in MIME format. --===============1686435156== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A72E.5DB010B8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A72E.5DB010B8 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lakshminath, =20 It seems that option 2 is the best choice.=20 =20 Ideally the Tesla-introduction and Tesla-spec documents should = complement each other. =20 Haitham =20 ---- Dr. Haitham S. Cruickshank=20 Lecturer=20 Communications Centre for Communication Systems Research (CCSR)=20 School of Electronics, Computing and Mathematics=20 University of Surrey, Guildford, Surrey GU2 7XH, UK=20 =20 Tel: +44 1483 686007 (indirect 689844)=20 Fax: +44 1483 686011=20 e-mail: H.Cruickshank@surrey.ac.uk=20 http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/=20 ________________________________ From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] Sent: Wed 12/07/2006 19:42 To: msec@ietf.org Cc: Russ Housley; canetti@csail.mit.edu Subject: [MSEC] TESLA documents Folks, It looks like we need to think through the TESLA document organization a bit more: ++++++++++++ Option 1: RFC 4082 (with Errata) -- TESLA introduction RFC 4383 -- TESLA-SRTP Revive draft-ietf-msec-tesla-spec (Proposed Standard) which is = currently dead Write a new draft draft-ietf-msec-mesp (old expired draft) -- this would be similar to 4383, but for IPsec. ++++++++++++++++ +++++++++++++ Option 2: Revise RFC 4082 -- TESLA Specification Keep RFC 4383 as is Write draft-ietf-msec-ipsec-tesla +++++++++++++++ I think Option 2 is most logical and has the fewest TESLA-related RFCs. I would like to hear others' opinions. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec ------_=_NextPart_001_01C6A72E.5DB010B8 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= [MSEC] TESLA documents=0A= =0A= =0A=
=0A=
Hi =0A= Lakshminath,
=0A=
 
=0A=
It seems that option 2 is the best choice.
=0A=
 
=0A=
Ideally the Tesla-introduction and Tesla-spec documents = should =0A= complement each other.
=0A=
 
=0A=
Haitham
=0A=
 
=0A=
=0A=
=0A=
----
=0A=
Dr. Haitham S. =0A= Cruickshank
=0A=
Lecturer =0A=
=0A=
Communications =0A= Centre for Communication Systems Research (CCSR)
=0A=
School of =0A= Electronics, Computing and Mathematics
=0A=
University of =0A= Surrey, Guildford, =0A= Surrey GU2 7XH, =0A= UK
=0A=
 
=0A=
Tel: +44 1483 =0A= 686007 (indirect 689844)
=0A=
Fax: +44 1483 =0A= 686011
=0A=
e-mail: H.Cruickshank@surrey.ac.uk
=0A=
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ =0A=
=0A=

=0A=
=0A= From: Lakshminath Dondeti =0A= [mailto:ldondeti@qualcomm.com]
Sent: Wed 12/07/2006 =0A= 19:42
To: msec@ietf.org
Cc: Russ Housley; =0A= canetti@csail.mit.edu
Subject: [MSEC] TESLA =0A= documents

=0A=
=0A=

Folks,

It looks like we need to think through = the TESLA =0A= document
organization a bit more:

++++++++++++
Option = 1:

RFC =0A= 4082 (with Errata)  --  TESLA introduction

RFC =0A= 4383           &nb= sp;         =0A= --  TESLA-SRTP

Revive draft-ietf-msec-tesla-spec (Proposed =0A= Standard)   which is currently dead

Write a new draft =0A= draft-ietf-msec-mesp (old expired draft) -- this
would be similar to = 4383, =0A= but for IPsec.
++++++++++++++++

+++++++++++++
Option =0A= 2:

Revise RFC 4082     --  TESLA =0A= Specification

Keep RFC 4383 as is

Write =0A= draft-ietf-msec-ipsec-tesla
+++++++++++++++

I think Option 2 = is most =0A= logical and has the fewest TESLA-related
RFCs.  I would like to = hear =0A= others' =0A= opinions.

thanks,
Lakshminath


______________________= _________________________
MSEC =0A= mailing list
MSEC@ietf.org
https://www1.ietf.or= g/mailman/listinfo/msec

=0A= =0A= =0A= ------_=_NextPart_001_01C6A72E.5DB010B8-- --===============1686435156== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1686435156==-- From msec-bounces@ietf.org Wed Jul 19 12:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FJF-00084Z-BO; Wed, 19 Jul 2006 12:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FJE-00084R-TP for msec@ietf.org; Wed, 19 Jul 2006 12:54:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C7A-0002MU-Gz for msec@ietf.org; Wed, 19 Jul 2006 09:29:24 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Bs3-0003N1-Le for msec@ietf.org; Wed, 19 Jul 2006 09:13:49 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k6JDDejk017241; Wed, 19 Jul 2006 15:13:40 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k6JDDdgO019102; Wed, 19 Jul 2006 15:13:39 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:13:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] TESLA documents Date: Wed, 19 Jul 2006 15:13:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] TESLA documents thread-index: Acal4yZxSBcKnI3KRMStRAqrA18zmwFUTwdQ From: "Fries, Steffen" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 19 Jul 2006 13:13:39.0604 (UTC) FILETIME=[269C6D40:01C6AB35] X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Lakshminath, I would support option 2, assumed that the draft will be revised. As far as I can remember there was an issue, which needs to be corrected. At least, for the TESLA MIKEY Bootstrapping we included something in the 48 hours. Regards Steffen=20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Wednesday, July 12, 2006 8:42 PM > To: msec@ietf.org > Cc: Russ Housley; canetti@csail.mit.edu > Subject: [MSEC] TESLA documents >=20 > Folks, >=20 > It looks like we need to think through the TESLA document=20 > organization a bit more: >=20 > ++++++++++++ > Option 1: >=20 > RFC 4082 (with Errata) -- TESLA introduction >=20 > RFC 4383 -- TESLA-SRTP >=20 > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which=20 > is currently dead >=20 > Write a new draft draft-ietf-msec-mesp (old expired draft) --=20 > this would be similar to 4383, but for IPsec. > ++++++++++++++++ >=20 > +++++++++++++ > Option 2: >=20 > Revise RFC 4082 -- TESLA Specification >=20 > Keep RFC 4383 as is >=20 > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ >=20 > I think Option 2 is most logical and has the fewest TESLA-related=20 > RFCs. I would like to hear others' opinions. >=20 > thanks, > Lakshminath >=20 >=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec >=20 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 19 12:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FJF-00084Z-BO; Wed, 19 Jul 2006 12:54:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3FJE-00084R-TP for msec@ietf.org; Wed, 19 Jul 2006 12:54:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3C7A-0002MU-Gz for msec@ietf.org; Wed, 19 Jul 2006 09:29:24 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Bs3-0003N1-Le for msec@ietf.org; Wed, 19 Jul 2006 09:13:49 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k6JDDejk017241; Wed, 19 Jul 2006 15:13:40 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k6JDDdgO019102; Wed, 19 Jul 2006 15:13:39 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 19 Jul 2006 15:13:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] TESLA documents Date: Wed, 19 Jul 2006 15:13:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] TESLA documents thread-index: Acal4yZxSBcKnI3KRMStRAqrA18zmwFUTwdQ From: "Fries, Steffen" To: "Lakshminath Dondeti" , X-OriginalArrivalTime: 19 Jul 2006 13:13:39.0604 (UTC) FILETIME=[269C6D40:01C6AB35] X-Spam-Score: -2.6 (--) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: Russ Housley , canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Lakshminath, I would support option 2, assumed that the draft will be revised. As far as I can remember there was an issue, which needs to be corrected. At least, for the TESLA MIKEY Bootstrapping we included something in the 48 hours. Regards Steffen=20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Wednesday, July 12, 2006 8:42 PM > To: msec@ietf.org > Cc: Russ Housley; canetti@csail.mit.edu > Subject: [MSEC] TESLA documents >=20 > Folks, >=20 > It looks like we need to think through the TESLA document=20 > organization a bit more: >=20 > ++++++++++++ > Option 1: >=20 > RFC 4082 (with Errata) -- TESLA introduction >=20 > RFC 4383 -- TESLA-SRTP >=20 > Revive draft-ietf-msec-tesla-spec (Proposed Standard) which=20 > is currently dead >=20 > Write a new draft draft-ietf-msec-mesp (old expired draft) --=20 > this would be similar to 4383, but for IPsec. > ++++++++++++++++ >=20 > +++++++++++++ > Option 2: >=20 > Revise RFC 4082 -- TESLA Specification >=20 > Keep RFC 4383 as is >=20 > Write draft-ietf-msec-ipsec-tesla > +++++++++++++++ >=20 > I think Option 2 is most logical and has the fewest TESLA-related=20 > RFCs. I would like to hear others' opinions. >=20 > thanks, > Lakshminath >=20 >=20 > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec >=20 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 21 18:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G438e-0000wL-Fl; Fri, 21 Jul 2006 18:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G438d-0000uY-3D; Fri, 21 Jul 2006 18:06:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G438b-00012g-O5; Fri, 21 Jul 2006 18:06:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2006 15:06:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LM6PXg012385; Fri, 21 Jul 2006 15:06:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6LM6NK8023566; Fri, 21 Jul 2006 15:06:24 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jul 2006 15:05:53 -0700 Received: from irp-view6.cisco.com ([171.70.65.143]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 15:05:52 -0700 Date: Fri, 21 Jul 2006 15:05:52 -0700 (PDT) From: Mike McBride To: pim@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Jul 2006 22:05:52.0906 (UTC) FILETIME=[D52B1EA0:01C6AD11] DKIM-Signature: a=rsa-sha1; q=dns; l=390; t=1153519585; x=1154383585; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:Mike=20McBride=20 |Subject:[pim]=20draft-atwood-pim-sm-linklocal=20; X=v=3Dcisco.com=3B=20h=3DWbsM7rEjm0AOfcaNpT2xmvo9lbU=3D; b=k9RJwsiSgV2JRjsEgw85Uxhv7ORPaolugBhlO+Cjia8WwUk+dzTvwilnFEqTlkRWnfiFVvDw nKrvr4jSFHJiIdX1o8YIHycWLVgygo3P2w1YaGt9FDI8MGr/0+oFSdzJ; Authentication-Results: sj-dkim-3.cisco.com; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: msec@ietf.org Subject: [MSEC] [pim] draft-atwood-pim-sm-linklocal X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org draft-atwood-pim-sm-linklocal-01 was presented by Bill Atwood in our wg meeting last week. The authors are requesting this work become a wg item. It proposes securing the pim control plane beyond what is defined in the pim-sm spec. Please review the draft and provide opinions on adoption. http://www.ietf.org/internet-drafts/draft-atwood-pim-sm-linklocal-01.txt thanks, mike _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 21 18:07:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G438e-0000wL-Fl; Fri, 21 Jul 2006 18:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G438d-0000uY-3D; Fri, 21 Jul 2006 18:06:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G438b-00012g-O5; Fri, 21 Jul 2006 18:06:27 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2006 15:06:25 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6LM6PXg012385; Fri, 21 Jul 2006 15:06:25 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6LM6NK8023566; Fri, 21 Jul 2006 15:06:24 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Jul 2006 15:05:53 -0700 Received: from irp-view6.cisco.com ([171.70.65.143]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 15:05:52 -0700 Date: Fri, 21 Jul 2006 15:05:52 -0700 (PDT) From: Mike McBride To: pim@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 21 Jul 2006 22:05:52.0906 (UTC) FILETIME=[D52B1EA0:01C6AD11] DKIM-Signature: a=rsa-sha1; q=dns; l=390; t=1153519585; x=1154383585; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mmcbride@cisco.com; z=From:Mike=20McBride=20 |Subject:[pim]=20draft-atwood-pim-sm-linklocal=20; X=v=3Dcisco.com=3B=20h=3DWbsM7rEjm0AOfcaNpT2xmvo9lbU=3D; b=k9RJwsiSgV2JRjsEgw85Uxhv7ORPaolugBhlO+Cjia8WwUk+dzTvwilnFEqTlkRWnfiFVvDw nKrvr4jSFHJiIdX1o8YIHycWLVgygo3P2w1YaGt9FDI8MGr/0+oFSdzJ; Authentication-Results: sj-dkim-3.cisco.com; header.From=mmcbride@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: msec@ietf.org Subject: [MSEC] [pim] draft-atwood-pim-sm-linklocal X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org draft-atwood-pim-sm-linklocal-01 was presented by Bill Atwood in our wg meeting last week. The authors are requesting this work become a wg item. It proposes securing the pim control plane beyond what is defined in the pim-sm spec. Please review the draft and provide opinions on adoption. http://www.ietf.org/internet-drafts/draft-atwood-pim-sm-linklocal-01.txt thanks, mike _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 25 10:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NdO-0007va-LE; Tue, 25 Jul 2006 10:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NdN-0007vV-RX for msec@ietf.org; Tue, 25 Jul 2006 10:11:41 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5NdM-0003EH-I7 for msec@ietf.org; Tue, 25 Jul 2006 10:11:41 -0400 Received: (qmail 30671 invoked by uid 0); 25 Jul 2006 10:11:39 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 25 Jul 2006 10:11:39 -0400 Received: (qmail 72329 invoked from network); 25 Jul 2006 10:11:23 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 25 Jul 2006 10:11:23 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6PAPsn03088; Tue, 25 Jul 2006 06:25:54 -0400 Date: Tue, 25 Jul 2006 06:25:53 -0400 (EDT) From: George Gross To: Mike McBride Subject: Re: [MSEC] [pim] draft-atwood-pim-sm-linklocal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: msec@ietf.org, pim@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mike, I took a look at your PIM-SM link local security draft. As part of any operationally viable solution, I would suggest that automated group key management is going to be preferred for PIM-SM over manual keying. There are at least four cases that tilt the table towards this conclusion: 1) Group Speaker PIM-SM router crashes and reboots (note: in your model, every PIM-SM router is a Group Speaker) 2) Group Receiver PIM-SM router rebooting 3) group key lifetime expiration - good key management hygiene is to retire keys that have been in use for a period of time (e.g. 24 hours), or after they've authenticated a given volume of traffic. 4) group key compromise - somebody leaks the group secret authentication key, we need to replace it immediately. In the first of these cases, the PIM-SM communications are inoperable until all of the peer endpoints manually synchronize their IPsec SA sequence numbers with the rebooted peer PIM-SM router. In all of the above cases, the PIM-SM communications are interrupted until you manually visit each PIM-SM router to correct the IPsec SPD/SAD state. A group key management protocol solves the problems incurred by the above cases. Rebooting PIM-SM routers must re-register with the Group Controller Key Server (GCKS) to synchronize their state with the group. The GCKS announces each global change in group state to its members. Rekeying the whole group is done by the GCKS using a group rekey protocol such as Logical Key Hierarchy (e.g. see Appendix A of RFC4535). So unless the group has only two or three PIM-SM routers, I would be concerned that a manually keyed group IPsec SA would not be scalable in practice. That said, it is a good thing that PIM-SM working group is taking steps to examine how to secure the protocol, and standardizing its solution would make sense as a working group activity. BTW, there is an IPsec multicast extensions standards track draft in MSEC you may wish to look at: draft-ietf-msec-ipsec-extensions-02.txt. This draft defines the RFC4301 superset needed to support a group key management protocol. hth, George P.S. I don't subscribe to the PIM mail list, so if this e-mail bounces and doesn't appear there, please feel free to forward there on my behalf. thx! On Fri, 21 Jul 2006, Mike McBride wrote: > draft-atwood-pim-sm-linklocal-01 was presented by Bill Atwood in our wg > meeting last week. The authors are requesting this work become a wg item. > It proposes securing the pim control plane beyond what is defined in the > pim-sm spec. Please review the draft and provide opinions on adoption. > > http://www.ietf.org/internet-drafts/draft-atwood-pim-sm-linklocal-01.txt > > thanks, > mike > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Jul 25 10:11:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NdO-0007va-LE; Tue, 25 Jul 2006 10:11:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5NdN-0007vV-RX for msec@ietf.org; Tue, 25 Jul 2006 10:11:41 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5NdM-0003EH-I7 for msec@ietf.org; Tue, 25 Jul 2006 10:11:41 -0400 Received: (qmail 30671 invoked by uid 0); 25 Jul 2006 10:11:39 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 25 Jul 2006 10:11:39 -0400 Received: (qmail 72329 invoked from network); 25 Jul 2006 10:11:23 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 25 Jul 2006 10:11:23 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6PAPsn03088; Tue, 25 Jul 2006 06:25:54 -0400 Date: Tue, 25 Jul 2006 06:25:53 -0400 (EDT) From: George Gross To: Mike McBride Subject: Re: [MSEC] [pim] draft-atwood-pim-sm-linklocal In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: msec@ietf.org, pim@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Mike, I took a look at your PIM-SM link local security draft. As part of any operationally viable solution, I would suggest that automated group key management is going to be preferred for PIM-SM over manual keying. There are at least four cases that tilt the table towards this conclusion: 1) Group Speaker PIM-SM router crashes and reboots (note: in your model, every PIM-SM router is a Group Speaker) 2) Group Receiver PIM-SM router rebooting 3) group key lifetime expiration - good key management hygiene is to retire keys that have been in use for a period of time (e.g. 24 hours), or after they've authenticated a given volume of traffic. 4) group key compromise - somebody leaks the group secret authentication key, we need to replace it immediately. In the first of these cases, the PIM-SM communications are inoperable until all of the peer endpoints manually synchronize their IPsec SA sequence numbers with the rebooted peer PIM-SM router. In all of the above cases, the PIM-SM communications are interrupted until you manually visit each PIM-SM router to correct the IPsec SPD/SAD state. A group key management protocol solves the problems incurred by the above cases. Rebooting PIM-SM routers must re-register with the Group Controller Key Server (GCKS) to synchronize their state with the group. The GCKS announces each global change in group state to its members. Rekeying the whole group is done by the GCKS using a group rekey protocol such as Logical Key Hierarchy (e.g. see Appendix A of RFC4535). So unless the group has only two or three PIM-SM routers, I would be concerned that a manually keyed group IPsec SA would not be scalable in practice. That said, it is a good thing that PIM-SM working group is taking steps to examine how to secure the protocol, and standardizing its solution would make sense as a working group activity. BTW, there is an IPsec multicast extensions standards track draft in MSEC you may wish to look at: draft-ietf-msec-ipsec-extensions-02.txt. This draft defines the RFC4301 superset needed to support a group key management protocol. hth, George P.S. I don't subscribe to the PIM mail list, so if this e-mail bounces and doesn't appear there, please feel free to forward there on my behalf. thx! On Fri, 21 Jul 2006, Mike McBride wrote: > draft-atwood-pim-sm-linklocal-01 was presented by Bill Atwood in our wg > meeting last week. The authors are requesting this work become a wg item. > It proposes securing the pim control plane beyond what is defined in the > pim-sm spec. Please review the draft and provide opinions on adoption. > > http://www.ietf.org/internet-drafts/draft-atwood-pim-sm-linklocal-01.txt > > thanks, > mike > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 26 14:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oJE-0000Zt-Cs; Wed, 26 Jul 2006 14:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oJC-0000Yr-UH for msec@ietf.org; Wed, 26 Jul 2006 14:40:38 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5oJB-0002dH-JR for msec@ietf.org; Wed, 26 Jul 2006 14:40:38 -0400 Received: (qmail 97757 invoked by uid 0); 26 Jul 2006 14:40:34 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 26 Jul 2006 14:40:34 -0400 Received: (qmail 94944 invoked from network); 26 Jul 2006 14:40:34 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 26 Jul 2006 14:40:34 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6QEspL04749; Wed, 26 Jul 2006 10:54:51 -0400 Date: Wed, 26 Jul 2006 10:54:51 -0400 (EDT) From: George Gross To: Subject: RE: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: msec@ietf.org, canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Lakshminath, Haitham and I will be working together as co-authors on this draft. There are several other parties that I have invited to review the composite groups draft. However, as might be expected, that review is only one in the mix of many activities bidding for their time. So I would appreciate it if we could await their views and accomodate their schedules before deciding for/against this draft becoming an MSEC activity... tia, George On Thu, 13 Jul 2006 H.Cruickshank@surrey.ac.uk wrote: > Hi Lakshminath and George, > > I think this work is very interesting. I can co-author this draft, if possible. > > Haitham > > ---- > Dr. Haitham S. Cruickshank > Lecturer > 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/ > > ________________________________ > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Wed 12/07/2006 19:48 > To: msec@ietf.org > Cc: canetti@csail.mit.edu > Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track > > > > Folks, > > At the MSEC meeting yesterday, George's composite group work was well > received, well really two supporting statements and no objections. I > would like to hear from the list as to whether there is interest in > co-authoring and/or reviewing that work. > > The proposal is to make it a MSEC work item in the Experimental > track. Please let us know your opinions on this before July 26th, 2006. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Jul 26 14:41:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oJE-0000Zt-Cs; Wed, 26 Jul 2006 14:40:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oJC-0000Yr-UH for msec@ietf.org; Wed, 26 Jul 2006 14:40:38 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5oJB-0002dH-JR for msec@ietf.org; Wed, 26 Jul 2006 14:40:38 -0400 Received: (qmail 97757 invoked by uid 0); 26 Jul 2006 14:40:34 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 26 Jul 2006 14:40:34 -0400 Received: (qmail 94944 invoked from network); 26 Jul 2006 14:40:34 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 26 Jul 2006 14:40:34 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6QEspL04749; Wed, 26 Jul 2006 10:54:51 -0400 Date: Wed, 26 Jul 2006 10:54:51 -0400 (EDT) From: George Gross To: Subject: RE: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: msec@ietf.org, canetti@csail.mit.edu X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Lakshminath, Haitham and I will be working together as co-authors on this draft. There are several other parties that I have invited to review the composite groups draft. However, as might be expected, that review is only one in the mix of many activities bidding for their time. So I would appreciate it if we could await their views and accomodate their schedules before deciding for/against this draft becoming an MSEC activity... tia, George On Thu, 13 Jul 2006 H.Cruickshank@surrey.ac.uk wrote: > Hi Lakshminath and George, > > I think this work is very interesting. I can co-author this draft, if possible. > > Haitham > > ---- > Dr. Haitham S. Cruickshank > Lecturer > 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/ > > ________________________________ > > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: Wed 12/07/2006 19:48 > To: msec@ietf.org > Cc: canetti@csail.mit.edu > Subject: [MSEC] Consensus call: draft-gross-msec-ipsec-composite-group as a WG item in the Exp track > > > > Folks, > > At the MSEC meeting yesterday, George's composite group work was well > received, well really two supporting statements and no objections. I > would like to hear from the list as to whether there is interest in > co-authoring and/or reviewing that work. > > The proposal is to make it a MSEC work item in the Experimental > track. Please let us know your opinions on this before July 26th, 2006. > > thanks, > Lakshminath > > > _______________________________________________ > MSEC mailing list > MSEC@ietf.org > https://www1.ietf.org/mailman/listinfo/msec > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 27 06:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63Ue-0000NL-B1; Thu, 27 Jul 2006 06:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63Ud-0000NG-Ep for msec@ietf.org; Thu, 27 Jul 2006 06:53:27 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G63Uc-0001uG-3z for msec@ietf.org; Thu, 27 Jul 2006 06:53:27 -0400 Received: by nf-out-0910.google.com with SMTP id n15so132651nfc for ; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CA0K+DfIK4+e4PTGTH5P4GW9tonPP9o08mZSGJcKRD02FFOSZufoP/WHcltAA3YSihZi7f0GJBcSNZVwNj3tXCguz6kr+OpY6zV59Uqx8laQA2VqMhnxYFHqjJwvjNgdGoKSI9IHwqLL/vUEaMUpqDzqf+zmQFbageHsJuW7Z/I= Received: by 10.48.42.1 with SMTP id p1mr1609594nfp; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) Message-ID: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> Date: Thu, 27 Jul 2006 11:53:25 +0100 From: "Prashant Pillai" To: msec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [MSEC] distributed GSAKMP X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1566605580==" Errors-To: msec-bounces@ietf.org --===============1566605580== Content-Type: multipart/alternative; boundary="----=_Part_123320_5295319.1153997605230" ------=_Part_123320_5295319.1153997605230 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Could someone pleased help me with some doubts on distributed architecture: - In RFC3740, Section 2.3 mention having separate policy servers in a distributed multicast framework. While in GSAKMP, there is only a single GO, which is reposbile for the policy. - In the GSAKMP document, it is stated that a subset of the GMs will be authorised to be S-GCKS. Is there any particular way in which these GMs are selected? I am not sure how this is done in a distributed architecture. Is GM selected per domain? - What if there is only a single GM (in each of the distributed domains) who wants to access the content? And what happens for indivduals on the internet? - Also what happens if the GM acting as the S-GCKS decides to leave? - In a distributed environment - like two separate corporates who want to access the content, is it not more feasible to have one of the servers act as a GCKS, instead of a GM. Regards Prashant Pillai Research Assistant School of Engineering, Design and Technology, University of Bradford United Kingdom ------=_Part_123320_5295319.1153997605230 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
Could someone pleased help me with some doubts on distributed architecture:
  • In RFC3740, Section 2.3 mention having separate policy servers in a distributed multicast framework. While in GSAKMP, there is only a single GO, which is reposbile for the policy.
  • In the GSAKMP document, it is stated that a subset of the GMs will be authorised to be S-GCKS. Is there any particular way in which these GMs are selected? I am not sure how this is done in a distributed architecture. Is GM selected per domain?
  • What if there is only a single GM (in each of the distributed domains) who wants to access the content? And what happens for indivduals on the internet?
  • Also what happens if the GM acting as the S-GCKS decides to leave?
  • In a distributed environment - like two separate corporates who want to access the content, is it not more feasible to have one of the servers act as a GCKS, instead of a GM.
Regards
Prashant Pillai
 
Research Assistant
School of Engineering, Design and Technology,
University of Bradford
United Kingdom
 
------=_Part_123320_5295319.1153997605230-- --===============1566605580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1566605580==-- From msec-bounces@ietf.org Thu Jul 27 06:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63Ue-0000NL-B1; Thu, 27 Jul 2006 06:53:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G63Ud-0000NG-Ep for msec@ietf.org; Thu, 27 Jul 2006 06:53:27 -0400 Received: from nf-out-0910.google.com ([64.233.182.184]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G63Uc-0001uG-3z for msec@ietf.org; Thu, 27 Jul 2006 06:53:27 -0400 Received: by nf-out-0910.google.com with SMTP id n15so132651nfc for ; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=CA0K+DfIK4+e4PTGTH5P4GW9tonPP9o08mZSGJcKRD02FFOSZufoP/WHcltAA3YSihZi7f0GJBcSNZVwNj3tXCguz6kr+OpY6zV59Uqx8laQA2VqMhnxYFHqjJwvjNgdGoKSI9IHwqLL/vUEaMUpqDzqf+zmQFbageHsJuW7Z/I= Received: by 10.48.42.1 with SMTP id p1mr1609594nfp; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Thu, 27 Jul 2006 03:53:25 -0700 (PDT) Message-ID: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> Date: Thu, 27 Jul 2006 11:53:25 +0100 From: "Prashant Pillai" To: msec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [MSEC] distributed GSAKMP X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1566605580==" Errors-To: msec-bounces@ietf.org --===============1566605580== Content-Type: multipart/alternative; boundary="----=_Part_123320_5295319.1153997605230" ------=_Part_123320_5295319.1153997605230 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Could someone pleased help me with some doubts on distributed architecture: - In RFC3740, Section 2.3 mention having separate policy servers in a distributed multicast framework. While in GSAKMP, there is only a single GO, which is reposbile for the policy. - In the GSAKMP document, it is stated that a subset of the GMs will be authorised to be S-GCKS. Is there any particular way in which these GMs are selected? I am not sure how this is done in a distributed architecture. Is GM selected per domain? - What if there is only a single GM (in each of the distributed domains) who wants to access the content? And what happens for indivduals on the internet? - Also what happens if the GM acting as the S-GCKS decides to leave? - In a distributed environment - like two separate corporates who want to access the content, is it not more feasible to have one of the servers act as a GCKS, instead of a GM. Regards Prashant Pillai Research Assistant School of Engineering, Design and Technology, University of Bradford United Kingdom ------=_Part_123320_5295319.1153997605230 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi,
 
Could someone pleased help me with some doubts on distributed architecture:
  • In RFC3740, Section 2.3 mention having separate policy servers in a distributed multicast framework. While in GSAKMP, there is only a single GO, which is reposbile for the policy.
  • In the GSAKMP document, it is stated that a subset of the GMs will be authorised to be S-GCKS. Is there any particular way in which these GMs are selected? I am not sure how this is done in a distributed architecture. Is GM selected per domain?
  • What if there is only a single GM (in each of the distributed domains) who wants to access the content? And what happens for indivduals on the internet?
  • Also what happens if the GM acting as the S-GCKS decides to leave?
  • In a distributed environment - like two separate corporates who want to access the content, is it not more feasible to have one of the servers act as a GCKS, instead of a GM.
Regards
Prashant Pillai
 
Research Assistant
School of Engineering, Design and Technology,
University of Bradford
United Kingdom
 
------=_Part_123320_5295319.1153997605230-- --===============1566605580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============1566605580==-- From msec-bounces@ietf.org Thu Jul 27 09:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6620-0006ao-N4; Thu, 27 Jul 2006 09:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G661z-0006YI-GX for msec@ietf.org; Thu, 27 Jul 2006 09:36:03 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G661y-0000gX-6p for msec@ietf.org; Thu, 27 Jul 2006 09:36:03 -0400 Received: (qmail 54114 invoked by uid 0); 27 Jul 2006 09:36:01 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 27 Jul 2006 09:36:01 -0400 Received: (qmail 81203 invoked from network); 27 Jul 2006 09:36:01 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 27 Jul 2006 09:36:01 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6R9oCL06306; Thu, 27 Jul 2006 05:50:12 -0400 Date: Thu, 27 Jul 2006 05:50:11 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Thu, 27 Jul 2006, Prashant Pillai wrote: > Hi, > > Could someone pleased help me with some doubts on distributed architecture: > > - In RFC3740, Section 2.3 mention having separate policy servers in a > distributed multicast framework. While in GSAKMP, there is only a single GO, > which is reposbile for the policy. Yes, that is correct. The GSAKMP framework uses multicast to distribute the policy token whenever it changes. Since this policy distribution method is scalable, it mitigates the need for multiple policy servers. Besides, having multiple policy authorities would be extremely complicated for minimumal benefit, IMHO. > - In the GSAKMP document, it is stated that a subset of the GMs will > be authorised to be S-GCKS. Is there any particular way in which these GMs > are selected? I am not sure how this is done in a distributed architecture. > Is GM selected per domain? The answer is application policy specific. The GO decides what is the "right" policy, and encodes the policy token to authorize the S-GCKS subset within the overall group membership. For example, composite groups could be organized to have a S-GCKS per homogeneous sub-group. Again, what attributes constitute a "sub-group" for a composite group is application specific. > - What if there is only a single GM (in each of the distributed > domains) who wants to access the content? And what happens for indivduals on > the internet? I don't understand this question. > - Also what happens if the GM acting as the S-GCKS decides to leave? This answer is also application security policy specific. Usually a S-GCKS doesn't leave until after its sub-group reaches an empty membership condition. If a S-GCKS is compromised, then its sub-group membership must re-register at another GCKS to rejoin the group. This is because after primary GCKS rekeys the group to expell the S-GCKS, the S-GCKS is no longer able to decrypt the RKE multicasts from the primary GCKS and propagate the new GTPK and PT to the sub-group. Alternatively, after a S-GCKS compromise the whole group should be terminated and then re-built. > - In a distributed environment - like two separate corporates who want > to access the content, is it not more feasible to have one of the servers > act as a GCKS, instead of a GM. Yes. Yet another example of delegating S-GCKS responsibility on the basis of application specific policy. hth, George > > Regards > Prashant Pillai > > Research Assistant > School of Engineering, Design and Technology, > University of Bradford > United Kingdom > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 27 09:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6620-0006ao-N4; Thu, 27 Jul 2006 09:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G661z-0006YI-GX for msec@ietf.org; Thu, 27 Jul 2006 09:36:03 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G661y-0000gX-6p for msec@ietf.org; Thu, 27 Jul 2006 09:36:03 -0400 Received: (qmail 54114 invoked by uid 0); 27 Jul 2006 09:36:01 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 27 Jul 2006 09:36:01 -0400 Received: (qmail 81203 invoked from network); 27 Jul 2006 09:36:01 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 27 Jul 2006 09:36:01 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6R9oCL06306; Thu, 27 Jul 2006 05:50:12 -0400 Date: Thu, 27 Jul 2006 05:50:11 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Thu, 27 Jul 2006, Prashant Pillai wrote: > Hi, > > Could someone pleased help me with some doubts on distributed architecture: > > - In RFC3740, Section 2.3 mention having separate policy servers in a > distributed multicast framework. While in GSAKMP, there is only a single GO, > which is reposbile for the policy. Yes, that is correct. The GSAKMP framework uses multicast to distribute the policy token whenever it changes. Since this policy distribution method is scalable, it mitigates the need for multiple policy servers. Besides, having multiple policy authorities would be extremely complicated for minimumal benefit, IMHO. > - In the GSAKMP document, it is stated that a subset of the GMs will > be authorised to be S-GCKS. Is there any particular way in which these GMs > are selected? I am not sure how this is done in a distributed architecture. > Is GM selected per domain? The answer is application policy specific. The GO decides what is the "right" policy, and encodes the policy token to authorize the S-GCKS subset within the overall group membership. For example, composite groups could be organized to have a S-GCKS per homogeneous sub-group. Again, what attributes constitute a "sub-group" for a composite group is application specific. > - What if there is only a single GM (in each of the distributed > domains) who wants to access the content? And what happens for indivduals on > the internet? I don't understand this question. > - Also what happens if the GM acting as the S-GCKS decides to leave? This answer is also application security policy specific. Usually a S-GCKS doesn't leave until after its sub-group reaches an empty membership condition. If a S-GCKS is compromised, then its sub-group membership must re-register at another GCKS to rejoin the group. This is because after primary GCKS rekeys the group to expell the S-GCKS, the S-GCKS is no longer able to decrypt the RKE multicasts from the primary GCKS and propagate the new GTPK and PT to the sub-group. Alternatively, after a S-GCKS compromise the whole group should be terminated and then re-built. > - In a distributed environment - like two separate corporates who want > to access the content, is it not more feasible to have one of the servers > act as a GCKS, instead of a GM. Yes. Yet another example of delegating S-GCKS responsibility on the basis of application specific policy. hth, George > > Regards > Prashant Pillai > > Research Assistant > School of Engineering, Design and Technology, > University of Bradford > United Kingdom > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 27 11:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Vv-0001gg-Hh; Thu, 27 Jul 2006 11:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Vv-0001gW-3K for msec@ietf.org; Thu, 27 Jul 2006 11:11:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66eA-0007lR-0d for msec@ietf.org; Thu, 27 Jul 2006 10:15:30 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G66bV-0004Fh-5l for msec@ietf.org; Thu, 27 Jul 2006 10:12:48 -0400 Received: by nf-out-0910.google.com with SMTP id n15so199611nfc for ; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ae/Iz10k8h3fwUbrb6oaPQKJ4GaAkkAbmlsOEneUaeh0hPxEKPEE+rviPOma26id6h2HYZlH7CN74j0+WWkHEeVAeOmRol6CakapUauVAuVkgtzSNbMSYuwNEfvv4BlLbQRqtZzpU8C1O8ESD2d7hLJrEyjA5vtU1t5UJbXsYa0= Received: by 10.49.8.15 with SMTP id l15mr46634nfi; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) Message-ID: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> Date: Thu, 27 Jul 2006 15:12:41 +0100 From: "Prashant Pillai" To: "George Gross" Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: MIME-Version: 1.0 References: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263228274==" Errors-To: msec-bounces@ietf.org --===============0263228274== Content-Type: multipart/alternative; boundary="----=_Part_125649_30676790.1154009561348" ------=_Part_125649_30676790.1154009561348 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi George, Thanx for ur reply. See inline. Regards Prashant Pillai On 7/27/06, George Gross wrote: > Hi Prashant, > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > Hi, > > > > Could someone pleased help me with some doubts on distributed > architecture: > > > > - In RFC3740, Section 2.3 mention having separate policy servers in a > > distributed multicast framework. While in GSAKMP, there is only a > single GO, > > which is reposbile for the policy. > > Yes, that is correct. The GSAKMP framework uses multicast to distribute > the policy token whenever it changes. Since this policy distribution > method is scalable, it mitigates the need for multiple policy servers. > Besides, having multiple policy authorities would be extremely complicated > for minimumal benefit, IMHO. I agree, I was also not sure why we would need multiple policy servers. It adds to more complexity for interoperability of these policy server. > > - In the GSAKMP document, it is stated that a subset of the GMs will > > be authorised to be S-GCKS. Is there any particular way in which > these GMs > > are selected? I am not sure how this is done in a distributed > architecture. > > Is GM selected per domain? > > The answer is application policy specific. The GO decides what is the > "right" policy, and encodes the policy token to authorize the S-GCKS > subset within the overall group membership. > > For example, composite groups could be organized to have a S-GCKS per > homogeneous sub-group. Again, what attributes constitute a "sub-group" for > a composite group is application specific. Why is the definition of "Sub-groups" application specific? Do you mean the type of application shall define the sub-group? I am not sure why this should be so. > - What if there is only a single GM (in each of the distributed > domains) who wants to access the content? And what happens for indivduals on > the internet? I don't understand this question. What I wanted to ask was if GSAKMP is only suitable when different corporate LANs want to share secure multicast content or can it be also used over the internet - say a company decides to offer Secure multicast video streaming which should be accessible to any user on the internet. How is a S-GSKC selected then? Note here that users may connect from any part of the world at any time. Who can be an S-GCKS in such a scenario? > - Also what happens if the GM acting as the S-GCKS decides to leave? This answer is also application security policy specific. Usually a S-GCKS doesn't leave until after its sub-group reaches an empty membership condition. If the S-GCKS is a GM (hence an end user am I correct in saying this), I am not sure why it may not leave, unless GM is not an end user but another server or router that is always on. Not sure if this is possbile though. If a S-GCKS is compromised, then its sub-group membership must re-register at another GCKS to rejoin the group. This is because after primary GCKS rekeys the group to expell the S-GCKS, the S-GCKS is no longer able to decrypt the RKE multicasts from the primary GCKS and propagate the new GTPK and PT to the sub-group. Alternatively, after a S-GCKS compromise the whole group should be terminated and then re-built. > - In a distributed environment - like two separate corporates who want > to access the content, is it not more feasible to have one of the servers > act as a GCKS, instead of a GM. Yes. Yet another example of delegating S-GCKS responsibility on the basis of application specific policy. hth, George > > Regards > Prashant Pillai > > Research Assistant > School of Engineering, Design and Technology, > University of Bradford > United Kingdom > ------=_Part_125649_30676790.1154009561348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi George,
 
Thanx for ur reply. See inline.
 
Regards
Prashant Pillai
 
On 7/27/06, George Gross <gmgross@nac.net> wrote:
Hi Prashant,

On Thu, 27 Jul 2006, Prashant Pillai wrote:

> Hi,
>
> Could someone pleased help me with some doubts on distributed architecture:
>
>    - In RFC3740, Section 2.3 mention having separate policy servers in a
>    distributed multicast framework. While in GSAKMP, there is only a single GO,
>    which is reposbile for the policy.

Yes, that is correct. The GSAKMP framework uses multicast to distribute
the policy token whenever it changes. Since this policy distribution
method is scalable, it mitigates the need for multiple policy servers.
Besides, having multiple policy authorities would be extremely complicated
for minimumal benefit, IMHO.
 
I agree, I was also not sure why we would need multiple policy servers. It adds to more complexity for interoperability of these policy server.

 
>    - In the GSAKMP document, it is stated that a subset of the GMs will
>    be authorised to be S-GCKS. Is there any particular way in which these GMs
>    are selected? I am not sure how this is done in a distributed architecture.
>    Is GM selected per domain?

The answer is application policy specific. The GO decides what is the
"right" policy, and encodes the policy token to authorize the S-GCKS
subset within the overall group membership.

For example, composite groups could be organized to have a S-GCKS per
homogeneous sub-group. Again, what attributes constitute a "sub-group" for
a composite group is application specific.
 
Why is the definition of "Sub-groups" application specific? Do you mean the type of application shall define the sub-group? I am not sure why this should be so.
 
>    - What if there is only a single GM (in each of the distributed
>    domains) who wants to access the content? And what happens for indivduals on
>    the internet?

I don't understand this question.
 
What I wanted to ask was if GSAKMP is only suitable when different corporate LANs want to share secure multicast content or can it be also used over the internet - say a company decides to offer Secure multicast video streaming which should be accessible to any user on the internet. How is a S-GSKC selected then? Note here that users may connect from any part of the world at any time. Who can be an S-GCKS in such a scenario?

>    - Also what happens if the GM acting as the S-GCKS decides to leave?

This answer is also application security policy specific.

Usually a S-GCKS doesn't leave until after its sub-group reaches an empty
membership condition. 
 
If the S-GCKS is a GM (hence an end user am I correct in saying this), I am not sure why it may not leave, unless GM is not an end user but another server or router that is always on. Not sure if this is possbile though. 
 
 If a S-GCKS is compromised, then its sub-group
membership must re-register at another GCKS to rejoin the group. This is
because after primary GCKS rekeys the group to expell the S-GCKS, the
S-GCKS is no longer able to decrypt the RKE multicasts from the primary
GCKS and propagate the new GTPK and PT to the sub-group.

Alternatively, after a S-GCKS compromise the whole group should be
terminated and then re-built.

>    - In a distributed environment - like two separate corporates who want
>    to access the content, is it not more feasible to have one of the servers
>    act as a GCKS, instead of a GM.

Yes. Yet another example of delegating S-GCKS responsibility on the basis
of application specific policy.

hth,
       George

>
> Regards
> Prashant Pillai
>
> Research Assistant
> School of Engineering, Design and Technology,
> University of Bradford
> United Kingdom
>
------=_Part_125649_30676790.1154009561348-- --===============0263228274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0263228274==-- From msec-bounces@ietf.org Thu Jul 27 11:11:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Vv-0001gg-Hh; Thu, 27 Jul 2006 11:11:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67Vv-0001gW-3K for msec@ietf.org; Thu, 27 Jul 2006 11:11:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G66eA-0007lR-0d for msec@ietf.org; Thu, 27 Jul 2006 10:15:30 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G66bV-0004Fh-5l for msec@ietf.org; Thu, 27 Jul 2006 10:12:48 -0400 Received: by nf-out-0910.google.com with SMTP id n15so199611nfc for ; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Ae/Iz10k8h3fwUbrb6oaPQKJ4GaAkkAbmlsOEneUaeh0hPxEKPEE+rviPOma26id6h2HYZlH7CN74j0+WWkHEeVAeOmRol6CakapUauVAuVkgtzSNbMSYuwNEfvv4BlLbQRqtZzpU8C1O8ESD2d7hLJrEyjA5vtU1t5UJbXsYa0= Received: by 10.49.8.15 with SMTP id l15mr46634nfi; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Thu, 27 Jul 2006 07:12:41 -0700 (PDT) Message-ID: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> Date: Thu, 27 Jul 2006 15:12:41 +0100 From: "Prashant Pillai" To: "George Gross" Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: MIME-Version: 1.0 References: <4166af450607270353i907ab29xeed4bdb95e55f8ab@mail.gmail.com> X-Spam-Score: -2.5 (--) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0263228274==" Errors-To: msec-bounces@ietf.org --===============0263228274== Content-Type: multipart/alternative; boundary="----=_Part_125649_30676790.1154009561348" ------=_Part_125649_30676790.1154009561348 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi George, Thanx for ur reply. See inline. Regards Prashant Pillai On 7/27/06, George Gross wrote: > Hi Prashant, > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > Hi, > > > > Could someone pleased help me with some doubts on distributed > architecture: > > > > - In RFC3740, Section 2.3 mention having separate policy servers in a > > distributed multicast framework. While in GSAKMP, there is only a > single GO, > > which is reposbile for the policy. > > Yes, that is correct. The GSAKMP framework uses multicast to distribute > the policy token whenever it changes. Since this policy distribution > method is scalable, it mitigates the need for multiple policy servers. > Besides, having multiple policy authorities would be extremely complicated > for minimumal benefit, IMHO. I agree, I was also not sure why we would need multiple policy servers. It adds to more complexity for interoperability of these policy server. > > - In the GSAKMP document, it is stated that a subset of the GMs will > > be authorised to be S-GCKS. Is there any particular way in which > these GMs > > are selected? I am not sure how this is done in a distributed > architecture. > > Is GM selected per domain? > > The answer is application policy specific. The GO decides what is the > "right" policy, and encodes the policy token to authorize the S-GCKS > subset within the overall group membership. > > For example, composite groups could be organized to have a S-GCKS per > homogeneous sub-group. Again, what attributes constitute a "sub-group" for > a composite group is application specific. Why is the definition of "Sub-groups" application specific? Do you mean the type of application shall define the sub-group? I am not sure why this should be so. > - What if there is only a single GM (in each of the distributed > domains) who wants to access the content? And what happens for indivduals on > the internet? I don't understand this question. What I wanted to ask was if GSAKMP is only suitable when different corporate LANs want to share secure multicast content or can it be also used over the internet - say a company decides to offer Secure multicast video streaming which should be accessible to any user on the internet. How is a S-GSKC selected then? Note here that users may connect from any part of the world at any time. Who can be an S-GCKS in such a scenario? > - Also what happens if the GM acting as the S-GCKS decides to leave? This answer is also application security policy specific. Usually a S-GCKS doesn't leave until after its sub-group reaches an empty membership condition. If the S-GCKS is a GM (hence an end user am I correct in saying this), I am not sure why it may not leave, unless GM is not an end user but another server or router that is always on. Not sure if this is possbile though. If a S-GCKS is compromised, then its sub-group membership must re-register at another GCKS to rejoin the group. This is because after primary GCKS rekeys the group to expell the S-GCKS, the S-GCKS is no longer able to decrypt the RKE multicasts from the primary GCKS and propagate the new GTPK and PT to the sub-group. Alternatively, after a S-GCKS compromise the whole group should be terminated and then re-built. > - In a distributed environment - like two separate corporates who want > to access the content, is it not more feasible to have one of the servers > act as a GCKS, instead of a GM. Yes. Yet another example of delegating S-GCKS responsibility on the basis of application specific policy. hth, George > > Regards > Prashant Pillai > > Research Assistant > School of Engineering, Design and Technology, > University of Bradford > United Kingdom > ------=_Part_125649_30676790.1154009561348 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi George,
 
Thanx for ur reply. See inline.
 
Regards
Prashant Pillai
 
On 7/27/06, George Gross <gmgross@nac.net> wrote:
Hi Prashant,

On Thu, 27 Jul 2006, Prashant Pillai wrote:

> Hi,
>
> Could someone pleased help me with some doubts on distributed architecture:
>
>    - In RFC3740, Section 2.3 mention having separate policy servers in a
>    distributed multicast framework. While in GSAKMP, there is only a single GO,
>    which is reposbile for the policy.

Yes, that is correct. The GSAKMP framework uses multicast to distribute
the policy token whenever it changes. Since this policy distribution
method is scalable, it mitigates the need for multiple policy servers.
Besides, having multiple policy authorities would be extremely complicated
for minimumal benefit, IMHO.
 
I agree, I was also not sure why we would need multiple policy servers. It adds to more complexity for interoperability of these policy server.

 
>    - In the GSAKMP document, it is stated that a subset of the GMs will
>    be authorised to be S-GCKS. Is there any particular way in which these GMs
>    are selected? I am not sure how this is done in a distributed architecture.
>    Is GM selected per domain?

The answer is application policy specific. The GO decides what is the
"right" policy, and encodes the policy token to authorize the S-GCKS
subset within the overall group membership.

For example, composite groups could be organized to have a S-GCKS per
homogeneous sub-group. Again, what attributes constitute a "sub-group" for
a composite group is application specific.
 
Why is the definition of "Sub-groups" application specific? Do you mean the type of application shall define the sub-group? I am not sure why this should be so.
 
>    - What if there is only a single GM (in each of the distributed
>    domains) who wants to access the content? And what happens for indivduals on
>    the internet?

I don't understand this question.
 
What I wanted to ask was if GSAKMP is only suitable when different corporate LANs want to share secure multicast content or can it be also used over the internet - say a company decides to offer Secure multicast video streaming which should be accessible to any user on the internet. How is a S-GSKC selected then? Note here that users may connect from any part of the world at any time. Who can be an S-GCKS in such a scenario?

>    - Also what happens if the GM acting as the S-GCKS decides to leave?

This answer is also application security policy specific.

Usually a S-GCKS doesn't leave until after its sub-group reaches an empty
membership condition. 
 
If the S-GCKS is a GM (hence an end user am I correct in saying this), I am not sure why it may not leave, unless GM is not an end user but another server or router that is always on. Not sure if this is possbile though. 
 
 If a S-GCKS is compromised, then its sub-group
membership must re-register at another GCKS to rejoin the group. This is
because after primary GCKS rekeys the group to expell the S-GCKS, the
S-GCKS is no longer able to decrypt the RKE multicasts from the primary
GCKS and propagate the new GTPK and PT to the sub-group.

Alternatively, after a S-GCKS compromise the whole group should be
terminated and then re-built.

>    - In a distributed environment - like two separate corporates who want
>    to access the content, is it not more feasible to have one of the servers
>    act as a GCKS, instead of a GM.

Yes. Yet another example of delegating S-GCKS responsibility on the basis
of application specific policy.

hth,
       George

>
> Regards
> Prashant Pillai
>
> Research Assistant
> School of Engineering, Design and Technology,
> University of Bradford
> United Kingdom
>
------=_Part_125649_30676790.1154009561348-- --===============0263228274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0263228274==-- From msec-bounces@ietf.org Thu Jul 27 11:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67jw-0004fB-3U; Thu, 27 Jul 2006 11:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67jv-0004f6-Md for msec@ietf.org; Thu, 27 Jul 2006 11:25:31 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G67ju-0002zt-C5 for msec@ietf.org; Thu, 27 Jul 2006 11:25:31 -0400 Received: (qmail 94936 invoked by uid 0); 27 Jul 2006 11:18:44 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 27 Jul 2006 11:18:44 -0400 Received: (qmail 45884 invoked from network); 27 Jul 2006 11:18:43 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 27 Jul 2006 11:18:43 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6RBWo106520; Thu, 27 Jul 2006 07:32:50 -0400 Date: Thu, 27 Jul 2006 07:32:50 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > - In the GSAKMP document, it is stated that a subset of the GMs will > > > be authorised to be S-GCKS. Is there any particular way in which > > these GMs > > > are selected? I am not sure how this is done in a distributed > > architecture. > > > Is GM selected per domain? > > > > The answer is application policy specific. The GO decides what is the > > "right" policy, and encodes the policy token to authorize the S-GCKS > > subset within the overall group membership. > > > > For example, composite groups could be organized to have a S-GCKS per > > homogeneous sub-group. Again, what attributes constitute a "sub-group" for > > a composite group is application specific. > > Why is the definition of "Sub-groups" application specific? Do you mean the > type of application shall define the sub-group? I am not sure why this > should be so. The Group Owner gets to decide this policy for each group. The criteria for S-GCKS can be anything: - scalability: 1 S-GCKS per 1,000 GM - divide up a group along administrative domain boundaries, S-GCKS per domain - composite group: S-GCKS per sub-group. - picked at random from a dart board, so long as that GM is considered trustworthy in that S-GCKS role o;) in other words, GSAKMP provides the tools to do it any way that makes sense to the GO. > > > - What if there is only a single GM (in each of the distributed > > domains) who wants to access the content? And what happens for > indivduals on > > the internet? > > I don't understand this question. > > What I wanted to ask was if GSAKMP is only suitable when different corporate > LANs want to share secure multicast content or can it be also used over the > internet - say a company decides to offer Secure multicast video streaming > which should be accessible to any user on the internet. How is a S-GSKC > selected then? Note here that users may connect from any part of the world > at any time. Who can be an S-GCKS in such a scenario? Discovery of S-GCKS is yet another question for which there is no "one size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > - Also what happens if the GM acting as the S-GCKS decides to leave? > > This answer is also application security policy specific. > > Usually a S-GCKS doesn't leave until after its sub-group reaches an empty > membership condition. > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I am > not sure why it may not leave, unless GM is not an end user but another > server or router that is always on. Not sure if this is possbile though. Accepting the S-GCKS role implies taking responsibility for the sub-group's membership management throughout a sub-group's lifespan. One part of that responsibility is the LKH key server for the sub-group. In that sense, S-GCKS are indeed a superset of an ordinary Group Member. However, as explained in RFC 4535 section 4.4.6, any Group Member must be prepared to accept becoming a S-GCKS if the GO authorized it AND local policy permits executing in that mode. George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Jul 27 11:25:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67jw-0004fB-3U; Thu, 27 Jul 2006 11:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G67jv-0004f6-Md for msec@ietf.org; Thu, 27 Jul 2006 11:25:31 -0400 Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G67ju-0002zt-C5 for msec@ietf.org; Thu, 27 Jul 2006 11:25:31 -0400 Received: (qmail 94936 invoked by uid 0); 27 Jul 2006 11:18:44 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 27 Jul 2006 11:18:44 -0400 Received: (qmail 45884 invoked from network); 27 Jul 2006 11:18:43 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 27 Jul 2006 11:18:43 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6RBWo106520; Thu, 27 Jul 2006 07:32:50 -0400 Date: Thu, 27 Jul 2006 07:32:50 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > - In the GSAKMP document, it is stated that a subset of the GMs will > > > be authorised to be S-GCKS. Is there any particular way in which > > these GMs > > > are selected? I am not sure how this is done in a distributed > > architecture. > > > Is GM selected per domain? > > > > The answer is application policy specific. The GO decides what is the > > "right" policy, and encodes the policy token to authorize the S-GCKS > > subset within the overall group membership. > > > > For example, composite groups could be organized to have a S-GCKS per > > homogeneous sub-group. Again, what attributes constitute a "sub-group" for > > a composite group is application specific. > > Why is the definition of "Sub-groups" application specific? Do you mean the > type of application shall define the sub-group? I am not sure why this > should be so. The Group Owner gets to decide this policy for each group. The criteria for S-GCKS can be anything: - scalability: 1 S-GCKS per 1,000 GM - divide up a group along administrative domain boundaries, S-GCKS per domain - composite group: S-GCKS per sub-group. - picked at random from a dart board, so long as that GM is considered trustworthy in that S-GCKS role o;) in other words, GSAKMP provides the tools to do it any way that makes sense to the GO. > > > - What if there is only a single GM (in each of the distributed > > domains) who wants to access the content? And what happens for > indivduals on > > the internet? > > I don't understand this question. > > What I wanted to ask was if GSAKMP is only suitable when different corporate > LANs want to share secure multicast content or can it be also used over the > internet - say a company decides to offer Secure multicast video streaming > which should be accessible to any user on the internet. How is a S-GSKC > selected then? Note here that users may connect from any part of the world > at any time. Who can be an S-GCKS in such a scenario? Discovery of S-GCKS is yet another question for which there is no "one size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > - Also what happens if the GM acting as the S-GCKS decides to leave? > > This answer is also application security policy specific. > > Usually a S-GCKS doesn't leave until after its sub-group reaches an empty > membership condition. > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I am > not sure why it may not leave, unless GM is not an end user but another > server or router that is always on. Not sure if this is possbile though. Accepting the S-GCKS role implies taking responsibility for the sub-group's membership management throughout a sub-group's lifespan. One part of that responsibility is the LKH key server for the sub-group. In that sense, S-GCKS are indeed a superset of an ordinary Group Member. However, as explained in RFC 4535 section 4.4.6, any Group Member must be prepared to accept becoming a S-GCKS if the GO authorized it AND local policy permits executing in that mode. George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 28 05:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OKd-0007Pj-7e; Fri, 28 Jul 2006 05:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OKb-0007Pe-Ro for msec@ietf.org; Fri, 28 Jul 2006 05:08:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6OKb-0002KX-9E for msec@ietf.org; Fri, 28 Jul 2006 05:08:29 -0400 Received: by nf-out-0910.google.com with SMTP id n15so153222nfc for ; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gCQy94BANAjDHAM/hhFpk1G6+laJDlfdBvJ2DwHbUj64nLNXG+vxxlgFDR3N40KsCnKsgIiboz9fMInTqu4a6chpBnNKxzEqL9NIMK5ZsUGaVsfgopKGsotoaSrGt0ni5Wuqn9s3meYiFTtx76/gPd+KeAR3takB8ulJbkOUnmA= Received: by 10.49.5.12 with SMTP id h12mr427848nfi; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) Message-ID: <4166af450607280208w29393c9dy14f3a0ead1b8ea8d@mail.gmail.com> Date: Fri, 28 Jul 2006 10:08:28 +0100 From: "Prashant Pillai" To: "George Gross" Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: MIME-Version: 1.0 References: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0938112673==" Errors-To: msec-bounces@ietf.org --===============0938112673== Content-Type: multipart/alternative; boundary="----=_Part_1915_30027796.1154077708359" ------=_Part_1915_30027796.1154077708359 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi George Is the GM an end user (receiver of the multicast content) or can it be any device (some server/ router)? RFC 4535 states that the GM is one who has access to the group keys. Am I correct in saying that the GM is any device who is registered (out-of- band) with the GO and hence is present in the access list?... and this GM should authenticate itself before it can act as a S-GSKC or as an end user receiving the multicast content. Regards Prashant P.S. Thanx a lot for you helpful replies. On 7/27/06, George Gross wrote: > > Hi Prashant, > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > > > > - In the GSAKMP document, it is stated that a subset of the GMs > will > > > > be authorised to be S-GCKS. Is there any particular way in which > > > these GMs > > > > are selected? I am not sure how this is done in a distributed > > > architecture. > > > > Is GM selected per domain? > > > > > > The answer is application policy specific. The GO decides what is the > > > "right" policy, and encodes the policy token to authorize the S-GCKS > > > subset within the overall group membership. > > > > > > For example, composite groups could be organized to have a S-GCKS per > > > homogeneous sub-group. Again, what attributes constitute a "sub-group" > for > > > a composite group is application specific. > > > > Why is the definition of "Sub-groups" application specific? Do you mean > the > > type of application shall define the sub-group? I am not sure why this > > should be so. > > The Group Owner gets to decide this policy for each group. The criteria > for S-GCKS can be anything: > > - scalability: 1 S-GCKS per 1,000 GM > > - divide up a group along administrative domain boundaries, S-GCKS per > domain > > - composite group: S-GCKS per sub-group. > > - picked at random from a dart board, so long as that GM is considered > trustworthy in that S-GCKS role o;) > > in other words, GSAKMP provides the tools to do it any way that makes > sense to the GO. > > > > > > - What if there is only a single GM (in each of the distributed > > > domains) who wants to access the content? And what happens for > > indivduals on > > > the internet? > > > > I don't understand this question. > > > > What I wanted to ask was if GSAKMP is only suitable when different > corporate > > LANs want to share secure multicast content or can it be also used over > the > > internet - say a company decides to offer Secure multicast video > streaming > > which should be accessible to any user on the internet. How is a S-GSKC > > selected then? Note here that users may connect from any part of the > world > > at any time. Who can be an S-GCKS in such a scenario? > > Discovery of S-GCKS is yet another question for which there is no "one > size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > > > - Also what happens if the GM acting as the S-GCKS decides to > leave? > > > > This answer is also application security policy specific. > > > > Usually a S-GCKS doesn't leave until after its sub-group reaches an > empty > > membership condition. > > > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I > am > > not sure why it may not leave, unless GM is not an end user but another > > server or router that is always on. Not sure if this is possbile though. > > Accepting the S-GCKS role implies taking responsibility for the > sub-group's membership management throughout a sub-group's lifespan. One > part of that responsibility is the LKH key server for the sub-group. In > that sense, S-GCKS are indeed a superset of an ordinary Group Member. > > However, as explained in RFC 4535 section 4.4.6, any Group Member must be > prepared to accept becoming a S-GCKS if the GO authorized it AND local > policy permits executing in that mode. > > George > > ------=_Part_1915_30027796.1154077708359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi George
 
Is the GM an end user (receiver of the multicast content) or can it be any device (some server/ router)? RFC 4535 states that the GM is one who has access to the group keys. Am I correct in saying that the GM is any device who is registered (out-of- band) with the GO and hence is present in the access list?... and this GM should authenticate itself before it can act as a S-GSKC or as an end user receiving the multicast content.
 
 
Regards
Prashant

P.S. Thanx a lot for you helpful replies.
 
 
On 7/27/06, George Gross <gmgross@nac.net> wrote:
Hi Prashant,

On Thu, 27 Jul 2006, Prashant Pillai wrote:

<snip for brevity>
> > >    - In the GSAKMP document, it is stated that a subset of the GMs will
> > >    be authorised to be S-GCKS. Is there any particular way in which
> > these GMs
> > >    are selected? I am not sure how this is done in a distributed
> > architecture.
> > >    Is GM selected per domain?
> >
> > The answer is application policy specific. The GO decides what is the
> > "right" policy, and encodes the policy token to authorize the S-GCKS
> > subset within the overall group membership.
> >
> > For example, composite groups could be organized to have a S-GCKS per
> > homogeneous sub-group. Again, what attributes constitute a "sub-group" for
> > a composite group is application specific.
>
> Why is the definition of "Sub-groups" application specific? Do you mean the
> type of application shall define the sub-group? I am not sure why this
> should be so.

The Group Owner gets to decide this policy for each group. The criteria
for S-GCKS can be anything:

- scalability: 1 S-GCKS per 1,000 GM

- divide up a group along administrative domain boundaries, S-GCKS per
domain

- composite group: S-GCKS per sub-group.

- picked at random from a dart board, so long as that GM is considered
trustworthy in that S-GCKS role o;)

in other words, GSAKMP provides the tools to do it any way that makes
sense to the GO.

>
> >    - What if there is only a single GM (in each of the distributed
> >    domains) who wants to access the content? And what happens for
> indivduals on
> >    the internet?
>
> I don't understand this question.
>
> What I wanted to ask was if GSAKMP is only suitable when different corporate
> LANs want to share secure multicast content or can it be also used over the
> internet - say a company decides to offer Secure multicast video streaming
> which should be accessible to any user on the internet. How is a S-GSKC
> selected then? Note here that users may connect from any part of the world
> at any time. Who can be an S-GCKS in such a scenario?

Discovery of S-GCKS is yet another question for which there is no "one
size fits all" answer. See RFC 4535 section 4.3 for a survey of methods.

> >    - Also what happens if the GM acting as the S-GCKS decides to leave?
>
> This answer is also application security policy specific.
>
> Usually a S-GCKS doesn't leave until after its sub-group reaches an empty
> membership condition.
>
> If the S-GCKS is a GM (hence an end user am I correct in saying this), I am
> not sure why it may not leave, unless GM is not an end user but another
> server or router that is always on. Not sure if this is possbile though.

Accepting the S-GCKS role implies taking responsibility for the
sub-group's membership management throughout a sub-group's lifespan. One
part of that responsibility is the LKH key server for the sub-group. In
that sense, S-GCKS are indeed a superset of an ordinary Group Member.

However, as explained in RFC 4535 section 4.4.6, any Group Member must be
prepared to accept becoming a S-GCKS if the GO authorized it AND local
policy permits executing in that mode.

       George


------=_Part_1915_30027796.1154077708359-- --===============0938112673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0938112673==-- From msec-bounces@ietf.org Fri Jul 28 05:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OKd-0007Pj-7e; Fri, 28 Jul 2006 05:08:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6OKb-0007Pe-Ro for msec@ietf.org; Fri, 28 Jul 2006 05:08:29 -0400 Received: from nf-out-0910.google.com ([64.233.182.189]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6OKb-0002KX-9E for msec@ietf.org; Fri, 28 Jul 2006 05:08:29 -0400 Received: by nf-out-0910.google.com with SMTP id n15so153222nfc for ; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gCQy94BANAjDHAM/hhFpk1G6+laJDlfdBvJ2DwHbUj64nLNXG+vxxlgFDR3N40KsCnKsgIiboz9fMInTqu4a6chpBnNKxzEqL9NIMK5ZsUGaVsfgopKGsotoaSrGt0ni5Wuqn9s3meYiFTtx76/gPd+KeAR3takB8ulJbkOUnmA= Received: by 10.49.5.12 with SMTP id h12mr427848nfi; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) Received: by 10.49.57.18 with HTTP; Fri, 28 Jul 2006 02:08:28 -0700 (PDT) Message-ID: <4166af450607280208w29393c9dy14f3a0ead1b8ea8d@mail.gmail.com> Date: Fri, 28 Jul 2006 10:08:28 +0100 From: "Prashant Pillai" To: "George Gross" Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: MIME-Version: 1.0 References: <4166af450607270712j64b85b53m2d5dc088792091d8@mail.gmail.com> X-Spam-Score: 0.5 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0938112673==" Errors-To: msec-bounces@ietf.org --===============0938112673== Content-Type: multipart/alternative; boundary="----=_Part_1915_30027796.1154077708359" ------=_Part_1915_30027796.1154077708359 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi George Is the GM an end user (receiver of the multicast content) or can it be any device (some server/ router)? RFC 4535 states that the GM is one who has access to the group keys. Am I correct in saying that the GM is any device who is registered (out-of- band) with the GO and hence is present in the access list?... and this GM should authenticate itself before it can act as a S-GSKC or as an end user receiving the multicast content. Regards Prashant P.S. Thanx a lot for you helpful replies. On 7/27/06, George Gross wrote: > > Hi Prashant, > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > > > > - In the GSAKMP document, it is stated that a subset of the GMs > will > > > > be authorised to be S-GCKS. Is there any particular way in which > > > these GMs > > > > are selected? I am not sure how this is done in a distributed > > > architecture. > > > > Is GM selected per domain? > > > > > > The answer is application policy specific. The GO decides what is the > > > "right" policy, and encodes the policy token to authorize the S-GCKS > > > subset within the overall group membership. > > > > > > For example, composite groups could be organized to have a S-GCKS per > > > homogeneous sub-group. Again, what attributes constitute a "sub-group" > for > > > a composite group is application specific. > > > > Why is the definition of "Sub-groups" application specific? Do you mean > the > > type of application shall define the sub-group? I am not sure why this > > should be so. > > The Group Owner gets to decide this policy for each group. The criteria > for S-GCKS can be anything: > > - scalability: 1 S-GCKS per 1,000 GM > > - divide up a group along administrative domain boundaries, S-GCKS per > domain > > - composite group: S-GCKS per sub-group. > > - picked at random from a dart board, so long as that GM is considered > trustworthy in that S-GCKS role o;) > > in other words, GSAKMP provides the tools to do it any way that makes > sense to the GO. > > > > > > - What if there is only a single GM (in each of the distributed > > > domains) who wants to access the content? And what happens for > > indivduals on > > > the internet? > > > > I don't understand this question. > > > > What I wanted to ask was if GSAKMP is only suitable when different > corporate > > LANs want to share secure multicast content or can it be also used over > the > > internet - say a company decides to offer Secure multicast video > streaming > > which should be accessible to any user on the internet. How is a S-GSKC > > selected then? Note here that users may connect from any part of the > world > > at any time. Who can be an S-GCKS in such a scenario? > > Discovery of S-GCKS is yet another question for which there is no "one > size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > > > - Also what happens if the GM acting as the S-GCKS decides to > leave? > > > > This answer is also application security policy specific. > > > > Usually a S-GCKS doesn't leave until after its sub-group reaches an > empty > > membership condition. > > > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I > am > > not sure why it may not leave, unless GM is not an end user but another > > server or router that is always on. Not sure if this is possbile though. > > Accepting the S-GCKS role implies taking responsibility for the > sub-group's membership management throughout a sub-group's lifespan. One > part of that responsibility is the LKH key server for the sub-group. In > that sense, S-GCKS are indeed a superset of an ordinary Group Member. > > However, as explained in RFC 4535 section 4.4.6, any Group Member must be > prepared to accept becoming a S-GCKS if the GO authorized it AND local > policy permits executing in that mode. > > George > > ------=_Part_1915_30027796.1154077708359 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi George
 
Is the GM an end user (receiver of the multicast content) or can it be any device (some server/ router)? RFC 4535 states that the GM is one who has access to the group keys. Am I correct in saying that the GM is any device who is registered (out-of- band) with the GO and hence is present in the access list?... and this GM should authenticate itself before it can act as a S-GSKC or as an end user receiving the multicast content.
 
 
Regards
Prashant

P.S. Thanx a lot for you helpful replies.
 
 
On 7/27/06, George Gross <gmgross@nac.net> wrote:
Hi Prashant,

On Thu, 27 Jul 2006, Prashant Pillai wrote:

<snip for brevity>
> > >    - In the GSAKMP document, it is stated that a subset of the GMs will
> > >    be authorised to be S-GCKS. Is there any particular way in which
> > these GMs
> > >    are selected? I am not sure how this is done in a distributed
> > architecture.
> > >    Is GM selected per domain?
> >
> > The answer is application policy specific. The GO decides what is the
> > "right" policy, and encodes the policy token to authorize the S-GCKS
> > subset within the overall group membership.
> >
> > For example, composite groups could be organized to have a S-GCKS per
> > homogeneous sub-group. Again, what attributes constitute a "sub-group" for
> > a composite group is application specific.
>
> Why is the definition of "Sub-groups" application specific? Do you mean the
> type of application shall define the sub-group? I am not sure why this
> should be so.

The Group Owner gets to decide this policy for each group. The criteria
for S-GCKS can be anything:

- scalability: 1 S-GCKS per 1,000 GM

- divide up a group along administrative domain boundaries, S-GCKS per
domain

- composite group: S-GCKS per sub-group.

- picked at random from a dart board, so long as that GM is considered
trustworthy in that S-GCKS role o;)

in other words, GSAKMP provides the tools to do it any way that makes
sense to the GO.

>
> >    - What if there is only a single GM (in each of the distributed
> >    domains) who wants to access the content? And what happens for
> indivduals on
> >    the internet?
>
> I don't understand this question.
>
> What I wanted to ask was if GSAKMP is only suitable when different corporate
> LANs want to share secure multicast content or can it be also used over the
> internet - say a company decides to offer Secure multicast video streaming
> which should be accessible to any user on the internet. How is a S-GSKC
> selected then? Note here that users may connect from any part of the world
> at any time. Who can be an S-GCKS in such a scenario?

Discovery of S-GCKS is yet another question for which there is no "one
size fits all" answer. See RFC 4535 section 4.3 for a survey of methods.

> >    - Also what happens if the GM acting as the S-GCKS decides to leave?
>
> This answer is also application security policy specific.
>
> Usually a S-GCKS doesn't leave until after its sub-group reaches an empty
> membership condition.
>
> If the S-GCKS is a GM (hence an end user am I correct in saying this), I am
> not sure why it may not leave, unless GM is not an end user but another
> server or router that is always on. Not sure if this is possbile though.

Accepting the S-GCKS role implies taking responsibility for the
sub-group's membership management throughout a sub-group's lifespan. One
part of that responsibility is the LKH key server for the sub-group. In
that sense, S-GCKS are indeed a superset of an ordinary Group Member.

However, as explained in RFC 4535 section 4.4.6, any Group Member must be
prepared to accept becoming a S-GCKS if the GO authorized it AND local
policy permits executing in that mode.

       George


------=_Part_1915_30027796.1154077708359-- --===============0938112673== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec --===============0938112673==-- From msec-bounces@ietf.org Fri Jul 28 08:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rs1-0006Bc-Vl; Fri, 28 Jul 2006 08:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rs0-0006BX-Cw for msec@ietf.org; Fri, 28 Jul 2006 08:55:12 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6Rrz-0005W0-1I for msec@ietf.org; Fri, 28 Jul 2006 08:55:12 -0400 Received: (qmail 33893 invoked by uid 0); 28 Jul 2006 08:55:10 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 28 Jul 2006 08:55:10 -0400 Received: (qmail 81302 invoked from network); 28 Jul 2006 08:55:09 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 28 Jul 2006 08:55:09 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6S99AW08085; Fri, 28 Jul 2006 05:09:10 -0400 Date: Fri, 28 Jul 2006 05:09:10 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607280208w29393c9dy14f3a0ead1b8ea8d@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Fri, 28 Jul 2006, Prashant Pillai wrote: > Hi George > > Is the GM an end user (receiver of the multicast content) or can it be any > device (some server/ router)? RFC 4535 states that the GM is one who has > access to the group keys. GSAKMP does not care whether a GM is a human carrying a smart card versus a server/router device with a secure cryptographic storage. What matters is that during the registration protocol exchange the GM proves possession of the signature private key for the identity asserted in the public key certificate. > Am I correct in saying that the GM is any device > who is registered (out-of- band) with the GO and hence is present in the > access list?... The word "registered" is misleading, a GM would be more accurately said to be "authorized" by the GO. The GM would have registered with a PKI Certificate Authority or Registration Authority as part of the PKI enrollment process to get its public key certificate. Yes, the GO must know the GM's identity within the PKI being used by a group. The GO adds the GM's identity to the group access list before signing and distributing the PT. > and this GM should authenticate itself before it can act as > a S-GSKC or as an end user receiving the multicast content. Yes, GM authentication occurs during the GSAKMP registration protocol exchange. George > > > Regards > Prashant > > P.S. Thanx a lot for you helpful replies. > > > On 7/27/06, George Gross wrote: > > > > Hi Prashant, > > > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > > > > > > > - In the GSAKMP document, it is stated that a subset of the GMs > > will > > > > > be authorised to be S-GCKS. Is there any particular way in which > > > > these GMs > > > > > are selected? I am not sure how this is done in a distributed > > > > architecture. > > > > > Is GM selected per domain? > > > > > > > > The answer is application policy specific. The GO decides what is the > > > > "right" policy, and encodes the policy token to authorize the S-GCKS > > > > subset within the overall group membership. > > > > > > > > For example, composite groups could be organized to have a S-GCKS per > > > > homogeneous sub-group. Again, what attributes constitute a "sub-group" > > for > > > > a composite group is application specific. > > > > > > Why is the definition of "Sub-groups" application specific? Do you mean > > the > > > type of application shall define the sub-group? I am not sure why this > > > should be so. > > > > The Group Owner gets to decide this policy for each group. The criteria > > for S-GCKS can be anything: > > > > - scalability: 1 S-GCKS per 1,000 GM > > > > - divide up a group along administrative domain boundaries, S-GCKS per > > domain > > > > - composite group: S-GCKS per sub-group. > > > > - picked at random from a dart board, so long as that GM is considered > > trustworthy in that S-GCKS role o;) > > > > in other words, GSAKMP provides the tools to do it any way that makes > > sense to the GO. > > > > > > > > > - What if there is only a single GM (in each of the distributed > > > > domains) who wants to access the content? And what happens for > > > indivduals on > > > > the internet? > > > > > > I don't understand this question. > > > > > > What I wanted to ask was if GSAKMP is only suitable when different > > corporate > > > LANs want to share secure multicast content or can it be also used over > > the > > > internet - say a company decides to offer Secure multicast video > > streaming > > > which should be accessible to any user on the internet. How is a S-GSKC > > > selected then? Note here that users may connect from any part of the > > world > > > at any time. Who can be an S-GCKS in such a scenario? > > > > Discovery of S-GCKS is yet another question for which there is no "one > > size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > > > > > - Also what happens if the GM acting as the S-GCKS decides to > > leave? > > > > > > This answer is also application security policy specific. > > > > > > Usually a S-GCKS doesn't leave until after its sub-group reaches an > > empty > > > membership condition. > > > > > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I > > am > > > not sure why it may not leave, unless GM is not an end user but another > > > server or router that is always on. Not sure if this is possbile though. > > > > Accepting the S-GCKS role implies taking responsibility for the > > sub-group's membership management throughout a sub-group's lifespan. One > > part of that responsibility is the LKH key server for the sub-group. In > > that sense, S-GCKS are indeed a superset of an ordinary Group Member. > > > > However, as explained in RFC 4535 section 4.4.6, any Group Member must be > > prepared to accept becoming a S-GCKS if the GO authorized it AND local > > policy permits executing in that mode. > > > > George > > > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Fri Jul 28 08:55:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rs1-0006Bc-Vl; Fri, 28 Jul 2006 08:55:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Rs0-0006BX-Cw for msec@ietf.org; Fri, 28 Jul 2006 08:55:12 -0400 Received: from smtp-out2.oct.nac.net ([209.123.233.212]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6Rrz-0005W0-1I for msec@ietf.org; Fri, 28 Jul 2006 08:55:12 -0400 Received: (qmail 33893 invoked by uid 0); 28 Jul 2006 08:55:10 -0400 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 28 Jul 2006 08:55:10 -0400 Received: (qmail 81302 invoked from network); 28 Jul 2006 08:55:09 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 28 Jul 2006 08:55:09 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k6S99AW08085; Fri, 28 Jul 2006 05:09:10 -0400 Date: Fri, 28 Jul 2006 05:09:10 -0400 (EDT) From: George Gross To: Prashant Pillai Subject: Re: [MSEC] distributed GSAKMP In-Reply-To: <4166af450607280208w29393c9dy14f3a0ead1b8ea8d@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: msec@ietf.org X-BeenThere: msec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multicast Security List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: msec-bounces@ietf.org Hi Prashant, On Fri, 28 Jul 2006, Prashant Pillai wrote: > Hi George > > Is the GM an end user (receiver of the multicast content) or can it be any > device (some server/ router)? RFC 4535 states that the GM is one who has > access to the group keys. GSAKMP does not care whether a GM is a human carrying a smart card versus a server/router device with a secure cryptographic storage. What matters is that during the registration protocol exchange the GM proves possession of the signature private key for the identity asserted in the public key certificate. > Am I correct in saying that the GM is any device > who is registered (out-of- band) with the GO and hence is present in the > access list?... The word "registered" is misleading, a GM would be more accurately said to be "authorized" by the GO. The GM would have registered with a PKI Certificate Authority or Registration Authority as part of the PKI enrollment process to get its public key certificate. Yes, the GO must know the GM's identity within the PKI being used by a group. The GO adds the GM's identity to the group access list before signing and distributing the PT. > and this GM should authenticate itself before it can act as > a S-GSKC or as an end user receiving the multicast content. Yes, GM authentication occurs during the GSAKMP registration protocol exchange. George > > > Regards > Prashant > > P.S. Thanx a lot for you helpful replies. > > > On 7/27/06, George Gross wrote: > > > > Hi Prashant, > > > > On Thu, 27 Jul 2006, Prashant Pillai wrote: > > > > > > > > > - In the GSAKMP document, it is stated that a subset of the GMs > > will > > > > > be authorised to be S-GCKS. Is there any particular way in which > > > > these GMs > > > > > are selected? I am not sure how this is done in a distributed > > > > architecture. > > > > > Is GM selected per domain? > > > > > > > > The answer is application policy specific. The GO decides what is the > > > > "right" policy, and encodes the policy token to authorize the S-GCKS > > > > subset within the overall group membership. > > > > > > > > For example, composite groups could be organized to have a S-GCKS per > > > > homogeneous sub-group. Again, what attributes constitute a "sub-group" > > for > > > > a composite group is application specific. > > > > > > Why is the definition of "Sub-groups" application specific? Do you mean > > the > > > type of application shall define the sub-group? I am not sure why this > > > should be so. > > > > The Group Owner gets to decide this policy for each group. The criteria > > for S-GCKS can be anything: > > > > - scalability: 1 S-GCKS per 1,000 GM > > > > - divide up a group along administrative domain boundaries, S-GCKS per > > domain > > > > - composite group: S-GCKS per sub-group. > > > > - picked at random from a dart board, so long as that GM is considered > > trustworthy in that S-GCKS role o;) > > > > in other words, GSAKMP provides the tools to do it any way that makes > > sense to the GO. > > > > > > > > > - What if there is only a single GM (in each of the distributed > > > > domains) who wants to access the content? And what happens for > > > indivduals on > > > > the internet? > > > > > > I don't understand this question. > > > > > > What I wanted to ask was if GSAKMP is only suitable when different > > corporate > > > LANs want to share secure multicast content or can it be also used over > > the > > > internet - say a company decides to offer Secure multicast video > > streaming > > > which should be accessible to any user on the internet. How is a S-GSKC > > > selected then? Note here that users may connect from any part of the > > world > > > at any time. Who can be an S-GCKS in such a scenario? > > > > Discovery of S-GCKS is yet another question for which there is no "one > > size fits all" answer. See RFC 4535 section 4.3 for a survey of methods. > > > > > > - Also what happens if the GM acting as the S-GCKS decides to > > leave? > > > > > > This answer is also application security policy specific. > > > > > > Usually a S-GCKS doesn't leave until after its sub-group reaches an > > empty > > > membership condition. > > > > > > If the S-GCKS is a GM (hence an end user am I correct in saying this), I > > am > > > not sure why it may not leave, unless GM is not an end user but another > > > server or router that is always on. Not sure if this is possbile though. > > > > Accepting the S-GCKS role implies taking responsibility for the > > sub-group's membership management throughout a sub-group's lifespan. One > > part of that responsibility is the LKH key server for the sub-group. In > > that sense, S-GCKS are indeed a superset of an ordinary Group Member. > > > > However, as explained in RFC 4535 section 4.4.6, any Group Member must be > > prepared to accept becoming a S-GCKS if the GO authorized it AND local > > policy permits executing in that mode. > > > > George > > > > > _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec