From 888momo444@docomo.ne.jp Sat Feb 03 05:22:47 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDI2h-0005eV-6j for msec-archive@ietf.org; Sat, 03 Feb 2007 05:22:47 -0500 Received: from [220.194.47.148] (helo=kimu03.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDI2f-0008Jj-Of for msec-archive@ietf.org; Sat, 03 Feb 2007 05:22:47 -0500 Subject: =?ISO-2022-JP?B?grGC8YLJgr+CzYFBU05TgWmXoIFqiV6JY46WlrGLx4LFgreBQg==?= From: SNS（裏）運営事務局 To: msec-archive@ietf.org Message-ID: 20070203190749 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Sat, 3 Feb 2007 19:07:50 +0900 (JST) X-Spam-Score: 3.4 (+++) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 仁美　さんがあなたを セックスフレンドネットワーキングサイト SNS（裏）へ招待しています。 メッセージ： 『さっき話ししたＳＮＳですー。 いろんな人がいるから気軽に話しかけられるから入ってみてください☆彡 ここも招待制だから私も友達の和美ちゃんから招待されたばかりであんまり わからないけどとにかく面白いよ☆彡 すこしＨだけどね('-')　自己紹介メール書いてくれたら皆に紹介するから！』 下記のURLより仁美さんの登録画面をご覧いただけます。 ↓こちらから招待者のsns（裏）トップページを見ることができます。 http://gyt.pupu.jp/848908.htm ■□■　コミュニティ・エンターテイメント　　　　　　　　　　　　■□■ □■□　セックスフレンドネットワーキングサイト　SNS（裏）って何？　□■□ SNS（裏）は、メンバーより招待された方のみで構成されている、 日本初のセックスフレンドネットワーキングサイトです。 ■SNS（裏）ならこれまで以上にセフレ関係を活性化できる 信頼できる旧知の友人、お知り合いとのセックスライフの活性化を図るさまざまな ツールをご用意しています。 ■「友人の友人」と交流できる SNS（裏）を使えば友人同士のネットワークをたどって「友人の友人」との交流が 簡単にできます。そこにはあなたの友人から繋がる信頼できるネットワークが 形成されています。SNS（裏）はどこかで繋がっている人同士が集まるコミュニティ であり、これがソーシャルネットワーキングの特徴です。 ■SNS（裏）なら日記の読み書き、これまでご利用の日記の公開ができる みなさんは日記を公開することによって友人やSNS（裏）に登録している人々に多くの 情報を発信することが可能です。さらにこれまで使用されていた他の日記・ブログ を使うか、SNS（裏）の日記を使うかを選択することができます。 SNS（裏）へ参加↓ http://gyt.pupu.jp/848908.htm それでは、参加を心よりお待ちしております。 ― SNS（裏） ――――――――――――――――――― コミュニティ・エンターテイメント SNS（裏） URL ：http://gyt.pupu.jp/ 運営会社 ： 株式会社SNS ――――――――――――――――――――――――― From 777momo333@docomo.ne.jp Sun Feb 04 21:29:10 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDtbS-000692-VG for msec-archive@megatron.ietf.org; Sun, 04 Feb 2007 21:29:10 -0500 Received: from [220.194.47.148] (helo=kimu03.alpha.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDtbR-0000YD-BK for msec-archive@megatron.ietf.org; Sun, 04 Feb 2007 21:29:10 -0500 Subject: =?ISO-2022-JP?B?g4GBW4OLgqCC6IKqgsaCpIKygrSCooLcgrWCvYH0?= From: 瑞奈 To: msec-archive@megatron.ietf.org Message-ID: 20070205100009 Content-Type: text/plain; charset="SHIFT_JIS" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Date: Mon, 5 Feb 2007 10:00:30 +0900 (JST) X-Spam-Score: 3.4 (+++) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 お久し振りです。瑞奈です。 先日はメールありがとうございました。 返事が遅くなってしまい、申し訳ありません。 前のメールで質問されていた仕事の話ですが・・・ 私は専業主婦なんです。 去年の12月からずっと家のことをやってて、それで忙しかったんです。 家事は楽しいんですが、さすがに疲れが・・・（＞＜ こんな生活なので出会いもないし、誰かに甘えたくなっちゃう事も多くて。 それで、急にこんな事をいうと変に思われるかもしれませんが 一度会ってお話をしたいのですが、ご迷惑でしょうか？ 私は世田谷区に住んでいる31歳です。 一緒にゴハンを食べたり、たくさんお話がしたいです♪ できれば今週末、新宿か渋谷あたりが私は都合がいいのですが いかがでしょうか？ http://jiew.boo.jp/848908.htm 最近、このサイトを利用しているので ここからメールを下さいませんか？ mixiもやっているのですが、こちらの方が居心地がいいので このサイトばかりを使ってます（＾＾； それでは、お返事をお待ちしていますね。 瑞奈 From msec-bounces@ietf.org Mon Feb 05 12:38:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7mj-0002YZ-9V; Mon, 05 Feb 2007 12:37:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7mh-0002YQ-JC for msec@ietf.org; Mon, 05 Feb 2007 12:37:43 -0500 Received: from lvs00-fl-n08.ftl.affinity.com ([216.219.253.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7mg-0007sY-Ae for msec@ietf.org; Mon, 05 Feb 2007 12:37:43 -0500 Received: ("??"@ams008.ftl.affinity.com) by ams008.ftl.affinity.com id S364138AbXBERhl for ; Mon, 5 Feb 2007 12:37:41 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 05 Feb 2007 12:37:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [MSEC] IPsec composite group ID, was MSEC status update (fwd) 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, you had inquired about the ID status for: > IV. > TESLA-ALC-NORM: What is the status on this? > draft-ietf-msec-ipsec-composite-group: Ditto! The draft-ietf-msec-ipsec-composite-group Internet Draft is being updated with the IETF revised boilerplate text. Once that draft version publishes, Haitham and I would like it to goto MSEC WGLC. tia, George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 05 12:38:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7mj-0002YZ-9V; Mon, 05 Feb 2007 12:37:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE7mh-0002YQ-JC for msec@ietf.org; Mon, 05 Feb 2007 12:37:43 -0500 Received: from lvs00-fl-n08.ftl.affinity.com ([216.219.253.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE7mg-0007sY-Ae for msec@ietf.org; Mon, 05 Feb 2007 12:37:43 -0500 Received: ("??"@ams008.ftl.affinity.com) by ams008.ftl.affinity.com id S364138AbXBERhl for ; Mon, 5 Feb 2007 12:37:41 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 05 Feb 2007 12:37:40 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [MSEC] IPsec composite group ID, was MSEC status update (fwd) 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, you had inquired about the ID status for: > IV. > TESLA-ALC-NORM: What is the status on this? > draft-ietf-msec-ipsec-composite-group: Ditto! The draft-ietf-msec-ipsec-composite-group Internet Draft is being updated with the IETF revised boilerplate text. Once that draft version publishes, Haitham and I would like it to goto MSEC WGLC. tia, George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 05 13:32:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8dH-0007rf-NX; Mon, 05 Feb 2007 13:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8dG-0007rZ-Td for msec@ietf.org; Mon, 05 Feb 2007 13:32:02 -0500 Received: from lvs00-fl-n04.ftl.affinity.com ([216.219.253.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8dF-0001QX-KG for msec@ietf.org; Mon, 05 Feb 2007 13:32:02 -0500 Received: ("??"@ams004.ftl.affinity.com) by ams004.ftl.affinity.com id S373524AbXBESa1 for ; Mon, 5 Feb 2007 13:30:27 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 05 Feb 2007 13:30:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: gmgross@identaware.com Subject: [MSEC] weis-esp-group-counter, was MSEC status update (fwd) 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 Brian and Lakshminath, > V. > New work (to be adopted after asking for group's opinion): > draft-weis-esp-group-counter-cipher-00: Ditto. I do not have a strong objection to this draft being adopted as a MSEC working group item. However, there are several questions (problems?) that I wondered about when I did a quick superficial review of this draft. 1) A fundamental problem is nonce or IV re-use, as recently discussed at length on CFRG. Wei Dai posted an good summary of those discussions and what to do about this problem about a week ago. I would suggest that this draft should include that guidance in its security considerations. That said, I suspect the risk of compromise is magnified in direct proportion to the size of the group membership. Instead of two endpoints, there are "N" endpoints that could accidently re-use a {SID, SSIV} pair, and this needs to be emphasized by this draft. There were about two dozen CFRG e-mail exchanges about random number generation, counter management, virtual machine interactions, and re-boot scenarios. At the least, the Sender-Specific IV (SSIV) field must be saved in a non-volatile storage after each use to avoid the scenario where a re-boot causes accidental {SID, SSIV} re-use. That way if a member re-boots then re-joins the same group, then it MUST also restart its SSIV at the last value used plus one. This is only one example. There are other cases mentioned by CFRG that need documentation. Perhaps the SID and SSIV must be qualified by a third field assigned by the GCKS, a "registration instance" counter? 2) A second problem is the inability to scale to large groups because the per sender state that receivers must maintain to enforce anti-replay services. The draft does not mention anti-replay service or how it interacts in this multi-sender group scenario. The draft must state that anti-replay service is not recommended, or else explain how it is done such that it scales to a large group. 3) The draft as written assumes that there is only a single cryptographic group and a single omnipotent GCKS. It seems to preclude any easy extension or accommodation for composite groups or distributed S-GCKS operations. In particular, the requirements in section 4 could be a source of complexity. Is an endpoint always required to interact with the same S-GCKS? Are all S-GCKS expected to know the SID of every potential group member? 4) The assertion made in section 6, the Security Considerations, that the security is equivalent to that of a single sender is not true and should be replaced with text along the lines described above. hth, George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 05 13:32:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8dH-0007rf-NX; Mon, 05 Feb 2007 13:32:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HE8dG-0007rZ-Td for msec@ietf.org; Mon, 05 Feb 2007 13:32:02 -0500 Received: from lvs00-fl-n04.ftl.affinity.com ([216.219.253.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HE8dF-0001QX-KG for msec@ietf.org; Mon, 05 Feb 2007 13:32:02 -0500 Received: ("??"@ams004.ftl.affinity.com) by ams004.ftl.affinity.com id S373524AbXBESa1 for ; Mon, 5 Feb 2007 13:30:27 -0500 From: gmgietf@identaware.com To: msec@ietf.org Date: Mon, 05 Feb 2007 13:30:27 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: gmgross@identaware.com Subject: [MSEC] weis-esp-group-counter, was MSEC status update (fwd) 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 Brian and Lakshminath, > V. > New work (to be adopted after asking for group's opinion): > draft-weis-esp-group-counter-cipher-00: Ditto. I do not have a strong objection to this draft being adopted as a MSEC working group item. However, there are several questions (problems?) that I wondered about when I did a quick superficial review of this draft. 1) A fundamental problem is nonce or IV re-use, as recently discussed at length on CFRG. Wei Dai posted an good summary of those discussions and what to do about this problem about a week ago. I would suggest that this draft should include that guidance in its security considerations. That said, I suspect the risk of compromise is magnified in direct proportion to the size of the group membership. Instead of two endpoints, there are "N" endpoints that could accidently re-use a {SID, SSIV} pair, and this needs to be emphasized by this draft. There were about two dozen CFRG e-mail exchanges about random number generation, counter management, virtual machine interactions, and re-boot scenarios. At the least, the Sender-Specific IV (SSIV) field must be saved in a non-volatile storage after each use to avoid the scenario where a re-boot causes accidental {SID, SSIV} re-use. That way if a member re-boots then re-joins the same group, then it MUST also restart its SSIV at the last value used plus one. This is only one example. There are other cases mentioned by CFRG that need documentation. Perhaps the SID and SSIV must be qualified by a third field assigned by the GCKS, a "registration instance" counter? 2) A second problem is the inability to scale to large groups because the per sender state that receivers must maintain to enforce anti-replay services. The draft does not mention anti-replay service or how it interacts in this multi-sender group scenario. The draft must state that anti-replay service is not recommended, or else explain how it is done such that it scales to a large group. 3) The draft as written assumes that there is only a single cryptographic group and a single omnipotent GCKS. It seems to preclude any easy extension or accommodation for composite groups or distributed S-GCKS operations. In particular, the requirements in section 4 could be a source of complexity. Is an endpoint always required to interact with the same S-GCKS? Are all S-GCKS expected to know the SID of every potential group member? 4) The assertion made in section 6, the Security Considerations, that the security is equivalent to that of a single sender is not true and should be replaced with text along the lines described above. hth, George _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Feb 05 19:22:26 2007 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEE6M-0006OU-DK for msec-archive@lists.ietf.org; Mon, 05 Feb 2007 19:22:26 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEE6L-0003oZ-45 for msec-archive@lists.ietf.org; Mon, 05 Feb 2007 19:22:26 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B6F922C872; Mon, 5 Feb 2007 19:22:18 -0500 (EST) 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 E74A42CA1F for ; Mon, 5 Feb 2007 19:22:16 -0500 (EST) Received: (qmail 71866 invoked by uid 3269); 6 Feb 2007 00:22:16 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 71863 invoked from network); 6 Feb 2007 00:22:16 -0000 Received: from mailwash15.pair.com (66.39.2.15) by klesh.pair.com with SMTP; 6 Feb 2007 00:22:16 -0000 Received: from localhost (localhost [127.0.0.1]) by mailwash15.pair.com (Postfix) with SMTP id D67ADE9D23 for ; Mon, 5 Feb 2007 19:22:16 -0500 (EST) Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by mailwash15.pair.com (Postfix) with ESMTP id AAE21E9D13 for ; Mon, 5 Feb 2007 19:22:16 -0500 (EST) Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l160MFHK030837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Feb 2007 16:22:15 -0800 Received: from [129.46.173.183] (ldondeti.na.qualcomm.com [129.46.173.183]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l160MEiQ020314 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 16:22:14 -0800 (PST) Message-ID: <45C7C9EE.3020401@qualcomm.com> Date: Mon, 05 Feb 2007 16:21:02 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@securemulticast.org Subject: [MSEC] This list is now closed X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Folks, We have moved to msec@ietf.org a while ago and the IETF web page will soon reflect the correct subscription information: General Discussion: msec@ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/msec Archive: http://www.ietf.org/mail-archive/web/msec/current/index.html I think all of you are already subscribed to the msec@ietf.org list (I have done that myself). Please go to https://www1.ietf.org/mailman/listinfo/msec to verify if you are in doubt. thanks, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 00:30:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIu9-0004IU-5z; Tue, 06 Feb 2007 00:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIu7-0004IO-NX for msec@ietf.org; Tue, 06 Feb 2007 00:30:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEIu5-0007lq-Bo for msec@ietf.org; Tue, 06 Feb 2007 00:30:07 -0500 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 l165U3Jl015370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 21:30:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l165U1x0026083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 21:30:02 -0800 Message-ID: <45C81212.3040800@qualcomm.com> Date: Mon, 05 Feb 2007 21:28:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: gmgietf@identaware.com Subject: Re: [MSEC] IPsec composite group ID, was MSEC status update (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Thanks for the update George. Please revise and submit soon. regards, Lakshminath gmgietf@identaware.com wrote: > Hi Lakshminath, > you had inquired about the ID status for: >> IV. >> TESLA-ALC-NORM: What is the status on this? >> draft-ietf-msec-ipsec-composite-group: Ditto! > > The draft-ietf-msec-ipsec-composite-group Internet Draft is being > updated with the IETF revised boilerplate text. Once that draft version > publishes, Haitham and I would like it to goto MSEC WGLC. > tia, > George > > > _______________________________________________ > 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 Feb 06 00:30:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIu9-0004IU-5z; Tue, 06 Feb 2007 00:30:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEIu7-0004IO-NX for msec@ietf.org; Tue, 06 Feb 2007 00:30:07 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEIu5-0007lq-Bo for msec@ietf.org; Tue, 06 Feb 2007 00:30:07 -0500 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 l165U3Jl015370 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 21:30:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l165U1x0026083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 21:30:02 -0800 Message-ID: <45C81212.3040800@qualcomm.com> Date: Mon, 05 Feb 2007 21:28:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: gmgietf@identaware.com Subject: Re: [MSEC] IPsec composite group ID, was MSEC status update (fwd) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Thanks for the update George. Please revise and submit soon. regards, Lakshminath gmgietf@identaware.com wrote: > Hi Lakshminath, > you had inquired about the ID status for: >> IV. >> TESLA-ALC-NORM: What is the status on this? >> draft-ietf-msec-ipsec-composite-group: Ditto! > > The draft-ietf-msec-ipsec-composite-group Internet Draft is being > updated with the IETF revised boilerplate text. Once that draft version > publishes, Haitham and I would like it to goto MSEC WGLC. > tia, > George > > > _______________________________________________ > 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 Feb 06 01:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJgV-0001tD-F1; Tue, 06 Feb 2007 01:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJgU-0001qG-23; Tue, 06 Feb 2007 01:20:06 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJgS-00027w-NK; Tue, 06 Feb 2007 01:20:06 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l166K3NZ014111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 22:20:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166K2qQ029062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 22:20:02 -0800 (PST) Message-ID: <45C81DCA.20100@qualcomm.com> Date: Mon, 05 Feb 2007 22:18:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipsec@ietf.org, Russ Housley Subject: [MSEC] WGLC on draft-ietf-msec-ipsec-extensions-04 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, This is a WG last call for comments on draft-ietf-msec-ipsec-extensions-04, ending on Feb 19th AOE. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 01:20:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJgV-0001tD-F1; Tue, 06 Feb 2007 01:20:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJgU-0001qG-23; Tue, 06 Feb 2007 01:20:06 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJgS-00027w-NK; Tue, 06 Feb 2007 01:20:06 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l166K3NZ014111 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 22:20:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166K2qQ029062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 22:20:02 -0800 (PST) Message-ID: <45C81DCA.20100@qualcomm.com> Date: Mon, 05 Feb 2007 22:18:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ipsec@ietf.org, Russ Housley Subject: [MSEC] WGLC on draft-ietf-msec-ipsec-extensions-04 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, This is a WG last call for comments on draft-ietf-msec-ipsec-extensions-04, ending on Feb 19th AOE. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 01:22:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJix-0003Xv-Gi; Tue, 06 Feb 2007 01:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJis-0003MT-R9 for msec@ietf.org; Tue, 06 Feb 2007 01:22:34 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJir-0003QS-GO for msec@ietf.org; Tue, 06 Feb 2007 01:22:34 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l166MWtK021745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Feb 2007 22:22:32 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166MV9G029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 22:22:32 -0800 (PST) Message-ID: <45C81E5F.2030006@qualcomm.com> Date: Mon, 05 Feb 2007 22:21:19 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [MSEC] WGLC on draft-ietf-msec-gdoi-update-01 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 and send your comments on draft-ietf-msec-gdoi-update-01. Please consider this a WGLC and send your comments before Feb 19, 2007 AOE. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 01:22:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJix-0003Xv-Gi; Tue, 06 Feb 2007 01:22:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJis-0003MT-R9 for msec@ietf.org; Tue, 06 Feb 2007 01:22:34 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJir-0003QS-GO for msec@ietf.org; Tue, 06 Feb 2007 01:22:34 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l166MWtK021745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Feb 2007 22:22:32 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166MV9G029607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 22:22:32 -0800 (PST) Message-ID: <45C81E5F.2030006@qualcomm.com> Date: Mon, 05 Feb 2007 22:21:19 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [MSEC] WGLC on draft-ietf-msec-gdoi-update-01 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 and send your comments on draft-ietf-msec-gdoi-update-01. Please consider this a WGLC and send your comments before Feb 19, 2007 AOE. thanks, Lakshminath _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 01:27:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJnn-0005wu-U7; Tue, 06 Feb 2007 01:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJnm-0005wS-6c for msec@ietf.org; Tue, 06 Feb 2007 01:27:38 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJnk-0005DS-PK for msec@ietf.org; Tue, 06 Feb 2007 01:27:38 -0500 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 l166RZgB014842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 22:27:36 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166RVQY003985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 22:27:32 -0800 Message-ID: <45C81F8C.5000307@qualcomm.com> Date: Mon, 05 Feb 2007 22:26:20 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org, Mark Baugher , adrian.rueegsegger@students.fhnw.ch Subject: Re: [MSEC] Any objections to adopting GDOI-SRTP as a work item? References: <45BEA80E.8070800@qualcomm.com> In-Reply-To: <45BEA80E.8070800@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: msec-bounces@ietf.org All, We have not received any objections to adopting this work. Let's do it. Mark and Adrian, Please submit the next revision as a WG draft. Is draft-ietf-msec-gdoi-srtp acceptable as the tag? Please confirm and I will send that request in to the Secretariat. Here are the relevant deadlines, so please respond soon. February 19, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (14:00 UTC/GMT) February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) Also, please let me know about the status of the work. How close to completion is the specification? Do you have an implementation in the works? We need an idea on target WGLC date. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > At the San Diego meeting, Mark presented GDOI-SRTP describing how to use > GDOI to setup SRTP crypto context. There was some discussion and a > couple of folks (Russ and me) volunteered to review the work. > > Please consider this a call for 1) gauging interest in this work and 2) > adopting this work as a work item in MSEC. > > Please send your comments before next Monday (Feb 5, 2007). > > 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 Tue Feb 06 01:27:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJnn-0005wu-U7; Tue, 06 Feb 2007 01:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJnm-0005wS-6c for msec@ietf.org; Tue, 06 Feb 2007 01:27:38 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJnk-0005DS-PK for msec@ietf.org; Tue, 06 Feb 2007 01:27:38 -0500 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 l166RZgB014842 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 5 Feb 2007 22:27:36 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166RVQY003985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2007 22:27:32 -0800 Message-ID: <45C81F8C.5000307@qualcomm.com> Date: Mon, 05 Feb 2007 22:26:20 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org, Mark Baugher , adrian.rueegsegger@students.fhnw.ch Subject: Re: [MSEC] Any objections to adopting GDOI-SRTP as a work item? References: <45BEA80E.8070800@qualcomm.com> In-Reply-To: <45BEA80E.8070800@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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: , Errors-To: msec-bounces@ietf.org All, We have not received any objections to adopting this work. Let's do it. Mark and Adrian, Please submit the next revision as a WG draft. Is draft-ietf-msec-gdoi-srtp acceptable as the tag? Please confirm and I will send that request in to the Secretariat. Here are the relevant deadlines, so please respond soon. February 19, Monday - Working Group Chair approval for initial document (Version -00) submissions appreciated by 09:00 ET (14:00 UTC/GMT) February 26, Monday - Internet Draft Cut-off for initial document (-00) submission by 09:00 ET (14:00 UTC/GMT) Also, please let me know about the status of the work. How close to completion is the specification? Do you have an implementation in the works? We need an idea on target WGLC date. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > At the San Diego meeting, Mark presented GDOI-SRTP describing how to use > GDOI to setup SRTP crypto context. There was some discussion and a > couple of folks (Russ and me) volunteered to review the work. > > Please consider this a call for 1) gauging interest in this work and 2) > adopting this work as a work item in MSEC. > > Please send your comments before next Monday (Feb 5, 2007). > > 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 Tue Feb 06 01:28:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJoE-00068v-Cv; Tue, 06 Feb 2007 01:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJoD-00068b-B4 for msec@ietf.org; Tue, 06 Feb 2007 01:28:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJoB-0005K7-Vq for msec@ietf.org; Tue, 06 Feb 2007 01:28:05 -0500 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 l166S3vp014939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Feb 2007 22:28:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166S2lO004069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 22:28:02 -0800 Message-ID: <45C81FAA.3090704@qualcomm.com> Date: Mon, 05 Feb 2007 22:26:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Subject: Re: [MSEC] Any objections to adopting TESLA-IPsec as a WG item References: <45BEA471.9080101@qualcomm.com> In-Reply-To: <45BEA471.9080101@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Ok, I will submit the next revision as a WG item. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > Please send any objections to adopting draft-dondeti-msec-ipsec-tesla-01 > as a WG item (I know, I know, my name is on there, but this is not my > pet topic or whatever. I am just advancing some leftover TESLA work > done by other WG contributors through the process). > > Please see http://www3.ietf.org/proceedings/06nov/minutes/msec.txt for > some more context. > > 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 Tue Feb 06 01:28:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJoE-00068v-Cv; Tue, 06 Feb 2007 01:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEJoD-00068b-B4 for msec@ietf.org; Tue, 06 Feb 2007 01:28:05 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEJoB-0005K7-Vq for msec@ietf.org; Tue, 06 Feb 2007 01:28:05 -0500 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 l166S3vp014939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 5 Feb 2007 22:28:03 -0800 Received: from [10.50.72.196] (qconnect-10-50-72-196.qualcomm.com [10.50.72.196]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l166S2lO004069 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Feb 2007 22:28:02 -0800 Message-ID: <45C81FAA.3090704@qualcomm.com> Date: Mon, 05 Feb 2007 22:26:50 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Subject: Re: [MSEC] Any objections to adopting TESLA-IPsec as a WG item References: <45BEA471.9080101@qualcomm.com> In-Reply-To: <45BEA471.9080101@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 Ok, I will submit the next revision as a WG item. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > Please send any objections to adopting draft-dondeti-msec-ipsec-tesla-01 > as a WG item (I know, I know, my name is on there, but this is not my > pet topic or whatever. I am just advancing some leftover TESLA work > done by other WG contributors through the process). > > Please see http://www3.ietf.org/proceedings/06nov/minutes/msec.txt for > some more context. > > 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 Tue Feb 06 04:45:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMsd-0008Li-29; Tue, 06 Feb 2007 04:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMsc-0008LZ-1w for msec@ietf.org; Tue, 06 Feb 2007 04:44:50 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEMsa-0001qk-By for msec@ietf.org; Tue, 06 Feb 2007 04:44:50 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD1009BBCAN8Y@szxga02-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JD100BS3CANNG@szxga02-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Received: from l52008 ([10.111.12.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD100MN4CAJ1H@szxml04-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Date: Tue, 06 Feb 2007 17:42:19 +0800 From: Liu Ya To: msec@ietf.org Message-id: <023c01c749d3$18568940$3f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdJ0xfm9YlVe2upTgCEjgEYTp8+4g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [MSEC] How about defining a set of GKM APIs? 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, Similar group keying features (e.g., group member register/key distribution/rekeying) are provided by serveral GKM protocols, including GDOI, MIKEY, GKDP, GSAKMP. They may be embodied either in a daemon (e.g., gdoid) or in a library (e.g., libmikey). The later usage case is suitable for programms that use the keying services and control the keying process itself. However, standard GKM APIs are unavailable now. Programmers will have to define the APIs themselves if they use group keying services. Issues of portability and code reusability emerge. Furthermore, code modifications are unavoidable when switching between different keying libraries. How about defining a set of GKM APIs to avoid such issues? Comments are welcome. Regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 04:45:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMsd-0008Li-29; Tue, 06 Feb 2007 04:44:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEMsc-0008LZ-1w for msec@ietf.org; Tue, 06 Feb 2007 04:44:50 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEMsa-0001qk-By for msec@ietf.org; Tue, 06 Feb 2007 04:44:50 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD1009BBCAN8Y@szxga02-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JD100BS3CANNG@szxga02-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Received: from l52008 ([10.111.12.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD100MN4CAJ1H@szxml04-in.huawei.com> for msec@ietf.org; Tue, 06 Feb 2007 17:42:23 +0800 (CST) Date: Tue, 06 Feb 2007 17:42:19 +0800 From: Liu Ya To: msec@ietf.org Message-id: <023c01c749d3$18568940$3f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdJ0xfm9YlVe2upTgCEjgEYTp8+4g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [MSEC] How about defining a set of GKM APIs? 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, Similar group keying features (e.g., group member register/key distribution/rekeying) are provided by serveral GKM protocols, including GDOI, MIKEY, GKDP, GSAKMP. They may be embodied either in a daemon (e.g., gdoid) or in a library (e.g., libmikey). The later usage case is suitable for programms that use the keying services and control the keying process itself. However, standard GKM APIs are unavailable now. Programmers will have to define the APIs themselves if they use group keying services. Issues of portability and code reusability emerge. Furthermore, code modifications are unavoidable when switching between different keying libraries. How about defining a set of GKM APIs to avoid such issues? Comments are welcome. Regards, Liu Ya _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Tue Feb 06 11:53:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETZT-00073N-IJ; Tue, 06 Feb 2007 11:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETZS-00073B-44 for msec@ietf.org; Tue, 06 Feb 2007 11:53:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HETZO-0008L0-Lq for msec@ietf.org; Tue, 06 Feb 2007 11:53:30 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2007 08:53:26 -0800 X-IronPort-AV: i="4.13,291,1167638400"; d="scan'208"; a="462555168:sNHT49203296" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l16GrOkQ017362; Tue, 6 Feb 2007 08:53:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l16GrIGm003230; Tue, 6 Feb 2007 08:53:24 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:53:19 -0800 Received: from [192.168.0.11] ([10.21.154.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:53:19 -0800 In-Reply-To: <45C81F8C.5000307@qualcomm.com> References: <45BEA80E.8070800@qualcomm.com> <45C81F8C.5000307@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97C8B84E-BB58-41AC-8772-249B61A6441F@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Any objections to adopting GDOI-SRTP as a work item? Date: Tue, 6 Feb 2007 08:53:15 -0800 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Feb 2007 16:53:19.0875 (UTC) FILETIME=[4E1BAD30:01C74A0F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1593; t=1170780804; x=1171644804; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20Any=20objections=20to=20adopting=20GDOI-SRTP =20as=20a=20work=20item? |Sender:=20; bh=SxNtZeYhJ9sm+WREi3dIqrjoo7wxvJgEdd6oAuMivy0=; b=1lvyX31QCzvnGAFlZIaDnL30Xk131hK7AgyCNefsSInnAnnVKtOVlYiy7WaJkKT0yhUQYTd9 2j290gDjT8uzI3mwCQDMYrMGzIXmd2NG5K0Uo5+IEC6pDWBCx8jY8BEF; Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: msec@ietf.org, =?ISO-8859-1?Q?Adrian-Ken_R=FCegsegger?= 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 On Feb 5, 2007, at 10:26 PM, Lakshminath Dondeti wrote: > All, > > We have not received any objections to adopting this work. Let's > do it. > > Mark and Adrian, > > Please submit the next revision as a WG draft. > > Is draft-ietf-msec-gdoi-srtp acceptable as the tag? Please confirm > and I will send that request in to the Secretariat. Here are the > relevant deadlines, so please respond soon. That's a fine name thanks, Mark > > February 19, Monday - Working Group Chair approval for initial > document (Version -00) submissions appreciated by 09:00 ET (14:00 > UTC/GMT) > February 26, Monday - Internet Draft Cut-off for initial document > (-00) submission by 09:00 ET (14:00 UTC/GMT) > > Also, please let me know about the status of the work. How close > to completion is the specification? Do you have an implementation > in the works? We need an idea on target WGLC date. > > thanks, > Lakshminath > > Lakshminath Dondeti wrote: >> Folks, >> At the San Diego meeting, Mark presented GDOI-SRTP describing how >> to use GDOI to setup SRTP crypto context. There was some >> discussion and a couple of folks (Russ and me) volunteered to >> review the work. >> Please consider this a call for 1) gauging interest in this work >> and 2) adopting this work as a work item in MSEC. >> Please send your comments before next Monday (Feb 5, 2007). >> 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 Tue Feb 06 11:53:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETZT-00073N-IJ; Tue, 06 Feb 2007 11:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HETZS-00073B-44 for msec@ietf.org; Tue, 06 Feb 2007 11:53:30 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HETZO-0008L0-Lq for msec@ietf.org; Tue, 06 Feb 2007 11:53:30 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 06 Feb 2007 08:53:26 -0800 X-IronPort-AV: i="4.13,291,1167638400"; d="scan'208"; a="462555168:sNHT49203296" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l16GrOkQ017362; Tue, 6 Feb 2007 08:53:24 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l16GrIGm003230; Tue, 6 Feb 2007 08:53:24 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:53:19 -0800 Received: from [192.168.0.11] ([10.21.154.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 08:53:19 -0800 In-Reply-To: <45C81F8C.5000307@qualcomm.com> References: <45BEA80E.8070800@qualcomm.com> <45C81F8C.5000307@qualcomm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97C8B84E-BB58-41AC-8772-249B61A6441F@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] Any objections to adopting GDOI-SRTP as a work item? Date: Tue, 6 Feb 2007 08:53:15 -0800 To: Lakshminath Dondeti X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 06 Feb 2007 16:53:19.0875 (UTC) FILETIME=[4E1BAD30:01C74A0F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1593; t=1170780804; x=1171644804; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20Any=20objections=20to=20adopting=20GDOI-SRTP =20as=20a=20work=20item? |Sender:=20; bh=SxNtZeYhJ9sm+WREi3dIqrjoo7wxvJgEdd6oAuMivy0=; b=1lvyX31QCzvnGAFlZIaDnL30Xk131hK7AgyCNefsSInnAnnVKtOVlYiy7WaJkKT0yhUQYTd9 2j290gDjT8uzI3mwCQDMYrMGzIXmd2NG5K0Uo5+IEC6pDWBCx8jY8BEF; Authentication-Results: sj-dkim-2; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: msec@ietf.org, =?ISO-8859-1?Q?Adrian-Ken_R=FCegsegger?= 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 On Feb 5, 2007, at 10:26 PM, Lakshminath Dondeti wrote: > All, > > We have not received any objections to adopting this work. Let's > do it. > > Mark and Adrian, > > Please submit the next revision as a WG draft. > > Is draft-ietf-msec-gdoi-srtp acceptable as the tag? Please confirm > and I will send that request in to the Secretariat. Here are the > relevant deadlines, so please respond soon. That's a fine name thanks, Mark > > February 19, Monday - Working Group Chair approval for initial > document (Version -00) submissions appreciated by 09:00 ET (14:00 > UTC/GMT) > February 26, Monday - Internet Draft Cut-off for initial document > (-00) submission by 09:00 ET (14:00 UTC/GMT) > > Also, please let me know about the status of the work. How close > to completion is the specification? Do you have an implementation > in the works? We need an idea on target WGLC date. > > thanks, > Lakshminath > > Lakshminath Dondeti wrote: >> Folks, >> At the San Diego meeting, Mark presented GDOI-SRTP describing how >> to use GDOI to setup SRTP crypto context. There was some >> discussion and a couple of folks (Russ and me) volunteered to >> review the work. >> Please consider this a call for 1) gauging interest in this work >> and 2) adopting this work as a work item in MSEC. >> Please send your comments before next Monday (Feb 5, 2007). >> 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 Feb 07 00:45:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEfbd-00066B-Md; Wed, 07 Feb 2007 00:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEfbc-00063B-Qo for msec@ietf.org; Wed, 07 Feb 2007 00:44:32 -0500 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 1HEfbb-0007XA-86 for msec@ietf.org; Wed, 07 Feb 2007 00:44:32 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2007 21:44:31 -0800 X-IronPort-AV: i="4.13,292,1167638400"; d="scan'208"; a="762010605:sNHT50203872" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l175iSX6016113; Tue, 6 Feb 2007 21:44:28 -0800 Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l175iSnF015571; Tue, 6 Feb 2007 21:44:28 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Weis Subject: Re: [MSEC] weis-esp-group-counter, was MSEC status update (fwd) Date: Tue, 6 Feb 2007 21:44:50 -0800 To: gmgietf@identaware.com X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4973; t=1170827068; x=1171691068; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[MSEC]=20weis-esp-group-counter, =20was=20MSEC=20statu s=20update=20(fwd) |Sender:=20; bh=m2qHMnjwz5aWGPbDcBR/3DNN1dLWbMHjajuJz+SqYvM=; b=uImQOP9xtSaqHoaka9eJuVjY4AtxwxGBJn2cw1GFmbJKSLP4C7Y1e5NbzmCtOg7RNNpInPkj mi3XWSsgEwKX+eiOERxv9oA6tgVx+7WVAotE6NInVBgP82/KULk7Aonf; Authentication-Results: sj-dkim-5; header.From=bew@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: msec@ietf.org, George Gross 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 George, Thanks for your review. Some comments are embedded below. On Feb 5, 2007, at 10:30 AM, gmgietf@identaware.com wrote: > Hi Brian and Lakshminath, > >> V. >> New work (to be adopted after asking for group's opinion): > > >> draft-weis-esp-group-counter-cipher-00: Ditto. > > I do not have a strong objection to this draft being adopted as a > MSEC working group item. However, there are several questions > (problems?) that I wondered about when I did a quick superficial > review of this draft. > 1) A fundamental problem is nonce or IV re-use, as recently > discussed at length on CFRG. Wei Dai posted an good summary of > those discussions and what to do about this problem about a week > ago. I would suggest that this draft should include that guidance > in its security considerations. That said, I suspect the risk of > compromise is magnified in direct proportion to the size of the > group membership. Instead of two endpoints, there are "N" endpoints > that could accidently re-use a {SID, SSIV} pair, and this needs to > be emphasized by this draft. There were about two dozen CFRG e-mail > exchanges about random number generation, counter management, > virtual machine interactions, and re-boot scenarios. At the least, > the Sender-Specific IV (SSIV) field must be saved in a non-volatile > storage after each use to avoid the scenario where a re-boot causes > accidental {SID, SSIV} re-use. That way if a member re-boots then > re-joins the same group, then it MUST also restart its SSIV at the > last value used plus one. This is only one example. There are other > cases mentioned by CFRG that need documentation. Perhaps the SID > and SSIV must be qualified by a third field assigned by the GCKS, a > "registration instance" counter? I'm aware of the CRFG thread, and will review it for additional security considerations text as you suggest. Regarding re-use of the SSIV, your suggestion may not be appropriate as there are some devices for which frequent writes to non-volatile storage (e.g., NVRAM) are not appropriate. It was our intention that re-joins would be detected by the GCKS during re-registration, and that it would take appropriate action. I'll review Section 4 and clarify this. > 2) A second problem is the inability to scale to large groups > because the per sender state that receivers must maintain to > enforce anti-replay services. The draft does not mention anti- > replay service or how it interacts in this multi-sender group > scenario. The draft must state that anti-replay service is not > recommended, or else explain how it is done such that it scales to > a large group. Describing anti-replay services would make sense for a draft that is defining how multi-sender AH or ESP should be deployed. But his draft has a more modest goal of describing how multi-sender counter-mode ciphers can be deployed. The draft-ietf-msec-ipsec-extensions I-D gives the guidance you mention above. This guidance is certainly relevent to the esp-group-counter draft, but I don't think this document needs to do more than reference that I-D. I can add text pointing readers to that document for guidance on multi-sender SAs. > 3) The draft as written assumes that there is only a single > cryptographic group and a single omnipotent GCKS. It seems to > preclude any easy extension or accommodation for composite groups > or distributed S-GCKS operations. In particular, the requirements > in section 4 could be a source of complexity. Is an endpoint always > required to interact with the same S-GCKS? Are all S-GCKS expected > to know the SID of every potential group member? We didn't intend to make restrictions regarding composite groups or distributed S-GCKS operations. But this is hard to answer without knowing exactly how the distributed GCKS system in a particular deployment works. > 4) The assertion made in section 6, the Security Considerations, > that the security is equivalent to that of a single sender is not > true and should be replaced with text along the lines described above. The actual sentence is: "When [this document's] recommendations are followed, the security of the crypto algorithms is equivalent to the conventional case in which there is a single sender." We believe that this is a true statement as long as the IVs are not reused (i.e., the recommendations in this document). But we'll certainly add points made on the CFRG thread as well, as you suggest. Thanks, Brian > hth, > George > > _______________________________________________ > 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 Wed Feb 07 00:45:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEfbd-00066B-Md; Wed, 07 Feb 2007 00:44:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEfbc-00063B-Qo for msec@ietf.org; Wed, 07 Feb 2007 00:44:32 -0500 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 1HEfbb-0007XA-86 for msec@ietf.org; Wed, 07 Feb 2007 00:44:32 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-1.cisco.com with ESMTP; 06 Feb 2007 21:44:31 -0800 X-IronPort-AV: i="4.13,292,1167638400"; d="scan'208"; a="762010605:sNHT50203872" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l175iSX6016113; Tue, 6 Feb 2007 21:44:28 -0800 Received: from [10.32.244.213] (stealth-10-32-244-213.cisco.com [10.32.244.213]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l175iSnF015571; Tue, 6 Feb 2007 21:44:28 -0800 (PST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Brian Weis Subject: Re: [MSEC] weis-esp-group-counter, was MSEC status update (fwd) Date: Tue, 6 Feb 2007 21:44:50 -0800 To: gmgietf@identaware.com X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4973; t=1170827068; x=1171691068; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=bew@cisco.com; z=From:=20Brian=20Weis=20 |Subject:=20Re=3A=20[MSEC]=20weis-esp-group-counter, =20was=20MSEC=20statu s=20update=20(fwd) |Sender:=20; bh=m2qHMnjwz5aWGPbDcBR/3DNN1dLWbMHjajuJz+SqYvM=; b=uImQOP9xtSaqHoaka9eJuVjY4AtxwxGBJn2cw1GFmbJKSLP4C7Y1e5NbzmCtOg7RNNpInPkj mi3XWSsgEwKX+eiOERxv9oA6tgVx+7WVAotE6NInVBgP82/KULk7Aonf; Authentication-Results: sj-dkim-5; header.From=bew@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: msec@ietf.org, George Gross 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 George, Thanks for your review. Some comments are embedded below. On Feb 5, 2007, at 10:30 AM, gmgietf@identaware.com wrote: > Hi Brian and Lakshminath, > >> V. >> New work (to be adopted after asking for group's opinion): > > >> draft-weis-esp-group-counter-cipher-00: Ditto. > > I do not have a strong objection to this draft being adopted as a > MSEC working group item. However, there are several questions > (problems?) that I wondered about when I did a quick superficial > review of this draft. > 1) A fundamental problem is nonce or IV re-use, as recently > discussed at length on CFRG. Wei Dai posted an good summary of > those discussions and what to do about this problem about a week > ago. I would suggest that this draft should include that guidance > in its security considerations. That said, I suspect the risk of > compromise is magnified in direct proportion to the size of the > group membership. Instead of two endpoints, there are "N" endpoints > that could accidently re-use a {SID, SSIV} pair, and this needs to > be emphasized by this draft. There were about two dozen CFRG e-mail > exchanges about random number generation, counter management, > virtual machine interactions, and re-boot scenarios. At the least, > the Sender-Specific IV (SSIV) field must be saved in a non-volatile > storage after each use to avoid the scenario where a re-boot causes > accidental {SID, SSIV} re-use. That way if a member re-boots then > re-joins the same group, then it MUST also restart its SSIV at the > last value used plus one. This is only one example. There are other > cases mentioned by CFRG that need documentation. Perhaps the SID > and SSIV must be qualified by a third field assigned by the GCKS, a > "registration instance" counter? I'm aware of the CRFG thread, and will review it for additional security considerations text as you suggest. Regarding re-use of the SSIV, your suggestion may not be appropriate as there are some devices for which frequent writes to non-volatile storage (e.g., NVRAM) are not appropriate. It was our intention that re-joins would be detected by the GCKS during re-registration, and that it would take appropriate action. I'll review Section 4 and clarify this. > 2) A second problem is the inability to scale to large groups > because the per sender state that receivers must maintain to > enforce anti-replay services. The draft does not mention anti- > replay service or how it interacts in this multi-sender group > scenario. The draft must state that anti-replay service is not > recommended, or else explain how it is done such that it scales to > a large group. Describing anti-replay services would make sense for a draft that is defining how multi-sender AH or ESP should be deployed. But his draft has a more modest goal of describing how multi-sender counter-mode ciphers can be deployed. The draft-ietf-msec-ipsec-extensions I-D gives the guidance you mention above. This guidance is certainly relevent to the esp-group-counter draft, but I don't think this document needs to do more than reference that I-D. I can add text pointing readers to that document for guidance on multi-sender SAs. > 3) The draft as written assumes that there is only a single > cryptographic group and a single omnipotent GCKS. It seems to > preclude any easy extension or accommodation for composite groups > or distributed S-GCKS operations. In particular, the requirements > in section 4 could be a source of complexity. Is an endpoint always > required to interact with the same S-GCKS? Are all S-GCKS expected > to know the SID of every potential group member? We didn't intend to make restrictions regarding composite groups or distributed S-GCKS operations. But this is hard to answer without knowing exactly how the distributed GCKS system in a particular deployment works. > 4) The assertion made in section 6, the Security Considerations, > that the security is equivalent to that of a single sender is not > true and should be replaced with text along the lines described above. The actual sentence is: "When [this document's] recommendations are followed, the security of the crypto algorithms is equivalent to the conventional case in which there is a single sender." We believe that this is a true statement as long as the IVs are not reused (i.e., the recommendations in this document). But we'll certainly add points made on the CFRG thread as well, as you suggest. Thanks, Brian > hth, > George > > _______________________________________________ > 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 Wed Feb 07 06:52:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElLD-0005Rz-Cy; Wed, 07 Feb 2007 06:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElLD-0005Ro-0W for msec@ietf.org; Wed, 07 Feb 2007 06:51:59 -0500 Received: from lvs00-fl-n17.ftl.affinity.com ([216.219.253.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElLC-0003WM-KU for msec@ietf.org; Wed, 07 Feb 2007 06:51:58 -0500 Received: ("??"@ams017.ftl.affinity.com) by ams017.ftl.affinity.com id S360049AbXBGLvd for ; Wed, 7 Feb 2007 06:51:33 -0500 References: In-Reply-To: From: gmgietf@identaware.com To: Brian Weis Date: Wed, 07 Feb 2007 06:51:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: msec@ietf.org, George Gross Subject: [MSEC] Re: weis-esp-group-counter, was MSEC status update 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 Brian, To fully avoid the IV reuse problem in the general case, you probably need to encode a 4-tuple: {S-GCKS-ID, (re-)registration counter, SID, SSIV}. This approach would avoid the need write the SSIV to non-volatile storage and the potential problems that would occur if a group uses a distributed GCKS. I guess I'll stay tuned for the next revision of this draft. br, George Brian Weis writes: > Hi George, > > Thanks for your review. Some comments are embedded below. > > On Feb 5, 2007, at 10:30 AM, gmgietf@identaware.com wrote: > >> Hi Brian and Lakshminath, >> >>> V. >>> New work (to be adopted after asking for group's opinion): >> >> >>> draft-weis-esp-group-counter-cipher-00: Ditto. >> >> I do not have a strong objection to this draft being adopted as a MSEC >> working group item. However, there are several questions (problems?) >> that I wondered about when I did a quick superficial review of this >> draft. >> 1) A fundamental problem is nonce or IV re-use, as recently discussed at >> length on CFRG. Wei Dai posted an good summary of those discussions and >> what to do about this problem about a week ago. I would suggest that >> this draft should include that guidance in its security considerations. >> That said, I suspect the risk of compromise is magnified in direct >> proportion to the size of the group membership. Instead of two >> endpoints, there are "N" endpoints that could accidently re-use a {SID, >> SSIV} pair, and this needs to be emphasized by this draft. There were >> about two dozen CFRG e-mail exchanges about random number generation, >> counter management, virtual machine interactions, and re-boot scenarios. >> At the least, the Sender-Specific IV (SSIV) field must be saved in a >> non-volatile storage after each use to avoid the scenario where a >> re-boot causes accidental {SID, SSIV} re-use. That way if a member >> re-boots then re-joins the same group, then it MUST also restart its >> SSIV at the last value used plus one. This is only one example. There >> are other cases mentioned by CFRG that need documentation. Perhaps the >> SID and SSIV must be qualified by a third field assigned by the GCKS, a >> "registration instance" counter? > > I'm aware of the CRFG thread, and will review it for additional security > considerations text as you suggest. Regarding re-use of the SSIV, your > suggestion may not be appropriate as there are some devices for which > frequent writes to non-volatile storage (e.g., NVRAM) are not > appropriate. It was our intention that re-joins would be detected by the > GCKS during re-registration, and that it would take appropriate action. > I'll review Section 4 and clarify this. > >> 2) A second problem is the inability to scale to large groups because >> the per sender state that receivers must maintain to enforce anti-replay >> services. The draft does not mention anti- replay service or how it >> interacts in this multi-sender group scenario. The draft must state that >> anti-replay service is not recommended, or else explain how it is done >> such that it scales to a large group. > > Describing anti-replay services would make sense for a draft that is > defining how multi-sender AH or ESP should be deployed. But his draft has > a more modest goal of describing how multi-sender counter-mode ciphers > can be deployed. The draft-ietf-msec-ipsec-extensions I-D gives the > guidance you mention above. This guidance is certainly relevent to the > esp-group-counter draft, but I don't think this document needs to do more > than reference that I-D. I can add text pointing readers to that document > for guidance on multi-sender SAs. > >> 3) The draft as written assumes that there is only a single >> cryptographic group and a single omnipotent GCKS. It seems to preclude >> any easy extension or accommodation for composite groups or distributed >> S-GCKS operations. In particular, the requirements in section 4 could be >> a source of complexity. Is an endpoint always required to interact with >> the same S-GCKS? Are all S-GCKS expected to know the SID of every >> potential group member? > > We didn't intend to make restrictions regarding composite groups or > distributed S-GCKS operations. But this is hard to answer without knowing > exactly how the distributed GCKS system in a particular deployment works. > >> 4) The assertion made in section 6, the Security Considerations, that >> the security is equivalent to that of a single sender is not true and >> should be replaced with text along the lines described above. > > The actual sentence is: "When [this document's] recommendations are > followed, the security of the crypto algorithms is equivalent to the > conventional case in which there is a single sender." We believe that > this is a true statement as long as the IVs are not reused (i.e., the > recommendations in this document). But we'll certainly add points made on > the CFRG thread as well, as you suggest. > > Thanks, > Brian > >> hth, >> George >> >> _______________________________________________ >> 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 Wed Feb 07 06:52:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElLD-0005Rz-Cy; Wed, 07 Feb 2007 06:51:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HElLD-0005Ro-0W for msec@ietf.org; Wed, 07 Feb 2007 06:51:59 -0500 Received: from lvs00-fl-n17.ftl.affinity.com ([216.219.253.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HElLC-0003WM-KU for msec@ietf.org; Wed, 07 Feb 2007 06:51:58 -0500 Received: ("??"@ams017.ftl.affinity.com) by ams017.ftl.affinity.com id S360049AbXBGLvd for ; Wed, 7 Feb 2007 06:51:33 -0500 References: In-Reply-To: From: gmgietf@identaware.com To: Brian Weis Date: Wed, 07 Feb 2007 06:51:32 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Cc: msec@ietf.org, George Gross Subject: [MSEC] Re: weis-esp-group-counter, was MSEC status update 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 Brian, To fully avoid the IV reuse problem in the general case, you probably need to encode a 4-tuple: {S-GCKS-ID, (re-)registration counter, SID, SSIV}. This approach would avoid the need write the SSIV to non-volatile storage and the potential problems that would occur if a group uses a distributed GCKS. I guess I'll stay tuned for the next revision of this draft. br, George Brian Weis writes: > Hi George, > > Thanks for your review. Some comments are embedded below. > > On Feb 5, 2007, at 10:30 AM, gmgietf@identaware.com wrote: > >> Hi Brian and Lakshminath, >> >>> V. >>> New work (to be adopted after asking for group's opinion): >> >> >>> draft-weis-esp-group-counter-cipher-00: Ditto. >> >> I do not have a strong objection to this draft being adopted as a MSEC >> working group item. However, there are several questions (problems?) >> that I wondered about when I did a quick superficial review of this >> draft. >> 1) A fundamental problem is nonce or IV re-use, as recently discussed at >> length on CFRG. Wei Dai posted an good summary of those discussions and >> what to do about this problem about a week ago. I would suggest that >> this draft should include that guidance in its security considerations. >> That said, I suspect the risk of compromise is magnified in direct >> proportion to the size of the group membership. Instead of two >> endpoints, there are "N" endpoints that could accidently re-use a {SID, >> SSIV} pair, and this needs to be emphasized by this draft. There were >> about two dozen CFRG e-mail exchanges about random number generation, >> counter management, virtual machine interactions, and re-boot scenarios. >> At the least, the Sender-Specific IV (SSIV) field must be saved in a >> non-volatile storage after each use to avoid the scenario where a >> re-boot causes accidental {SID, SSIV} re-use. That way if a member >> re-boots then re-joins the same group, then it MUST also restart its >> SSIV at the last value used plus one. This is only one example. There >> are other cases mentioned by CFRG that need documentation. Perhaps the >> SID and SSIV must be qualified by a third field assigned by the GCKS, a >> "registration instance" counter? > > I'm aware of the CRFG thread, and will review it for additional security > considerations text as you suggest. Regarding re-use of the SSIV, your > suggestion may not be appropriate as there are some devices for which > frequent writes to non-volatile storage (e.g., NVRAM) are not > appropriate. It was our intention that re-joins would be detected by the > GCKS during re-registration, and that it would take appropriate action. > I'll review Section 4 and clarify this. > >> 2) A second problem is the inability to scale to large groups because >> the per sender state that receivers must maintain to enforce anti-replay >> services. The draft does not mention anti- replay service or how it >> interacts in this multi-sender group scenario. The draft must state that >> anti-replay service is not recommended, or else explain how it is done >> such that it scales to a large group. > > Describing anti-replay services would make sense for a draft that is > defining how multi-sender AH or ESP should be deployed. But his draft has > a more modest goal of describing how multi-sender counter-mode ciphers > can be deployed. The draft-ietf-msec-ipsec-extensions I-D gives the > guidance you mention above. This guidance is certainly relevent to the > esp-group-counter draft, but I don't think this document needs to do more > than reference that I-D. I can add text pointing readers to that document > for guidance on multi-sender SAs. > >> 3) The draft as written assumes that there is only a single >> cryptographic group and a single omnipotent GCKS. It seems to preclude >> any easy extension or accommodation for composite groups or distributed >> S-GCKS operations. In particular, the requirements in section 4 could be >> a source of complexity. Is an endpoint always required to interact with >> the same S-GCKS? Are all S-GCKS expected to know the SID of every >> potential group member? > > We didn't intend to make restrictions regarding composite groups or > distributed S-GCKS operations. But this is hard to answer without knowing > exactly how the distributed GCKS system in a particular deployment works. > >> 4) The assertion made in section 6, the Security Considerations, that >> the security is equivalent to that of a single sender is not true and >> should be replaced with text along the lines described above. > > The actual sentence is: "When [this document's] recommendations are > followed, the security of the crypto algorithms is equivalent to the > conventional case in which there is a single sender." We believe that > this is a true statement as long as the IVs are not reused (i.e., the > recommendations in this document). But we'll certainly add points made on > the CFRG thread as well, as you suggest. > > Thanks, > Brian > >> hth, >> George >> >> _______________________________________________ >> 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 Wed Feb 07 07:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmBt-0004rG-7D; Wed, 07 Feb 2007 07:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmBs-0004rB-3O for msec@ietf.org; Wed, 07 Feb 2007 07:46:24 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEmBq-0003Ez-Sp for msec@ietf.org; Wed, 07 Feb 2007 07:46:24 -0500 Received: by nz-out-0506.google.com with SMTP id z6so192567nzd for ; Wed, 07 Feb 2007 04:46:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=g9BbtlKJE38ZentM2n3WMRqitnQ8dkKMxRMRkM5Cg1bJ+d66RZgzmdLxMQgTMKGSgol23BkHdeyw2bjXpNBtqJhsTdDEjXPPOx7wpZT16GdwNjb53lVC7qgEzc+coEGc0+5grX9y8FKRQmN4QefQtEWHDmZB0HLcEhHyiKI89rg= Received: by 10.115.106.7 with SMTP id i7mr1652848wam.1170852382252; Wed, 07 Feb 2007 04:46:22 -0800 (PST) Received: by 10.65.239.20 with HTTP; Wed, 7 Feb 2007 04:46:22 -0800 (PST) Message-ID: <4166af450702070446n108c6c01ud40e62276bba3b7f@mail.gmail.com> Date: Wed, 7 Feb 2007 12:46:22 +0000 From: "Prashant Pillai" To: msec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [MSEC] GDOI/GSAKMP message sizes 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="===============1383977428==" Errors-To: msec-bounces@ietf.org --===============1383977428== Content-Type: multipart/alternative; boundary="----=_Part_3445_29244725.1170852382172" ------=_Part_3445_29244725.1170852382172 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Has anyone performed any analysis/simulation of the packet sizes of the different messages in GSAKMP and GDOI? I am working on comparing the two protocols and would like to know the appropriate message sizes. Thanks in advance. Regards Prashant -- Prashant Pillai Research Assistant Mobile and Satellite Communications Research Centre (MSCRC) School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom ------=_Part_3445_29244725.1170852382172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi All,
 
Has anyone performed any analysis/simulation of the packet sizes of the different messages in GSAKMP and GDOI?
 
I am working on comparing the two protocols and would like to know the appropriate message sizes.
 
Thanks in advance.
 
Regards
Prashant
 

--
Prashant Pillai
Research Assistant
Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
------=_Part_3445_29244725.1170852382172-- --===============1383977428== 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 --===============1383977428==-- From msec-bounces@ietf.org Wed Feb 07 07:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmBt-0004rG-7D; Wed, 07 Feb 2007 07:46:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEmBs-0004rB-3O for msec@ietf.org; Wed, 07 Feb 2007 07:46:24 -0500 Received: from nz-out-0506.google.com ([64.233.162.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEmBq-0003Ez-Sp for msec@ietf.org; Wed, 07 Feb 2007 07:46:24 -0500 Received: by nz-out-0506.google.com with SMTP id z6so192567nzd for ; Wed, 07 Feb 2007 04:46:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=g9BbtlKJE38ZentM2n3WMRqitnQ8dkKMxRMRkM5Cg1bJ+d66RZgzmdLxMQgTMKGSgol23BkHdeyw2bjXpNBtqJhsTdDEjXPPOx7wpZT16GdwNjb53lVC7qgEzc+coEGc0+5grX9y8FKRQmN4QefQtEWHDmZB0HLcEhHyiKI89rg= Received: by 10.115.106.7 with SMTP id i7mr1652848wam.1170852382252; Wed, 07 Feb 2007 04:46:22 -0800 (PST) Received: by 10.65.239.20 with HTTP; Wed, 7 Feb 2007 04:46:22 -0800 (PST) Message-ID: <4166af450702070446n108c6c01ud40e62276bba3b7f@mail.gmail.com> Date: Wed, 7 Feb 2007 12:46:22 +0000 From: "Prashant Pillai" To: msec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Subject: [MSEC] GDOI/GSAKMP message sizes 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="===============1383977428==" Errors-To: msec-bounces@ietf.org --===============1383977428== Content-Type: multipart/alternative; boundary="----=_Part_3445_29244725.1170852382172" ------=_Part_3445_29244725.1170852382172 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi All, Has anyone performed any analysis/simulation of the packet sizes of the different messages in GSAKMP and GDOI? I am working on comparing the two protocols and would like to know the appropriate message sizes. Thanks in advance. Regards Prashant -- Prashant Pillai Research Assistant Mobile and Satellite Communications Research Centre (MSCRC) School of Engineering, Design and Technology University of Bradford Bradford, BD7 1DP West Yorkshire United Kingdom ------=_Part_3445_29244725.1170852382172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Hi All,
 
Has anyone performed any analysis/simulation of the packet sizes of the different messages in GSAKMP and GDOI?
 
I am working on comparing the two protocols and would like to know the appropriate message sizes.
 
Thanks in advance.
 
Regards
Prashant
 

--
Prashant Pillai
Research Assistant
Mobile and Satellite Communications Research Centre (MSCRC)
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
------=_Part_3445_29244725.1170852382172-- --===============1383977428== 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 --===============1383977428==-- From msec-bounces@ietf.org Wed Feb 07 21:20:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEytj-0006On-GB; Wed, 07 Feb 2007 21:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEyth-0006Oe-MM for msec@ietf.org; Wed, 07 Feb 2007 21:20:29 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEytg-0008O4-Cd for msec@ietf.org; Wed, 07 Feb 2007 21:20:29 -0500 Received: from [127.0.0.1] (bill@fir.cs.concordia.ca [132.205.45.147]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id l182KMk1011585 for ; Wed, 7 Feb 2007 21:20:22 -0500 Message-ID: <45CA8836.8080605@cse.concordia.ca> Date: Wed, 07 Feb 2007 21:17:26 -0500 From: JW Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: MSEC Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/02/07 21:20:23 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [MSEC] Guaranteeing adjacency for PIM routers--some questions 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 As this topic concerns group security as much as it does PIM-SM, I am cross-posting it to the msec mailing list. My apologies to those who see it twice. Bill Atwood As we have begun to investigate the details of how to secure the link-local messages for PIM-SM (see draft-ietf-pim-linklocal), a "more general" problem has appeared, which is how to ensure that the (supposedly) adjacent routers are a) who they claim to be, b) really adjacent. A solution to this problem will be applicable to all exchanges with "adjacent" routers. Thus, the work could be useful in securing PIM-SM link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) other peer exchanges. As noted in draft-ietf-pim-linklocal, link-local communication actually is in the form of a set of independent groups, each with one speaker and several listeners. In each router, there is one incoming Security Association (SA) for each peer, plus one outgoing SA for this router as a sender. Thus, in a specific region, there will be as many SSM groups as there are routers, and each SSM group will have one SA associated with it. The GCKS will maintain membership information of these groups, and will generate and distribute keys to all pertinent routers. In reading the RFC on the Group Domain of Interpretation (RFC 3547), it is clear that the operation of any secure group (including the secure groups formed by adjacent routers) is going to have two phases: Phase 1 establishes Security Associations between the Group Controller/Key Server (GCKS) and each of the individual routers. Phase 2 establishes the Group Security Association and distributes the keys that will be used for the group communication. We expect to use either GDOI itself, or necessary parts of it, for phase 2. The basic principle is simple: whenever a router will be added or joined, the GCKS will create a new SA for the SSM group for which the added or joined router will be the speaker, and distribute the necessary information to the listeners (all the adjacent routers). The question to be resolved is how will the GCKS get the list of adjacent routers to the newly joined router? Two options are possible: a) Dynamic mode: Take the arrival of a message from a peer as prima facie evidence that the peer is adjacent. (This implies two assumptions: 1) that routers will not forward link-local messages, and 2) that no "rogue" router is on the subnet.) In this case, the only property of the peer to be verified is whether the peer is "legitimate" (which should eliminate "rogue" routers). It permits only validating the router itself, not its adjacency matrix. However, the "authority" (typically the GCKS) could build up dynamically an image of the topology by examining the requests for validation. The "legitimacy" of a particular router could be based on some pre-configured secret, stored in a configuration file on the router, or in a unique hardware device associated with the router. b) Static mode: The GCKS or "authority" will maintain an adjacency matrix (which in turn requires that the system administrator maintain the information in a machine-accessible format). However, it permits maintaining significantly more control over the router-to-router communication within the network. Clearly the first option requires that less information be maintained by the "authority", whereas the second option may reduce the traffic flow. Our primary question is, "Is it worthwhile exploring none, the first, the second, or both options?" A secondary question is, "Will any of these options be operationally viable, or will they require the maintenance of information where the average systems administrator will find it difficult to justify the time expenditure?" Any comments from the list will be most appreciated, and will guide us in our development of a solution to the link-local security problem. -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Wed Feb 07 21:20:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEytj-0006On-GB; Wed, 07 Feb 2007 21:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEyth-0006Oe-MM for msec@ietf.org; Wed, 07 Feb 2007 21:20:29 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEytg-0008O4-Cd for msec@ietf.org; Wed, 07 Feb 2007 21:20:29 -0500 Received: from [127.0.0.1] (bill@fir.cs.concordia.ca [132.205.45.147]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id l182KMk1011585 for ; Wed, 7 Feb 2007 21:20:22 -0500 Message-ID: <45CA8836.8080605@cse.concordia.ca> Date: Wed, 07 Feb 2007 21:17:26 -0500 From: JW Atwood Organization: Concordia University, Department of Computer Science and Software Engineering User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: MSEC Working Group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/02/07 21:20:23 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [MSEC] Guaranteeing adjacency for PIM routers--some questions 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 As this topic concerns group security as much as it does PIM-SM, I am cross-posting it to the msec mailing list. My apologies to those who see it twice. Bill Atwood As we have begun to investigate the details of how to secure the link-local messages for PIM-SM (see draft-ietf-pim-linklocal), a "more general" problem has appeared, which is how to ensure that the (supposedly) adjacent routers are a) who they claim to be, b) really adjacent. A solution to this problem will be applicable to all exchanges with "adjacent" routers. Thus, the work could be useful in securing PIM-SM link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) other peer exchanges. As noted in draft-ietf-pim-linklocal, link-local communication actually is in the form of a set of independent groups, each with one speaker and several listeners. In each router, there is one incoming Security Association (SA) for each peer, plus one outgoing SA for this router as a sender. Thus, in a specific region, there will be as many SSM groups as there are routers, and each SSM group will have one SA associated with it. The GCKS will maintain membership information of these groups, and will generate and distribute keys to all pertinent routers. In reading the RFC on the Group Domain of Interpretation (RFC 3547), it is clear that the operation of any secure group (including the secure groups formed by adjacent routers) is going to have two phases: Phase 1 establishes Security Associations between the Group Controller/Key Server (GCKS) and each of the individual routers. Phase 2 establishes the Group Security Association and distributes the keys that will be used for the group communication. We expect to use either GDOI itself, or necessary parts of it, for phase 2. The basic principle is simple: whenever a router will be added or joined, the GCKS will create a new SA for the SSM group for which the added or joined router will be the speaker, and distribute the necessary information to the listeners (all the adjacent routers). The question to be resolved is how will the GCKS get the list of adjacent routers to the newly joined router? Two options are possible: a) Dynamic mode: Take the arrival of a message from a peer as prima facie evidence that the peer is adjacent. (This implies two assumptions: 1) that routers will not forward link-local messages, and 2) that no "rogue" router is on the subnet.) In this case, the only property of the peer to be verified is whether the peer is "legitimate" (which should eliminate "rogue" routers). It permits only validating the router itself, not its adjacency matrix. However, the "authority" (typically the GCKS) could build up dynamically an image of the topology by examining the requests for validation. The "legitimacy" of a particular router could be based on some pre-configured secret, stored in a configuration file on the router, or in a unique hardware device associated with the router. b) Static mode: The GCKS or "authority" will maintain an adjacency matrix (which in turn requires that the system administrator maintain the information in a machine-accessible format). However, it permits maintaining significantly more control over the router-to-router communication within the network. Clearly the first option requires that less information be maintained by the "authority", whereas the second option may reduce the traffic flow. Our primary question is, "Is it worthwhile exploring none, the first, the second, or both options?" A secondary question is, "Will any of these options be operationally viable, or will they require the maintenance of information where the average systems administrator will find it difficult to justify the time expenditure?" Any comments from the list will be most appreciated, and will guide us in our development of a solution to the link-local security problem. -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http: //users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Thu Feb 08 19:24:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJYK-00013N-W2; Thu, 08 Feb 2007 19:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJYJ-00012U-9o; Thu, 08 Feb 2007 19:23:47 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJXq-0005Vf-Ms; Thu, 08 Feb 2007 19:23:47 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l190NGWP014872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 16:23:17 -0800 Received: from [129.46.173.183] (ldondeti.na.qualcomm.com [129.46.173.183]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l190NFvn000278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Feb 2007 16:23:15 -0800 (PST) Message-ID: <45CBBEAB.3050100@qualcomm.com> Date: Thu, 08 Feb 2007 16:22:03 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Subject: New version, 05, available (Re: [MSEC] WGLC on draft-ietf-msec-ipsec-extensions-04) References: <45C81DCA.20100@qualcomm.com> In-Reply-To: <45C81DCA.20100@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org, Russ Housley 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 -05- version of the MSEC-IPsec-extensions draft as part of the LC process. To make things easy, I am resetting the clock; you have until the 22nd AOE to send comments. If you are already reviewing -04- version, the following link may be helpful http://tools.ietf.org/wg/msec/draft-ietf-msec-ipsec-extensions/draft-ietf-msec-ipsec-extensions-05-from-04.diff.html Apologies for any confusion. thanks and regards, Lakshminath Lakshminath Dondeti wrote: > Folks, > > This is a WG last call for comments on > draft-ietf-msec-ipsec-extensions-04, ending on Feb 19th AOE. > > 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 Feb 08 19:24:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJYK-00013N-W2; Thu, 08 Feb 2007 19:23:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJYJ-00012U-9o; Thu, 08 Feb 2007 19:23:47 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJXq-0005Vf-Ms; Thu, 08 Feb 2007 19:23:47 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l190NGWP014872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2007 16:23:17 -0800 Received: from [129.46.173.183] (ldondeti.na.qualcomm.com [129.46.173.183]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l190NFvn000278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Feb 2007 16:23:15 -0800 (PST) Message-ID: <45CBBEAB.3050100@qualcomm.com> Date: Thu, 08 Feb 2007 16:22:03 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org Subject: New version, 05, available (Re: [MSEC] WGLC on draft-ietf-msec-ipsec-extensions-04) References: <45C81DCA.20100@qualcomm.com> In-Reply-To: <45C81DCA.20100@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ipsec@ietf.org, Russ Housley 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 -05- version of the MSEC-IPsec-extensions draft as part of the LC process. To make things easy, I am resetting the clock; you have until the 22nd AOE to send comments. If you are already reviewing -04- version, the following link may be helpful http://tools.ietf.org/wg/msec/draft-ietf-msec-ipsec-extensions/draft-ietf-msec-ipsec-extensions-05-from-04.diff.html Apologies for any confusion. thanks and regards, Lakshminath Lakshminath Dondeti wrote: > Folks, > > This is a WG last call for comments on > draft-ietf-msec-ipsec-extensions-04, ending on Feb 19th AOE. > > 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 Sat Feb 10 06:27:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqO3-0000eH-Cv; Sat, 10 Feb 2007 06:27:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqO2-0000eB-6j for msec@ietf.org; Sat, 10 Feb 2007 06:27:22 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFqNz-0005dq-Sv for msec@ietf.org; Sat, 10 Feb 2007 06:27:22 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD8007IBVQU40@szxga04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD800K1JVQUDY@szxga04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Received: from l52008 ([10.111.12.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD800GEKVQQNH@szxml04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Date: Sat, 10 Feb 2007 19:25:38 +0800 From: Liu Ya Subject: RE: [MSEC] Guaranteeing adjacency for PIM routers--some questions In-reply-to: <45CA8836.8080605@cse.concordia.ca> To: 'JW Atwood' Message-id: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdLKBLTbZhbgWYpT6C1Oljw7tzpBwB0i5mQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Bill, See inline please. JW Atwood wrote: > ... > A solution to this problem will be applicable to all exchanges with > "adjacent" routers. Thus, the work could be useful in securing PIM-SM > link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) > other peer exchanges. > Agree. I'm working on OSPFv3 automated group key management, where dynamically building up router topology image would be used either. > > The basic principle is simple: whenever a router will be added or > joined, the GCKS will create a new SA for the SSM group for which the > added or joined router will be the speaker, and distribute > the necessary > information to the listeners (all the adjacent routers). The question > to be resolved is how will the GCKS get the list of adjacent > routers to > the newly joined router? Two options are possible: > > a) Dynamic mode: Take the arrival of a message from a peer as prima > facie evidence that the peer is adjacent. I don't understand your point well . More detailed classifications are welcome :-) > (This implies two > assumptions: 1) that routers will not forward link-local messages, and > 2) that no "rogue" router is on the subnet.) In this case, the only > property of the peer to be verified is whether the peer is > "legitimate" > (which should eliminate "rogue" routers). It permits only > validating the > router itself, not its adjacency matrix. However, the "authority" > (typically the GCKS) could build up dynamically an image of > the topology > by examining the requests for validation. > > The "legitimacy" of a particular router could be based on some > pre-configured secret, stored in a configuration file on the > router, or > in a unique hardware device associated with the router. It is a router peer authentication issue. GDOI Phase II protocol meets this requirement. LIU Ya > > b) Static mode: The GCKS or "authority" will maintain an adjacency > matrix (which in turn requires that the system administrator maintain > the information in a machine-accessible format). However, it permits > maintaining significantly more control over the router-to-router > communication within the network. > > Clearly the first option requires that less information be > maintained by > the "authority", whereas the second option may reduce the > traffic flow. > > Our primary question is, "Is it worthwhile exploring none, the first, > the second, or both options?" A secondary question is, "Will any of > these options be operationally viable, or will they require the > maintenance of information where the average systems > administrator will > find it difficult to justify the time expenditure?" > > > Any comments from the list will be most appreciated, and will guide us > in our development of a solution to the link-local security problem. > > > -- > > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email: bill@cse.concordia.ca > 1455 de Maisonneuve Blvd. West http: > //users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 > > > _______________________________________________ > 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 Sat Feb 10 06:27:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqO3-0000eH-Cv; Sat, 10 Feb 2007 06:27:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFqO2-0000eB-6j for msec@ietf.org; Sat, 10 Feb 2007 06:27:22 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFqNz-0005dq-Sv for msec@ietf.org; Sat, 10 Feb 2007 06:27:22 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD8007IBVQU40@szxga04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD800K1JVQUDY@szxga04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Received: from l52008 ([10.111.12.63]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD800GEKVQQNH@szxml04-in.huawei.com> for msec@ietf.org; Sat, 10 Feb 2007 19:25:42 +0800 (CST) Date: Sat, 10 Feb 2007 19:25:38 +0800 From: Liu Ya Subject: RE: [MSEC] Guaranteeing adjacency for PIM routers--some questions In-reply-to: <45CA8836.8080605@cse.concordia.ca> To: 'JW Atwood' Message-id: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcdLKBLTbZhbgWYpT6C1Oljw7tzpBwB0i5mQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 Bill, See inline please. JW Atwood wrote: > ... > A solution to this problem will be applicable to all exchanges with > "adjacent" routers. Thus, the work could be useful in securing PIM-SM > link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) > other peer exchanges. > Agree. I'm working on OSPFv3 automated group key management, where dynamically building up router topology image would be used either. > > The basic principle is simple: whenever a router will be added or > joined, the GCKS will create a new SA for the SSM group for which the > added or joined router will be the speaker, and distribute > the necessary > information to the listeners (all the adjacent routers). The question > to be resolved is how will the GCKS get the list of adjacent > routers to > the newly joined router? Two options are possible: > > a) Dynamic mode: Take the arrival of a message from a peer as prima > facie evidence that the peer is adjacent. I don't understand your point well . More detailed classifications are welcome :-) > (This implies two > assumptions: 1) that routers will not forward link-local messages, and > 2) that no "rogue" router is on the subnet.) In this case, the only > property of the peer to be verified is whether the peer is > "legitimate" > (which should eliminate "rogue" routers). It permits only > validating the > router itself, not its adjacency matrix. However, the "authority" > (typically the GCKS) could build up dynamically an image of > the topology > by examining the requests for validation. > > The "legitimacy" of a particular router could be based on some > pre-configured secret, stored in a configuration file on the > router, or > in a unique hardware device associated with the router. It is a router peer authentication issue. GDOI Phase II protocol meets this requirement. LIU Ya > > b) Static mode: The GCKS or "authority" will maintain an adjacency > matrix (which in turn requires that the system administrator maintain > the information in a machine-accessible format). However, it permits > maintaining significantly more control over the router-to-router > communication within the network. > > Clearly the first option requires that less information be > maintained by > the "authority", whereas the second option may reduce the > traffic flow. > > Our primary question is, "Is it worthwhile exploring none, the first, > the second, or both options?" A secondary question is, "Will any of > these options be operationally viable, or will they require the > maintenance of information where the average systems > administrator will > find it difficult to justify the time expenditure?" > > > Any comments from the list will be most appreciated, and will guide us > in our development of a solution to the link-local security problem. > > > -- > > Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 > Professor Emeritus fax: +1 (514) 848-2830 > Department of Computer Science > and Software Engineering > Concordia University EV 3.185 email: bill@cse.concordia.ca > 1455 de Maisonneuve Blvd. West http: > //users.encs.concordia.ca/~bill > Montreal, Quebec Canada H3G 1M8 > > > _______________________________________________ > 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 Mon Feb 12 10:25:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd3F-0003VK-6o; Mon, 12 Feb 2007 10:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd3D-0003VC-9T for msec@ietf.org; Mon, 12 Feb 2007 10:25:07 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGd3B-0006iC-Vq for msec@ietf.org; Mon, 12 Feb 2007 10:25:07 -0500 Received: from [10.0.12.203] (unknown [10.0.12.203]) by mailing.unile.it (Postfix) with ESMTP id EF886104B33 for ; Mon, 12 Feb 2007 16:25:04 +0100 (CET) Message-ID: <45D086D1.806@inwind.it> Date: Mon, 12 Feb 2007 16:25:05 +0100 From: Elena Scialpi User-Agent: Mozilla Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [MSEC] multicast or unicast? 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, if I use LKH each member has one KEK(different to the other member) to decrypt the TEK. To PUSH the TEK I must use unicast messages! Can't I use a multicast message? Thank you in advance! Elena Scialpi -- LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it/ Office-Fax: (+39) 0832-297310 c/o Dipartimento di Ingegneria dell'Innovazione Via per Monteroni 73100 Lecce LE, Italy _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 12 10:25:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd3F-0003VK-6o; Mon, 12 Feb 2007 10:25:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGd3D-0003VC-9T for msec@ietf.org; Mon, 12 Feb 2007 10:25:07 -0500 Received: from mailing.unile.it ([193.204.77.251]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGd3B-0006iC-Vq for msec@ietf.org; Mon, 12 Feb 2007 10:25:07 -0500 Received: from [10.0.12.203] (unknown [10.0.12.203]) by mailing.unile.it (Postfix) with ESMTP id EF886104B33 for ; Mon, 12 Feb 2007 16:25:04 +0100 (CET) Message-ID: <45D086D1.806@inwind.it> Date: Mon, 12 Feb 2007 16:25:05 +0100 From: Elena Scialpi User-Agent: Mozilla Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [MSEC] multicast or unicast? 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, if I use LKH each member has one KEK(different to the other member) to decrypt the TEK. To PUSH the TEK I must use unicast messages! Can't I use a multicast message? Thank you in advance! Elena Scialpi -- LIIS Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi http://liis.unile.it http://www.campusdelsalento.it/ Office-Fax: (+39) 0832-297310 c/o Dipartimento di Ingegneria dell'Innovazione Via per Monteroni 73100 Lecce LE, Italy _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 12 19:35:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGlde-0001lR-54; Mon, 12 Feb 2007 19:35:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGldd-0001lJ-2B for msec@ietf.org; Mon, 12 Feb 2007 19:35:17 -0500 Received: from m4.sparta.com ([157.185.61.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGldX-0002l5-L5 for msec@ietf.org; Mon, 12 Feb 2007 19:35:17 -0500 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l1D0ZBrh004231 for ; Mon, 12 Feb 2007 18:35:11 -0600 Received: from cronus.sandiego.ads.sparta.com ([157.185.24.3]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l1D0ZB6L030402 for ; Mon, 12 Feb 2007 18:35:11 -0600 Received: from [127.0.0.1] ([157.185.24.42]) by cronus.sandiego.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 16:35:10 -0800 Message-ID: <45D107BD.80100@sparta.com> Date: Mon, 12 Feb 2007 16:35:09 -0800 From: Rod Fleischer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2007 00:35:10.0488 (UTC) FILETIME=[D1662980:01C74F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MSEC] GSAKMP Java Implementation available 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, SPARTA has recently released our Java implementation of GSAKMP to the public. It is available for download at: http://gsakmp.sourceforge.net Please note that this implementation only contains the core protocol API, we don't provide any GUI or application code in this release. Feedback is welcome and encouraged. Please send comments to isso-gsakmp@sparta.com -Rod Fleischer SPARTA, Inc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rod Fleischer Senior Engineer SPARTA, Inc. 858.668.3570.x214 858.668.3575 (fax) rodf@sparta.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 12 19:35:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGlde-0001lR-54; Mon, 12 Feb 2007 19:35:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGldd-0001lJ-2B for msec@ietf.org; Mon, 12 Feb 2007 19:35:17 -0500 Received: from m4.sparta.com ([157.185.61.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGldX-0002l5-L5 for msec@ietf.org; Mon, 12 Feb 2007 19:35:17 -0500 Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id l1D0ZBrh004231 for ; Mon, 12 Feb 2007 18:35:11 -0600 Received: from cronus.sandiego.ads.sparta.com ([157.185.24.3]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id l1D0ZB6L030402 for ; Mon, 12 Feb 2007 18:35:11 -0600 Received: from [127.0.0.1] ([157.185.24.42]) by cronus.sandiego.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 16:35:10 -0800 Message-ID: <45D107BD.80100@sparta.com> Date: Mon, 12 Feb 2007 16:35:09 -0800 From: Rod Fleischer User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: msec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2007 00:35:10.0488 (UTC) FILETIME=[D1662980:01C74F06] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [MSEC] GSAKMP Java Implementation available 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, SPARTA has recently released our Java implementation of GSAKMP to the public. It is available for download at: http://gsakmp.sourceforge.net Please note that this implementation only contains the core protocol API, we don't provide any GUI or application code in this release. Feedback is welcome and encouraged. Please send comments to isso-gsakmp@sparta.com -Rod Fleischer SPARTA, Inc. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rod Fleischer Senior Engineer SPARTA, Inc. 858.668.3570.x214 858.668.3575 (fax) rodf@sparta.com _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 12 22:53:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGoj0-00006v-W6; Mon, 12 Feb 2007 22:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGoiz-000059-QW for msec@ietf.org; Mon, 12 Feb 2007 22:53:01 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGoiv-0000zz-Db for msec@ietf.org; Mon, 12 Feb 2007 22:53:01 -0500 Received: from [132.205.44.76] (cedar.cs.concordia.ca [132.205.44.76]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id l1D3qYLU006651; Mon, 12 Feb 2007 22:52:34 -0500 Message-ID: <45D13608.5000608@cse.concordia.ca> Date: Mon, 12 Feb 2007 22:52:40 -0500 From: William Atwood Organization: Concordia University - Department of Computer Science and Software Engineering User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Guaranteeing adjacency for PIM routers--some questions References: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> In-Reply-To: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/02/12 22:52:34 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Hello, See inline, please. Liu Ya wrote: > Hi Bill, > > See inline please. > > JW Atwood wrote: >> ... >> A solution to this problem will be applicable to all exchanges with >> "adjacent" routers. Thus, the work could be useful in securing > PIM-SM >> link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) >> other peer exchanges. >> > Agree. I'm working on OSPFv3 automated group key management, where > dynamically building up router topology image would be used either. May I know the draft-xxx identifier for this work? I did not find anything in the ospf WG or the msec WG. > >> The basic principle is simple: whenever a router will be added or >> joined, the GCKS will create a new SA for the SSM group for which > the >> added or joined router will be the speaker, and distribute >> the necessary >> information to the listeners (all the adjacent routers). The > question >> to be resolved is how will the GCKS get the list of adjacent >> routers to >> the newly joined router? Two options are possible: >> >> a) Dynamic mode: Take the arrival of a message from a peer as prima >> facie evidence that the peer is adjacent. > > I don't understand your point well . More detailed classifications are > welcome :-) Dynamic case: Build up knowledge of the adjacency from observing the messages that arrive. Static case: Only acknowledge (or allow) the adjacencies that are pre-installed by the system administrator. > >> (This implies two >> assumptions: 1) that routers will not forward link-local messages, > and >> 2) that no "rogue" router is on the subnet.) In this case, the only >> property of the peer to be verified is whether the peer is >> "legitimate" >> (which should eliminate "rogue" routers). It permits only >> validating the >> router itself, not its adjacency matrix. However, the "authority" >> (typically the GCKS) could build up dynamically an image of >> the topology >> by examining the requests for validation. >> >> The "legitimacy" of a particular router could be based on some >> pre-configured secret, stored in a configuration file on the >> router, or >> in a unique hardware device associated with the router. > > It is a router peer authentication issue. GDOI Phase II protocol meets > this requirement. I will have to read GDOI again before I can (hopefully) understand. Here is my concern. I say, "I am a valid router". My peer says, "Prove it." How do I do this? This would seem to be independent of GDOI. > > LIU Ya > >> b) Static mode: The GCKS or "authority" will maintain an adjacency >> matrix (which in turn requires that the system administrator > maintain >> the information in a machine-accessible format). However, it permits >> maintaining significantly more control over the router-to-router >> communication within the network. >> >> Clearly the first option requires that less information be >> maintained by >> the "authority", whereas the second option may reduce the >> traffic flow. >> >> Our primary question is, "Is it worthwhile exploring none, the > first, >> the second, or both options?" A secondary question is, "Will any of >> these options be operationally viable, or will they require the >> maintenance of information where the average systems >> administrator will >> find it difficult to justify the time expenditure?" >> >> >> Any comments from the list will be most appreciated, and will guide > us >> in our development of a solution to the link-local security problem. >> >> >> -- >> >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Professor Emeritus fax: +1 (514) 848-2830 >> Department of Computer Science >> and Software Engineering >> Concordia University EV 3.185 email: bill@cse.concordia.ca >> 1455 de Maisonneuve Blvd. West http: >> //users.encs.concordia.ca/~bill >> Montreal, Quebec Canada H3G 1M8 >> >> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/msec > > > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Mon Feb 12 22:53:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGoj0-00006v-W6; Mon, 12 Feb 2007 22:53:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGoiz-000059-QW for msec@ietf.org; Mon, 12 Feb 2007 22:53:01 -0500 Received: from perseverance-96.encs.concordia.ca ([132.205.96.94] helo=perseverance.services.encs.concordia.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGoiv-0000zz-Db for msec@ietf.org; Mon, 12 Feb 2007 22:53:01 -0500 Received: from [132.205.44.76] (cedar.cs.concordia.ca [132.205.44.76]) by perseverance.services.encs.concordia.ca (envelope-from bill@cse.concordia.ca) (8.13.7/8.13.7) with ESMTP id l1D3qYLU006651; Mon, 12 Feb 2007 22:52:34 -0500 Message-ID: <45D13608.5000608@cse.concordia.ca> Date: Mon, 12 Feb 2007 22:52:40 -0500 From: William Atwood Organization: Concordia University - Department of Computer Science and Software Engineering User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Liu Ya Subject: Re: [MSEC] Guaranteeing adjacency for PIM routers--some questions References: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> In-Reply-To: <059101c74d06$30f71470$3f0c6f0a@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on perseverance.encs.concordia.ca at 2007/02/12 22:52:34 EST X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Hello, See inline, please. Liu Ya wrote: > Hi Bill, > > See inline please. > > JW Atwood wrote: >> ... >> A solution to this problem will be applicable to all exchanges with >> "adjacent" routers. Thus, the work could be useful in securing > PIM-SM >> link-local exchanges, OSPFv3 exchanges (see RFC 4552) and (possibly) >> other peer exchanges. >> > Agree. I'm working on OSPFv3 automated group key management, where > dynamically building up router topology image would be used either. May I know the draft-xxx identifier for this work? I did not find anything in the ospf WG or the msec WG. > >> The basic principle is simple: whenever a router will be added or >> joined, the GCKS will create a new SA for the SSM group for which > the >> added or joined router will be the speaker, and distribute >> the necessary >> information to the listeners (all the adjacent routers). The > question >> to be resolved is how will the GCKS get the list of adjacent >> routers to >> the newly joined router? Two options are possible: >> >> a) Dynamic mode: Take the arrival of a message from a peer as prima >> facie evidence that the peer is adjacent. > > I don't understand your point well . More detailed classifications are > welcome :-) Dynamic case: Build up knowledge of the adjacency from observing the messages that arrive. Static case: Only acknowledge (or allow) the adjacencies that are pre-installed by the system administrator. > >> (This implies two >> assumptions: 1) that routers will not forward link-local messages, > and >> 2) that no "rogue" router is on the subnet.) In this case, the only >> property of the peer to be verified is whether the peer is >> "legitimate" >> (which should eliminate "rogue" routers). It permits only >> validating the >> router itself, not its adjacency matrix. However, the "authority" >> (typically the GCKS) could build up dynamically an image of >> the topology >> by examining the requests for validation. >> >> The "legitimacy" of a particular router could be based on some >> pre-configured secret, stored in a configuration file on the >> router, or >> in a unique hardware device associated with the router. > > It is a router peer authentication issue. GDOI Phase II protocol meets > this requirement. I will have to read GDOI again before I can (hopefully) understand. Here is my concern. I say, "I am a valid router". My peer says, "Prove it." How do I do this? This would seem to be independent of GDOI. > > LIU Ya > >> b) Static mode: The GCKS or "authority" will maintain an adjacency >> matrix (which in turn requires that the system administrator > maintain >> the information in a machine-accessible format). However, it permits >> maintaining significantly more control over the router-to-router >> communication within the network. >> >> Clearly the first option requires that less information be >> maintained by >> the "authority", whereas the second option may reduce the >> traffic flow. >> >> Our primary question is, "Is it worthwhile exploring none, the > first, >> the second, or both options?" A secondary question is, "Will any of >> these options be operationally viable, or will they require the >> maintenance of information where the average systems >> administrator will >> find it difficult to justify the time expenditure?" >> >> >> Any comments from the list will be most appreciated, and will guide > us >> in our development of a solution to the link-local security problem. >> >> >> -- >> >> Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 >> Professor Emeritus fax: +1 (514) 848-2830 >> Department of Computer Science >> and Software Engineering >> Concordia University EV 3.185 email: bill@cse.concordia.ca >> 1455 de Maisonneuve Blvd. West http: >> //users.encs.concordia.ca/~bill >> Montreal, Quebec Canada H3G 1M8 >> >> >> _______________________________________________ >> MSEC mailing list >> MSEC@ietf.org >> https://www1.ietf.org/mailman/listinfo/msec > > > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email: bill@cse.concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Feb 17 03:25:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKrx-0001s7-JI; Sat, 17 Feb 2007 03:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKrw-0001n2-ET for msec@ietf.org; Sat, 17 Feb 2007 03:24:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIKrv-00039s-2i for msec@ietf.org; Sat, 17 Feb 2007 03:24:32 -0500 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 l1H8ORsj006726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 17 Feb 2007 00:24:28 -0800 Received: from [10.50.77.167] (qconnect-10-50-77-167.qualcomm.com [10.50.77.167]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1H8OQQG025958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Feb 2007 00:24:27 -0800 Message-ID: <45D6BB72.8070303@qualcomm.com> Date: Sat, 17 Feb 2007 00:23:14 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org, Russ Housley Subject: Re: [MSEC] Any objections to adopting CTR mode draft as a WG item? References: <45BEA651.3040206@qualcomm.com> In-Reply-To: <45BEA651.3040206@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: msec-bounces@ietf.org I saw one email from George with his concerns, but he has not quite objected to this becoming a WG item. So, let's make this a WG item. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > draft-weis-esp-group-counter-cipher-00 was presented at San Diego and > was discussed at length. One could argue that this is out of scope for > our charter, although the charter does not explicitly disallow > multi-sender operation (here is the relevant line from the charter: > "Initial efforts will focus on scalable solutions for groups with a > single source and a very large number of recipients. " Ok, we have been > at this for some 7 years and can no longer claim to be in initial > stages, but you know what I mean.). > > At the meeting 6 people thought this should be a work item and no one > objected. Any thoughts? > > Russ, could you tell us if we can do this without rechartering? > > 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 Sat Feb 17 03:25:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKrx-0001s7-JI; Sat, 17 Feb 2007 03:24:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIKrw-0001n2-ET for msec@ietf.org; Sat, 17 Feb 2007 03:24:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIKrv-00039s-2i for msec@ietf.org; Sat, 17 Feb 2007 03:24:32 -0500 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 l1H8ORsj006726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 17 Feb 2007 00:24:28 -0800 Received: from [10.50.77.167] (qconnect-10-50-77-167.qualcomm.com [10.50.77.167]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l1H8OQQG025958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 17 Feb 2007 00:24:27 -0800 Message-ID: <45D6BB72.8070303@qualcomm.com> Date: Sat, 17 Feb 2007 00:23:14 -0800 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0b2 (Windows/20070116) MIME-Version: 1.0 To: msec@ietf.org, Russ Housley Subject: Re: [MSEC] Any objections to adopting CTR mode draft as a WG item? References: <45BEA651.3040206@qualcomm.com> In-Reply-To: <45BEA651.3040206@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: msec-bounces@ietf.org I saw one email from George with his concerns, but he has not quite objected to this becoming a WG item. So, let's make this a WG item. thanks, Lakshminath Lakshminath Dondeti wrote: > Folks, > > draft-weis-esp-group-counter-cipher-00 was presented at San Diego and > was discussed at length. One could argue that this is out of scope for > our charter, although the charter does not explicitly disallow > multi-sender operation (here is the relevant line from the charter: > "Initial efforts will focus on scalable solutions for groups with a > single source and a very large number of recipients. " Ok, we have been > at this for some 7 years and can no longer claim to be in initial > stages, but you know what I mean.). > > At the meeting 6 people thought this should be a work item and no one > objected. Any thoughts? > > Russ, could you tell us if we can do this without rechartering? > > 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 Sat Feb 17 09:40:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQjF-00017e-1a; Sat, 17 Feb 2007 09:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQjD-00017Z-MQ for msec@ietf.org; Sat, 17 Feb 2007 09:39:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIQj8-0001MV-RV for msec@ietf.org; Sat, 17 Feb 2007 09:39:55 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2007 06:39:50 -0800 X-IronPort-AV: i="4.14,184,1170662400"; d="scan'208"; a="390110064:sNHT45780440" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1HEdoDO003570; Sat, 17 Feb 2007 06:39:50 -0800 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 l1HEdnDk018509; Sat, 17 Feb 2007 06:39:50 -0800 (PST) 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.1830); Sat, 17 Feb 2007 06:39:49 -0800 Received: from [192.168.0.10] ([10.21.113.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 06:39:49 -0800 In-Reply-To: <45D086D1.806@inwind.it> References: <45D086D1.806@inwind.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AAE6634-21C9-4DE5-9E03-F01DC770F4A5@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] multicast or unicast? Date: Sat, 17 Feb 2007 06:39:46 -0800 To: Elena Scialpi X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Feb 2007 14:39:49.0318 (UTC) FILETIME=[79FCEE60:01C752A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1541; t=1171723190; x=1172587190; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20multicast=20or=20unicast? |Sender:=20; bh=bUAncDi4JGEHQSbaM9yreYA41imPXm2yeiSX8FbaFV8=; b=D/RqYCj4mckYcg9LgEKkzx39HrO/L/kUjpqMXcfRJs+opvtq3UNA2a/hzhoR7C4N87XIn5XS FAFXWI1C0uPtEaMKT8XCv6kLbBLo3cnXfUhwJeRRxJjdHDjJLJvQtJy5yyJWGaqinGcrGEk92e QiKBRCHJii8Vei+Uq8IgnhJv8=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Elena, Are you using a referring to a particular LKH implementation or of RFC 2627 in general? In general, the KEK is a pairwise key that is established between the controller/server and the member. So one would use a pairwise, authenticated key establishment procedure in order to establish this key between the two. LKH can work without a backchannel, however, provided there is some means for the controller/ server to communicate securely with the member. For example, if the server had the member's public key, it could encrypt a symmetric key (the KEK) in this public key and multicast it to the group. All group members would receiver this message but only one member would be able to use it, and there must be some means to uniquely identify this member. Mark On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: > Hi, > if I use LKH each member has one KEK(different to the other > member) to > decrypt the TEK. > To PUSH the TEK I must use unicast messages! Can't I use a > multicast message? > > Thank you in advance! > Elena Scialpi > > -- > > > LIIS > Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi > http://liis.unile.it > http://www.campusdelsalento.it/ > Office-Fax: (+39) 0832-297310 > c/o Dipartimento di Ingegneria dell'Innovazione > Via per Monteroni > 73100 Lecce LE, Italy > > > > _______________________________________________ > 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 Sat Feb 17 09:40:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQjF-00017e-1a; Sat, 17 Feb 2007 09:39:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIQjD-00017Z-MQ for msec@ietf.org; Sat, 17 Feb 2007 09:39:55 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIQj8-0001MV-RV for msec@ietf.org; Sat, 17 Feb 2007 09:39:55 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 17 Feb 2007 06:39:50 -0800 X-IronPort-AV: i="4.14,184,1170662400"; d="scan'208"; a="390110064:sNHT45780440" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1HEdoDO003570; Sat, 17 Feb 2007 06:39:50 -0800 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 l1HEdnDk018509; Sat, 17 Feb 2007 06:39:50 -0800 (PST) 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.1830); Sat, 17 Feb 2007 06:39:49 -0800 Received: from [192.168.0.10] ([10.21.113.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 06:39:49 -0800 In-Reply-To: <45D086D1.806@inwind.it> References: <45D086D1.806@inwind.it> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AAE6634-21C9-4DE5-9E03-F01DC770F4A5@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Subject: Re: [MSEC] multicast or unicast? Date: Sat, 17 Feb 2007 06:39:46 -0800 To: Elena Scialpi X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Feb 2007 14:39:49.0318 (UTC) FILETIME=[79FCEE60:01C752A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1541; t=1171723190; x=1172587190; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20[MSEC]=20multicast=20or=20unicast? |Sender:=20; bh=bUAncDi4JGEHQSbaM9yreYA41imPXm2yeiSX8FbaFV8=; b=D/RqYCj4mckYcg9LgEKkzx39HrO/L/kUjpqMXcfRJs+opvtq3UNA2a/hzhoR7C4N87XIn5XS FAFXWI1C0uPtEaMKT8XCv6kLbBLo3cnXfUhwJeRRxJjdHDjJLJvQtJy5yyJWGaqinGcrGEk92e QiKBRCHJii8Vei+Uq8IgnhJv8=; Authentication-Results: sj-dkim-1; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Elena, Are you using a referring to a particular LKH implementation or of RFC 2627 in general? In general, the KEK is a pairwise key that is established between the controller/server and the member. So one would use a pairwise, authenticated key establishment procedure in order to establish this key between the two. LKH can work without a backchannel, however, provided there is some means for the controller/ server to communicate securely with the member. For example, if the server had the member's public key, it could encrypt a symmetric key (the KEK) in this public key and multicast it to the group. All group members would receiver this message but only one member would be able to use it, and there must be some means to uniquely identify this member. Mark On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: > Hi, > if I use LKH each member has one KEK(different to the other > member) to > decrypt the TEK. > To PUSH the TEK I must use unicast messages! Can't I use a > multicast message? > > Thank you in advance! > Elena Scialpi > > -- > > > LIIS > Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi > http://liis.unile.it > http://www.campusdelsalento.it/ > Office-Fax: (+39) 0832-297310 > c/o Dipartimento di Ingegneria dell'Innovazione > Via per Monteroni > 73100 Lecce LE, Italy > > > > _______________________________________________ > 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 Sat Feb 17 13:05:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITwR-0006o5-U1; Sat, 17 Feb 2007 13:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITwQ-0006nw-Cm for msec@ietf.org; Sat, 17 Feb 2007 13:05:46 -0500 Received: from lvs00-fl-n01.ftl.affinity.com ([216.219.253.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HITwP-00023M-1O for msec@ietf.org; Sat, 17 Feb 2007 13:05:46 -0500 Received: ("??"@ams001.ftl.affinity.com) by ams001.ftl.affinity.com id S359058AbXBQSFh for ; Sat, 17 Feb 2007 13:05:37 -0500 From: gmgietf@identaware.com To: mbaugher@cisco.com Date: Sat, 17 Feb 2007 13:05:36 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: msec@ietf.org Subject: [MSEC] multicast or unicast? 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 Mark and Elena, I think it might be worth clarifying one aspect of how the LKH KEK works that Mark's e-mail omitted. In LKH, the GCKS gives each group member at its registration time a set of KEK, one KEK for each virtual node in the group member's position in the logical key hierarchy. As a consequence, all but one of a group member's LKH KEK are shared with a sub-group of other members. Registration is a unicast protocol exchange. The GCKS discloses each KEK in the logical key hierarchy tree to a distinct sub-group of the overall group membership. When multicasting a LKH rekey message, the GCKS will encrypt the new group key, once for each sub-group of authorized group members who possess a given KEK. The GCKS chooses that set of KEK such that only the authorized set of group members can decrypt the rekey message using one of their KEK. Elena: I'd recommend looking at RFC2627 for the details with this clarification in mind. Also you may want to look at RFC4535 appendix A. hth, George ------------------------------------------- Date: Sat, 17 Feb 2007 06:39:46 -0800 From: Mark Baugher To: Elena Scialpi Cc: msec@ietf.org Subject: Re: [MSEC] multicast or unicast? hi Elena, Are you using a referring to a particular LKH implementation or of RFC 2627 in general? In general, the KEK is a pairwise key that is established between the controller/server and the member. So one would use a pairwise, authenticated key establishment procedure in order to establish this key between the two. LKH can work without a backchannel, however, provided there is some means for the controller/ server to communicate securely with the member. For example, if the server had the member's public key, it could encrypt a symmetric key (the KEK) in this public key and multicast it to the group. All group members would receiver this message but only one member would be able to use it, and there must be some means to uniquely identify this member. Mark On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: > Hi, > if I use LKH each member has one KEK(different to the other > member) to > decrypt the TEK. > To PUSH the TEK I must use unicast messages! Can't I use a > multicast message? > > Thank you in advance! > Elena Scialpi > > -- > > > LIIS > Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi > http://liis.unile.it > http://www.campusdelsalento.it/ > Office-Fax: (+39) 0832-297310 > c/o Dipartimento di Ingegneria dell'Innovazione > Via per Monteroni > 73100 Lecce LE, Italy > > > > _______________________________________________ > 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 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Feb 17 13:05:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITwR-0006o5-U1; Sat, 17 Feb 2007 13:05:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HITwQ-0006nw-Cm for msec@ietf.org; Sat, 17 Feb 2007 13:05:46 -0500 Received: from lvs00-fl-n01.ftl.affinity.com ([216.219.253.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HITwP-00023M-1O for msec@ietf.org; Sat, 17 Feb 2007 13:05:46 -0500 Received: ("??"@ams001.ftl.affinity.com) by ams001.ftl.affinity.com id S359058AbXBQSFh for ; Sat, 17 Feb 2007 13:05:37 -0500 From: gmgietf@identaware.com To: mbaugher@cisco.com Date: Sat, 17 Feb 2007 13:05:36 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: msec@ietf.org Subject: [MSEC] multicast or unicast? 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 Mark and Elena, I think it might be worth clarifying one aspect of how the LKH KEK works that Mark's e-mail omitted. In LKH, the GCKS gives each group member at its registration time a set of KEK, one KEK for each virtual node in the group member's position in the logical key hierarchy. As a consequence, all but one of a group member's LKH KEK are shared with a sub-group of other members. Registration is a unicast protocol exchange. The GCKS discloses each KEK in the logical key hierarchy tree to a distinct sub-group of the overall group membership. When multicasting a LKH rekey message, the GCKS will encrypt the new group key, once for each sub-group of authorized group members who possess a given KEK. The GCKS chooses that set of KEK such that only the authorized set of group members can decrypt the rekey message using one of their KEK. Elena: I'd recommend looking at RFC2627 for the details with this clarification in mind. Also you may want to look at RFC4535 appendix A. hth, George ------------------------------------------- Date: Sat, 17 Feb 2007 06:39:46 -0800 From: Mark Baugher To: Elena Scialpi Cc: msec@ietf.org Subject: Re: [MSEC] multicast or unicast? hi Elena, Are you using a referring to a particular LKH implementation or of RFC 2627 in general? In general, the KEK is a pairwise key that is established between the controller/server and the member. So one would use a pairwise, authenticated key establishment procedure in order to establish this key between the two. LKH can work without a backchannel, however, provided there is some means for the controller/ server to communicate securely with the member. For example, if the server had the member's public key, it could encrypt a symmetric key (the KEK) in this public key and multicast it to the group. All group members would receiver this message but only one member would be able to use it, and there must be some means to uniquely identify this member. Mark On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: > Hi, > if I use LKH each member has one KEK(different to the other > member) to > decrypt the TEK. > To PUSH the TEK I must use unicast messages! Can't I use a > multicast message? > > Thank you in advance! > Elena Scialpi > > -- > > > LIIS > Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi > http://liis.unile.it > http://www.campusdelsalento.it/ > Office-Fax: (+39) 0832-297310 > c/o Dipartimento di Ingegneria dell'Innovazione > Via per Monteroni > 73100 Lecce LE, Italy > > > > _______________________________________________ > 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 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Feb 17 14:01:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIUnj-00084H-4U; Sat, 17 Feb 2007 14:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIUnh-00082S-1h for msec@ietf.org; Sat, 17 Feb 2007 14:00:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIUne-00049O-Jj for msec@ietf.org; Sat, 17 Feb 2007 14:00:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2007 11:00:47 -0800 X-IronPort-AV: i="4.14,185,1170662400"; d="scan'208"; a="465303337:sNHT50187144" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1HJ0jhV023903; Sat, 17 Feb 2007 11:00:45 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1HJ0fUw001825; Sat, 17 Feb 2007 11:00:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 11:00:41 -0800 Received: from [192.168.0.10] ([10.21.121.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 11:00:40 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7350603D-FCE0-4C2B-B472-ABA83B2518EA@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Sat, 17 Feb 2007 11:00:38 -0800 To: gmgietf@identaware.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Feb 2007 19:00:40.0901 (UTC) FILETIME=[EB0EF750:01C752C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3233; t=1171738845; x=1172602845; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20multicast=20or=20unicast? |Sender:=20; bh=LtpNQ8nDCPR+9mjvkLNvaS5Q9OsUpK8AGJgX3JHE9h0=; b=ZNbyw9lpUWf63tPFAngPs70PdlbQGqqTd2PsccYv5ho9gMm9yyakVe+fa9OlhWuA/NKSC/ti hNk51IRg0oy4hM5DKK9Yp3KWJoJQwlxUPAW/tkwXt77Odhx21TSC00yD; Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: msec@ietf.org Subject: [MSEC] Re: multicast or unicast? 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 George That's right. What I was referring to is the leaf KEK, the one KEK that is not shared with any other leaf node in the tree. Mark On Feb 17, 2007, at 10:05 AM, gmgietf@identaware.com wrote: > Hi Mark and Elena, > I think it might be worth clarifying one aspect of how the LKH KEK > works that Mark's e-mail omitted. In LKH, the GCKS gives each group > member at its registration time a set of KEK, one KEK for each > virtual node in the group member's position in the logical key > hierarchy. As a consequence, all but one of a group member's LKH > KEK are shared with a sub-group of other members. Registration is a > unicast protocol exchange. > The GCKS discloses each KEK in the logical key hierarchy tree to a > distinct sub-group of the overall group membership. When > multicasting a LKH rekey message, the GCKS will encrypt the new > group key, once for each sub-group of authorized group members who > possess a given KEK. The GCKS chooses that set of KEK such that > only the authorized set of group members can decrypt the rekey > message using one of their KEK. > Elena: I'd recommend looking at RFC2627 for the details with this > clarification in mind. Also you may want to look at RFC4535 > appendix A. > hth, > George > ------------------------------------------- > Date: Sat, 17 Feb 2007 06:39:46 -0800 > From: Mark Baugher > To: Elena Scialpi > Cc: msec@ietf.org > Subject: Re: [MSEC] multicast or unicast? > hi Elena, > Are you using a referring to a particular LKH implementation or of > RFC 2627 in general? In general, the KEK is a pairwise key that is > established between the controller/server and the member. So one > would use a pairwise, authenticated key establishment procedure in > order to establish this key between the two. LKH can work without a > backchannel, however, provided there is some means for the controller/ > server to communicate securely with the member. For example, if the > server had the member's public key, it could encrypt a symmetric key > (the KEK) in this public key and multicast it to the group. All > group members would receiver this message but only one member would > be able to use it, and there must be some means to uniquely identify > this member. > Mark > On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: >> Hi, >> if I use LKH each member has one KEK(different to the other >> member) to >> decrypt the TEK. >> To PUSH the TEK I must use unicast messages! Can't I use a >> multicast message? >> Thank you in advance! >> Elena Scialpi >> -- >> >> >> LIIS >> Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi >> http://liis.unile.it >> http://www.campusdelsalento.it/ >> Office-Fax: (+39) 0832-297310 >> c/o Dipartimento di Ingegneria dell'Innovazione >> Via per Monteroni >> 73100 Lecce LE, Italy >> >> _______________________________________________ >> 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 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From msec-bounces@ietf.org Sat Feb 17 14:01:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIUnj-00084H-4U; Sat, 17 Feb 2007 14:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIUnh-00082S-1h for msec@ietf.org; Sat, 17 Feb 2007 14:00:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIUne-00049O-Jj for msec@ietf.org; Sat, 17 Feb 2007 14:00:49 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 17 Feb 2007 11:00:47 -0800 X-IronPort-AV: i="4.14,185,1170662400"; d="scan'208"; a="465303337:sNHT50187144" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1HJ0jhV023903; Sat, 17 Feb 2007 11:00:45 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1HJ0fUw001825; Sat, 17 Feb 2007 11:00:41 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 11:00:41 -0800 Received: from [192.168.0.10] ([10.21.121.39]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 11:00:40 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7350603D-FCE0-4C2B-B472-ABA83B2518EA@cisco.com> Content-Transfer-Encoding: 7bit From: Mark Baugher Date: Sat, 17 Feb 2007 11:00:38 -0800 To: gmgietf@identaware.com X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 17 Feb 2007 19:00:40.0901 (UTC) FILETIME=[EB0EF750:01C752C5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3233; t=1171738845; x=1172602845; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mbaugher@cisco.com; z=From:=20Mark=20Baugher=20 |Subject:=20Re=3A=20multicast=20or=20unicast? |Sender:=20; bh=LtpNQ8nDCPR+9mjvkLNvaS5Q9OsUpK8AGJgX3JHE9h0=; b=ZNbyw9lpUWf63tPFAngPs70PdlbQGqqTd2PsccYv5ho9gMm9yyakVe+fa9OlhWuA/NKSC/ti hNk51IRg0oy4hM5DKK9Yp3KWJoJQwlxUPAW/tkwXt77Odhx21TSC00yD; Authentication-Results: sj-dkim-4; header.From=mbaugher@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: msec@ietf.org Subject: [MSEC] Re: multicast or unicast? 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 George That's right. What I was referring to is the leaf KEK, the one KEK that is not shared with any other leaf node in the tree. Mark On Feb 17, 2007, at 10:05 AM, gmgietf@identaware.com wrote: > Hi Mark and Elena, > I think it might be worth clarifying one aspect of how the LKH KEK > works that Mark's e-mail omitted. In LKH, the GCKS gives each group > member at its registration time a set of KEK, one KEK for each > virtual node in the group member's position in the logical key > hierarchy. As a consequence, all but one of a group member's LKH > KEK are shared with a sub-group of other members. Registration is a > unicast protocol exchange. > The GCKS discloses each KEK in the logical key hierarchy tree to a > distinct sub-group of the overall group membership. When > multicasting a LKH rekey message, the GCKS will encrypt the new > group key, once for each sub-group of authorized group members who > possess a given KEK. The GCKS chooses that set of KEK such that > only the authorized set of group members can decrypt the rekey > message using one of their KEK. > Elena: I'd recommend looking at RFC2627 for the details with this > clarification in mind. Also you may want to look at RFC4535 > appendix A. > hth, > George > ------------------------------------------- > Date: Sat, 17 Feb 2007 06:39:46 -0800 > From: Mark Baugher > To: Elena Scialpi > Cc: msec@ietf.org > Subject: Re: [MSEC] multicast or unicast? > hi Elena, > Are you using a referring to a particular LKH implementation or of > RFC 2627 in general? In general, the KEK is a pairwise key that is > established between the controller/server and the member. So one > would use a pairwise, authenticated key establishment procedure in > order to establish this key between the two. LKH can work without a > backchannel, however, provided there is some means for the controller/ > server to communicate securely with the member. For example, if the > server had the member's public key, it could encrypt a symmetric key > (the KEK) in this public key and multicast it to the group. All > group members would receiver this message but only one member would > be able to use it, and there must be some means to uniquely identify > this member. > Mark > On Feb 12, 2007, at 7:25 AM, Elena Scialpi wrote: >> Hi, >> if I use LKH each member has one KEK(different to the other >> member) to >> decrypt the TEK. >> To PUSH the TEK I must use unicast messages! Can't I use a >> multicast message? >> Thank you in advance! >> Elena Scialpi >> -- >> >> >> LIIS >> Laboratorio per l'Internetworking e l'Interoperabilita' tra i Sistemi >> http://liis.unile.it >> http://www.campusdelsalento.it/ >> Office-Fax: (+39) 0832-297310 >> c/o Dipartimento di Ingegneria dell'Innovazione >> Via per Monteroni >> 73100 Lecce LE, Italy >> >> _______________________________________________ >> 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 _______________________________________________ MSEC mailing list MSEC@ietf.org https://www1.ietf.org/mailman/listinfo/msec From ddo_ppoppo@yahoo.co.jp Wed Feb 28 22:43:36 2007 Return-path: Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcCe-0002hT-Lk for msec-archive@ietf.org; Wed, 28 Feb 2007 22:43:36 -0500 Received: from [222.127.16.89] (helo=pc29) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1HMcCc-0005bg-Ez for msec-archive@ietf.org; Wed, 28 Feb 2007 22:43:36 -0500 To: From: =?iso-2022-jp?B?ZGRvX3Bwb3Bwb0B5YWhvby5jby5qcA==?= Subject: =?iso-2022-jp?B?GyRCRVRGO0lcOClKTD9NOkpIa0wpNmYzWkl0GyhC?= MIME-Version: 1.0 Reply-To: Date: Thu, 01 Mar 2007 12:37:10 +0900 Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.5 (++++) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 $B$O$8$a$^$7$F!";dEl>k9I2L$H?=$7$^$9!#(B $BK\F|$O;d$I$b$N1?1D$9$k%O%$%/%*%j%F%#%5!<%/%k(B $B!X?M:JHkL)6f3ZIt!Y$N$4>R2p$G$9!#(B $BEv6f3ZIt$G$O%;%C%/%9%l%9$GG:$`%+%C%W%k$d(B $B2K$H$*6b$r;}$FM>$9=w@-o;vBV$G$9$N$G:#2s$O8r:]$,@.N)$7$F$bCK=w$H$bNA6b$O0l@Z$$$?$@$-$^$;$s!#(B $B$b$A$m$s!"EPO?NA$d7n2qHq$J$IEv6f3ZIt$GDL>oI,MW$JHqMQ$O0l@ZL5NA$H$5$;$FD:$-$^$9!#(B $B$3$A$i$N0lJ}E*$J$4O"Mm$G$9$N$G;22CIT;22C$O$4<+?H$G$4H=CG$/$@$5$$!#(B http://freena.y7.net/free3/ $B"($3$A$i$N%5%$%H$K$OEv6f3ZIt0J30$N$*5RMM$bB??t$$$i$C$7$c$$$^$9!#(B $B!!HkL)$N9g8@MU(B $B!X%j%C%A5^Jg!Y(B $B$r$*K:$l$K$J$i$J$$MM$*4j$$$$$?$7$^$9!#(B $BEl>k(B