From msec-bounces@securemulticast.org Fri Jan 06 15:13:04 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EuxxP-0004hp-BN for msec-archive@megatron.ietf.org; Fri, 06 Jan 2006 15:13:04 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03518 for ; Fri, 6 Jan 2006 15:11:45 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 93C7F2C9B4; Fri, 6 Jan 2006 15:12:57 -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 2F3782C98B for ; Fri, 6 Jan 2006 15:12:56 -0500 (EST) Received: (qmail 29223 invoked by uid 3269); 6 Jan 2006 20:12:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 29219 invoked from network); 6 Jan 2006 20:12:56 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 6 Jan 2006 20:12:56 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id E52F468377 for ; Fri, 6 Jan 2006 15:12:55 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k06KCWgi021049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2006 12:12:33 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k06KCSgv017657 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jan 2006 12:12:29 -0800 (PST) Message-Id: <6.2.5.6.2.20060106111855.039fcca0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 06 Jan 2006 12:12:21 -0800 To: "Karl Norrman (KI/EAB)" , vesa.lehtovirta@ericsson.com, carrara@kth.se, Elisabetta.Carrara@enisa.eu.int From: Lakshminath Dondeti In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D76@esealmw104.eemea. ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D76@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti@watson.ibm.com, Russ Housley , msec@securemulticast.org Subject: [MSEC] Re: Submission of draft-ietf-msec-newtype-keyid-03.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org At 04:47 AM 11/30/2005, Karl Norrman (KI/EAB) wrote: >Dear Editor, > >please submit the new version of draft-ietf-msec-newtype-keyid-03.txt, >work item in the msec WG. > >Best Regards, >Karl Norrman >Ericsson > With apologies for the delay, here is my review of the newtype-keyid draft with a request (as a member of the WG) for some clarifications. First, I think that this version is much better than the previous one, especially the sec considerations section. *** In Section 1, 3rd paragraph: The draft says " The rationale behind this is that it would be inconvenient for subscribers to publish the decryption keys enabling non-subscribers to view the content." We have been in uncomfortable in MSEC on this notion. The closest I came to agreeing to this is the cost of the attack (cost uploading/downloading keys using the unicast channel) vs. value of the content (subscription charge for the broadcast service) argument. Perhaps that notion can be included in the draft. Personally I think "inconvenience" is not a strong enough argument. *** In the last paragraph of Section 2: Please expand DCF. (Please expand the first occurrence of all abbreviations, especially the non-IETF ones). *** In the last paragraph of Section 3: There is a provision to include multiple Key ID types in the GenExt payload. Could you please clarify the use case further? Is the intent to carry MSKs and MTKs in the same MIKEY message? *** In the security considerations section: First a question (not specific to this section) on MSK delivery: is the MSK always delivered under the protection of individual MUKs? If so, perhaps a statement along those lines will help (MSK delivery MUST be protected by MUK. MTK delivery MUST be protected by MSK or something along those lines). ** Group authentication for MTK delivery needs more clarification. Other standards have also avoided source authenticating group key delivery via broadcast with the reason that as long as the data itself is not source authenticated, not source authenticating the key delivery will only make it slightly (for some definition of slightly :-)) easier for the "insider" attacker. (A side note: The problem with large broadcast groups however is that it is presumably easy to become an "insider"). I propose the (some variation of the) following notes to be added: The threat model assumes that the data and the group key delivery via broadcast are integrity protected with group authentication. If source authentication is applied to the data (using SRTP-TESLA for example), the group key delivery MUST also be source authenticated. (Note: Since there is no relevant specification for source authenticated MTK delivery, perhaps this document should say that the specified extension is incompatible with SRTP-TESLA). Finally, perhaps we need a section describing the compatibility of this extension with the main MIKEY spec and other extensions to MIKEY. I mentioned the SRTP-TESLA extension in the previous paragraph. My recollection of 3830 is that it explicitly states that there is no "rekey" protocol specified. This extension changes that notion. This draft should note that I think to help readers of MIKEY specs. There are also notes in 3830 on how MIKEY fits within the GKMarch (4046) RFC. Please include notes on how this extension differs with 3830 in that respect. (Note: While that mind sound like many things, I think a few sentences can sufficiently cover everything). Thanks again folks. Is Elisabetta's contact information current in the draft? best regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From stitchwitch@earthlink.net Sun Jan 08 18:14:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Evjjj-0008VG-2E for msec-archive@megatron.ietf.org; Sun, 08 Jan 2006 18:14:07 -0500 Received: from ppp85-140-33-149.pppoe.mtu-net.ru (ppp85-140-33-149.pppoe.mtu-net.ru [85.140.33.149]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25540 for ; Sun, 8 Jan 2006 18:12:43 -0500 (EST) Received: (hell 88470 invoked from network); Sun, 08 Jan 2006 15:25:30 -0500 MIME-Version: 1.0 Message-Id: <614218190191634769501.258@microsoft.com> X-Originating-Ip: [71.94.155.211] Subject: Amazing, Earline From: Lindsay Lockett X-Mailer: lingerie 16.04.89733664 Date: Sun, 08 Jan 2006 15:34:43 -0500 To: msec-archive@ietf.org X-Confirm-Reading-To: superstamp@earthlink.net Disposition-Notification-To: pwipx@freeserve.com Content-Type: multipart/mixed; boundary="------=8410353580" Content-Transfer-Encoding: 7bit --------=8410353580 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Expenditures rise to meet income.God knows best he hasn't arranged your anatomy so as to make it easy for you to pat yourself on the back.
Every guest hates the others, and the host hates them all. --------=8410353580 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Billie-> http://efekuw.dateinn.info/?awkjnexwpqqyhmtpfazpoqreegd --------=8410353580-- From msec-bounces@securemulticast.org Thu Jan 12 10:45:06 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex4dO-0007A1-8X for msec-archive@megatron.ietf.org; Thu, 12 Jan 2006 10:45:06 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25713 for ; Thu, 12 Jan 2006 10:43:44 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 2247D2BECE; Thu, 12 Jan 2006 10:45:05 -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 E23032BE9E for ; Thu, 12 Jan 2006 10:45:02 -0500 (EST) Received: (qmail 61482 invoked by uid 3269); 12 Jan 2006 15:45:02 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 61479 invoked from network); 12 Jan 2006 15:45:02 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 12 Jan 2006 15:45:02 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 982026838F for ; Thu, 12 Jan 2006 10:45:02 -0500 (EST) Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0CFj0oS011098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2006 07:45:00 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-151.qualcomm.com [10.50.68.151]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0CFiwgv018381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 12 Jan 2006 07:44:59 -0800 (PST) Message-Id: <6.2.5.6.2.20060112064125.03d1a6d0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 12 Jan 2006 07:43:11 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] MSEC status update request X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, MSEC made some progress between Vancouver and now: * Policy Token spec finished IETF LC and will be on the IESG agenda soon. * Bootstrapping TESLA spec just cleared the final DISCUSS and an approval announcement should be out soon. That's pretty good progress during the holiday season. Many thanks to the authors of those two documents, Andrea, Uri, and Hugh, and Steffen and Hannes for quick turnaround on the revisions and to Russ for quick reviews and action. Looking forward to the Dallas meeting, I'd like to get a quick status update from the authors of the current contributions (I will be sending individual requests following this email), and also notes on any plans for new contributions for presentation at the Dallas meeting. We have a few milestones to meet between now and Dallas and we need to make all efforts to meet them. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From clherrick@geocities.com Thu Jan 12 14:54:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ex8WX-00083n-P3 for msec-archive@megatron.ietf.org; Thu, 12 Jan 2006 14:54:17 -0500 Received: from c64-135.icpnet.pl (c64-135.icpnet.pl [62.21.64.135]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13404 for ; Thu, 12 Jan 2006 14:52:43 -0500 (EST) Received: (from caldera@microsoft.com) by microsoft.com (5.4.77/3.1.0/Submit) id rood; Thu, 12 Jan 2006 09:50:31 -0500 Message-ID: <480057@cornelius> From: Lou Vinson To: msec-archive@ietf.org Subject: Amazing, Curt Date: Thu, 12 Jan 2006 14:03:12 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 97437692.6131010.20747.20577 X-MimeOLE: Produced By Microsoft MimeOLE 252035.16387.4101.60059224 Content-Type: multipart/mixed; boundary="------=4987961158985" Content-Transfer-Encoding: 8bit --------=4987961158985 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


I worked very hard. I felt I could play the game. The only thing that could stop me was myself.
Children have never been very good at listening to their elders, but they have never failed to imitate them.Where children are, there is the golden age. --------=4987961158985 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Karina-> http://iltwbv.marchstamp.info/?fagngpxwpqqywcemimzpoadvjdj --------=4987961158985-- From bluesguyis@email.msn.com Fri Jan 13 12:00:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExSI2-0006gw-Gh for msec-archive@megatron.ietf.org; Fri, 13 Jan 2006 12:00:38 -0500 Received: from fequs.info ([218.201.54.188]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21861 for ; Fri, 13 Jan 2006 11:59:10 -0500 (EST) Received: (refract 01999 invoked from network); Fri, 13 Jan 2006 17:18:59 -0500 MIME-Version: 1.0 Message-Id: <448824575079624036587.965@microsoft.com> X-Originating-Ip: [251.150.63.65] Subject: Amazing, Luz From: Jeff Orozco X-Mailer: squeamish 9.318.7201191 Date: Fri, 13 Jan 2006 19:45:44 -0500 To: msec-archive@ietf.org X-Confirm-Reading-To: davewil@digidem.com Disposition-Notification-To: lisya@geocities.com Content-Type: multipart/mixed; boundary="------=098674278154" Content-Transfer-Encoding: base64 --------=098674278154 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Honor is simply the morality of superior men.Desire! That's the one secret of every man's career. Not education. Not being born with hidden talents. Desire.
If we could first know where we are, and whither we are tending, we could then better judge what to do, and how to do it.We need only travel enough to give our intellects an airing. --------=098674278154 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Aaron-> http://iiafgi.giftfast.info/?jpicttxwpqqysnvqcizpokdcubs --------=098674278154-- From beaver@homenet.ie Fri Jan 13 18:25:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ExYIr-000699-Fz for msec-archive@megatron.ietf.org; Fri, 13 Jan 2006 18:25:53 -0500 Received: from vmgcwlbablxs.biz ([220.234.45.210]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20937 for ; Fri, 13 Jan 2006 18:24:27 -0500 (EST) Received: from maturate.upton.com (dumpty [16.34.18.102]) by disembowel.com (valid) with fulfill id 691099459039914 for ; Fri, 13 Jan 2006 12:39:56 -0500 Date: Fri, 13 Jan 2006 13:32:32 -0500 Message-Id: <457395872247379594450823@microsoft.com> From: Norbert Larsen To: msec-archive@ietf.org Subject: Amazing, Michel X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: manumission 77.54.670655 X-MimeOLE: strawberry 4.88.93583797 Content-Type: multipart/mixed; boundary="------=010454456036" Content-Transfer-Encoding: base64 --------=010454456036 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


God has two dwellings one in heaven, and the other in a meek and thankful heart.The nail that sticks up will be hammered down.
All wish to possess knowledge, but few, comparatively speaking, are willing to pay the price. --------=010454456036 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Tammi-> http://counciradi.com/?a=1065 --------=010454456036-- From msec-bounces@securemulticast.org Mon Jan 16 11:17:22 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EyX2o-0002nQ-6Z for msec-archive@megatron.ietf.org; Mon, 16 Jan 2006 11:17:22 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24420 for ; Mon, 16 Jan 2006 11:15:56 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 8FE812C4A1; Mon, 16 Jan 2006 11:17: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 690BD2C35D for ; Mon, 16 Jan 2006 11:17:17 -0500 (EST) Received: (qmail 93067 invoked by uid 3269); 16 Jan 2006 16:17:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 93063 invoked from network); 16 Jan 2006 16:17:17 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 16 Jan 2006 16:17:17 -0000 Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by klesh.pair.com (Postfix) with ESMTP id 573F868382 for ; Mon, 16 Jan 2006 11:17:17 -0500 (EST) Received: by xproxy.gmail.com with SMTP id s8so919623wxc for ; Mon, 16 Jan 2006 08:17:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=ddP7rN99iH6W4z4Gk/QaPIrdBFooOKyJujlhXRj6rEYVtxe+ixXPseYmpXbXGZueiyiOFRcRtBMIXbNCnE7VujcksWvg7aZFDmzdkkKMnHJE02jMemHM8y0FTcujyz33BnVeFWu/FXyRleWzrRXtuRtadkXGr8RkHHDkqIP3D9I= Received: by 10.70.82.5 with SMTP id f5mr8150294wxb; Mon, 16 Jan 2006 08:17:16 -0800 (PST) Received: by 10.70.56.9 with HTTP; Mon, 16 Jan 2006 08:17:16 -0800 (PST) Message-ID: <4166af450601160817n388de146j437fc67f07f463a5@mail.gmail.com> Date: Mon, 16 Jan 2006 16:17:16 +0000 From: Prashant Pilllai To: msec@securemulticast.org MIME-Version: 1.0 Subject: [MSEC] Multicast security AAA X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1471159046==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============1471159046== Content-Type: multipart/alternative; boundary="----=_Part_15025_1109114.1137428236733" ------=_Part_15025_1109114.1137428236733 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I have been working previously with RADIUS and DIAMETER protocols for AAA. I wanted to know if there is any work done in the MSEC group for AAA for multicast security? like MSEC with RADIUS/DIAMETER? Does the MSEc group look into how the access control is provided for a multicast group? e.g. A user wants to join a multicast group. He would sen= d an IGMP join message (to the routers connected to it...all the way to the source?). is there a method to know who this user is and validate his credentials? something like secure extensions for IGMP? How does the multicast source know that is is a valid new user and that he should be allowed to join and hence initiate a re-keying mechanisms? Thanks. Regards Prashant Pillai ------=_Part_15025_1109114.1137428236733 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
Hi All,
 
I have been working previously with RADIUS and DIAMETER protocols for = AAA.
 
I wanted to know if there is any work done in the MSEC group for AAA f= or multicast security? like MSEC with RADIUS/DIAMETER?
 
Does the MSEc group look into how the access control is provided for a= multicast group?  e.g. A user wants to join a multicast group. H= e would send an IGMP join message (to the routers connected to it...all the=  way to the source?). is there a method to know who this user is and v= alidate his credentials? something like secure extensions for IGMP?
 
How does the multicast source know that is is a valid new user and tha= t he should be allowed to join and hence initiate a re-keying mechanis= ms? 
 
Thanks.
 
Regards
Prashant Pillai
------=_Part_15025_1109114.1137428236733-- --===============1471159046== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1471159046==-- From corps@earthlink.net Tue Jan 17 05:13:56 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eynqe-00013N-Ro for msec-archive@megatron.ietf.org; Tue, 17 Jan 2006 05:13:56 -0500 Received: from c-66-31-91-168.hsd1.ma.comcast.net (@c-66-31-91-168.hsd1.ma.comcast.net [66.31.91.168]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02111 for ; Tue, 17 Jan 2006 05:12:31 -0500 (EST) Received: (from spiritual@microsoft.com) by microsoft.com (78.7.8/28.77.0/Submit) id stem; Tue, 17 Jan 2006 07:53:45 -0500 Date: Tue, 17 Jan 2006 11:55:28 -0500 Message-Id: <0.2@microsoft.com> From: Young.Coulter.corps@earthlink.net To: msec-archive@ietf.org Subject: Amazing, Deanne X-Priority: 3 X-Mailer: buttonweed connivance Mailer Content-Type: multipart/mixed; boundary="------=9220262172547" Content-Transfer-Encoding: 8bit --------=9220262172547 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


Fidelity purchased with money, money can destroy.What is thine is mine, and all mine is thine.
I will act as if what I do makes a difference. --------=9220262172547 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Rupert-> http://brooba.info/?4Zffaabf443b15fSbaedd4596f08287c --------=9220262172547-- From msec-bounces@securemulticast.org Wed Jan 18 04:19:59 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ez9Tx-0004Lv-Qg for msec-archive@megatron.ietf.org; Wed, 18 Jan 2006 04:19:59 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21477 for ; Wed, 18 Jan 2006 04:18:31 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B036A2CA7D; Wed, 18 Jan 2006 04:19:56 -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 A41D12CA79 for ; Wed, 18 Jan 2006 04:19:54 -0500 (EST) Received: (qmail 89087 invoked by uid 3269); 18 Jan 2006 09:19:54 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 89084 invoked from network); 18 Jan 2006 09:19:54 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Jan 2006 09:19:54 -0000 Received: from web25006.mail.ukl.yahoo.com (web25006.mail.ukl.yahoo.com [217.12.10.42]) by klesh.pair.com (Postfix) with SMTP id 335916838E for ; Wed, 18 Jan 2006 04:19:54 -0500 (EST) Received: (qmail 78487 invoked by uid 60001); 18 Jan 2006 09:19:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=kaB0DGOCebxFk1nVkUTILxuw2UMDIPoUWhUA46plnLUTrA7CpCgSGa0btG6nwPjD7LvbZ5EyxPfYv1eIyO1iYrQ5hJ8IklMMIX3MZ1YCmehbYUMhKQyKdWoHZmKXc6Q4CcrKjAnKdTssCGF/Ix9mb8JXF4nssfasNcWxi9gM8iI= ; Message-ID: <20060118091953.78485.qmail@web25006.mail.ukl.yahoo.com> Received: from [131.227.231.45] by web25006.mail.ukl.yahoo.com via HTTP; Wed, 18 Jan 2006 09:19:53 GMT Date: Wed, 18 Jan 2006 09:19:53 +0000 (GMT) From: Tommy Chan Subject: [MSEC] Multicast Security To: msec@securemulticast.org In-Reply-To: <6.2.5.6.2.20060112064125.03d1a6d0@qualcomm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Content-Transfer-Encoding: 8bit Hi all, I have a few questions. Hope that someone could help me to clear my doubts. 1. How the users know the existent of the group controller in the first place? In a distributed design, does it mean that a user know all the GCs? So in this case, how the user know which GC should he contact? 2. How can a GC ensure that all users receive the rekey information in a timely manner? (Refer to GSA - Catergoty 2 SA). Cheers. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From linmin@geocities.com Wed Jan 18 10:34:28 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzFKO-0002yE-78 for msec-archive@megatron.ietf.org; Wed, 18 Jan 2006 10:34:28 -0500 Received: from pc-18-49-214-201.cm.vtr.net (pc-18-49-214-201.cm.vtr.net [201.214.49.18]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25382 for ; Wed, 18 Jan 2006 10:32:59 -0500 (EST) Received: from mail by microsoft.com with local id 14-1-4; Wed, 18 Jan 2006 06:08:15 -0500 Message-ID: <0864822@confectionery> From: Garland Ivey To: msec-archive@ietf.org Subject: Amazing, Meredith Date: Wed, 18 Jan 2006 10:00:47 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 7865.9954.0026836.00668078 X-MimeOLE: Produced By Microsoft MimeOLE 108835.39725058.56497.293154 Content-Type: multipart/mixed; boundary="------=24071252363640" Content-Transfer-Encoding: 7bit --------=24071252363640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


The control of the palate is a valuable aid for the control of the mind.I know of no country in which there is so little independence of mind and real freedom of discussion as in America.
As a child my family's menu consisted of two choices: take it, or leave it.Genuine poetry can communicate before it is understood. --------=24071252363640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Nigel-> --------=24071252363640-- From msec-bounces@securemulticast.org Wed Jan 18 15:21:38 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzJoI-0004CQ-Qf for msec-archive@megatron.ietf.org; Wed, 18 Jan 2006 15:21:38 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20283 for ; Wed, 18 Jan 2006 15:20:11 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E04B02CB80; Wed, 18 Jan 2006 15:21:35 -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 DB9722C8BC for ; Wed, 18 Jan 2006 15:21:34 -0500 (EST) Received: (qmail 98769 invoked by uid 3269); 18 Jan 2006 20:21:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 98766 invoked from network); 18 Jan 2006 20:21:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 18 Jan 2006 20:21:34 -0000 Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by klesh.pair.com (Postfix) with ESMTP id 8BE6C68377 for ; Wed, 18 Jan 2006 15:21:34 -0500 (EST) 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 k0IKLX4D019632; Wed, 18 Jan 2006 14:21:33 -0600 Received: from coyote.columbia.ads.sparta.com ([157.185.80.112]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id k0IKLNpd018990; Wed, 18 Jan 2006 14:21:26 -0600 Received: from [157.185.81.145] ([157.185.81.145]) by coyote.columbia.ads.sparta.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2006 15:21:21 -0500 In-Reply-To: <20060118091953.78485.qmail@web25006.mail.ukl.yahoo.com> References: <20060118091953.78485.qmail@web25006.mail.ukl.yahoo.com> Mime-Version: 1.0 (Apple Message framework v623) Message-Id: <691db46cf2189c67da4524887523af82@sparta.com> From: Hugh Harney Subject: Re: [MSEC] Multicast Security Date: Wed, 18 Jan 2006 15:21:23 -0500 To: Tommy Chan X-Mailer: Apple Mail (2.623) X-OriginalArrivalTime: 18 Jan 2006 20:21:21.0911 (UTC) FILETIME=[BF5B3870:01C61C6C] Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0009852684==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org --===============0009852684== Content-Type: multipart/alternative; boundary=Apple-Mail-24-394693643 --Apple-Mail-24-394693643 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Hi, I can't speak for all of MSEC, but I can try to give you a better idea of how GSAKMP dealt with the issues you raised. 1) Discovery of the group was left out of the GSAKMP specification because there are so many ways that could be accomplished. The most common are email, web servers, announcement protocols... We did specify the information that should be distributed during that discovery process - namely the GSAKMP suite information that would allow you to attempt to join the group. 2) What your asking is how do we provide reliable communications of a multicasted message. The answer is we don't. We (GSAKMP) do provide an approach to help with the problem (multiple transmissions of the Rekey message). We also provide timeout counters that are configurable to ensure that the group stays within a secure state, given the probability that someone will not get the rekey. If a member fails to get the rekey message there are several potential things that can occur. 1) they get the retransmission of the rekey message, 2) the group key changes and they are dropped from the group then they rejoin the group, or 3) they get the rekey message sent to them via an unspecified service. vr hugh On Jan 18, 2006, at 4:19 AM, Tommy Chan wrote: > Hi all, > I have a few questions. Hope that someone could help > me to clear my doubts. > > 1. How the users know the existent of the group > controller in the first place? In a distributed > design, does it mean that a user know all the GCs? So > in this case, how the user know which GC should he > contact? > > 2. How can a GC ensure that all users receive the > rekey information in a timely manner? (Refer to GSA - > Catergoty 2 SA). > > Cheers. > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > > Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 --Apple-Mail-24-394693643 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, I can't speak for all of MSEC, but I can try to give you a better idea of how GSAKMP dealt with the issues you raised. 1) Discovery of the group was left out of the GSAKMP specification because there are so many ways that could be accomplished. The most common are email, web servers, announcement protocols... We did specify the information that should be distributed during that discovery process - namely the GSAKMP suite information that would allow you to attempt to join the group. 2) What your asking is how do we provide reliable communications of a multicasted message. The answer is we don't. We (GSAKMP) do provide an approach to help with the problem (multiple transmissions of the Rekey message). We also provide timeout counters that are configurable to ensure that the group stays within a secure state, given the probability that someone will not get the rekey. If a member fails to get the rekey message there are several potential things that can occur. 1) they get the retransmission of the rekey message, 2) the group key changes and they are dropped from the group then they rejoin the group, or 3) they get the rekey message sent to them via an unspecified service. vr hugh On Jan 18, 2006, at 4:19 AM, Tommy Chan wrote: Hi all, I have a few questions. Hope that someone could help me to clear my doubts. 1. How the users know the existent of the group controller in the first place? In a distributed design, does it mean that a user know all the GCs? So in this case, how the user know which GC should he contact? 2. How can a GC ensure that all users receive the rekey information in a timely manner? (Refer to GSA - Catergoty 2 SA). Cheers. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec Hugh Harney Sparta, Inc. hh@sparta.com 7075 Samuel Morse Drive (410) 872-1515 x203 Columbia, MD, 21046 --Apple-Mail-24-394693643-- --===============0009852684== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0009852684==-- From jgrimsley@financialshop.com Thu Jan 19 14:28:32 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzfSS-0008MF-2M for msec-archive@megatron.ietf.org; Thu, 19 Jan 2006 14:28:32 -0500 Received: from 226.254.uio.satnet.net (226.254.uio.satnet.net [200.63.254.226]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19383 for ; Thu, 19 Jan 2006 14:27:01 -0500 (EST) Received: from localhost (localhost [91.28.163.228]) by habitantsiderealbiography.sneerlindquistemulsionplasm.com (136.195.236.19/156.207.54.183/SuSE Linux 0.7) with SMTP id 6 for barony; Thu, 19 Jan 2006 12:39:03 -0500 Message-ID: <3082981@putt> From: Adrian Hardin To: msec-archive@ietf.org Subject: Amazing, Dirk Date: Thu, 19 Jan 2006 14:24:18 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 8364.8024.8703307.85131 X-MimeOLE: Produced By Microsoft MimeOLE 485047.034503.74646.84941 Content-Type: multipart/mixed; boundary="------=015428302619" Content-Transfer-Encoding: base64 --------=015428302619 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


A man who lives right, and is right, has more power in his silence than another has by his words.All women are flirts, but some are restrained by shyness, and others by sense.
The more I see of men, the more I like dogs.He that bringeth a present findeth the door open.We need not fear life, because God is the Ruler of all and we need not fear death, because He shares immortality with us. --------=015428302619 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Sergio-> http://wvudil.saudichamber.com/?99965177 --------=015428302619-- From msec-bounces@securemulticast.org Thu Jan 19 16:46:53 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzhcL-00032n-Bf for msec-archive@megatron.ietf.org; Thu, 19 Jan 2006 16:46:53 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29568 for ; Thu, 19 Jan 2006 16:45:25 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 996842C942; Thu, 19 Jan 2006 16:46:51 -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 2DC162B95A for ; Thu, 19 Jan 2006 16:46:51 -0500 (EST) Received: (qmail 24291 invoked by uid 3269); 19 Jan 2006 21:46:51 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 24288 invoked from network); 19 Jan 2006 21:46:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Jan 2006 21:46:50 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id E5B5C6838B for ; Thu, 19 Jan 2006 16:46:50 -0500 (EST) Received: (qmail 48546 invoked from network); 19 Jan 2006 16:46:49 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 19 Jan 2006 16:46:49 -0500 Received: (qmail 83299 invoked from network); 19 Jan 2006 16:46:49 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 19 Jan 2006 16:46:49 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k0JJJqp03570; Thu, 19 Jan 2006 14:19:52 -0500 Date: Thu, 19 Jan 2006 14:19:51 -0500 (EST) From: George Gross To: Prashant Pilllai Subject: Re: [MSEC] Multicast security AAA In-Reply-To: <4166af450601160817n388de146j437fc67f07f463a5@mail.gmail.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Prashant, inline below... On Mon, 16 Jan 2006, Prashant Pilllai wrote: > Hi All, > > I have been working previously with RADIUS and DIAMETER protocols for AAA. > > I wanted to know if there is any work done in the MSEC group for AAA for > multicast security? like MSEC with RADIUS/DIAMETER? You may wish to look at the MSEC working group's IETF58 meeting viewgraphs archived at www.securemulticast.org. I presented an overview of the topic of MSEC/AAA. However, there was no consensus to develop those concepts further. > > Does the MSEc group look into how the access control is provided for a > multicast group? e.g. A user wants to join a multicast group. He would send > an IGMP join message (to the routers connected to it...all the way to the > source?). is there a method to know who this user is and validate his > credentials? something like secure extensions for IGMP? AFAIK there have not been any (recent) attempts in MAGMA or MSEC to enhance IGMP along those lines. There has been an AAA multicast requirements Internet Draft floating in the mboned working group: draft-ietf-mboned-maccnt-req-02.txt But that draft's architectural focus seems to be controlling an end systems's IGMP access to the Service Provider's multicast routing infrastructure rather than using a MSEC group key management protocol in combination with AAA to protect the multicasted content. In other words, the MSEC group key management protocol exchange would occur in parallel and separate from the IGMP protocol exchange. Of course, any proposed piggybacking of AAA related payloads onto IGMP would require significant IGMP protocol changes to be secure... hth, George > > How does the multicast source know that is is a valid new user and that he > should be allowed to join and hence initiate a re-keying mechanisms? > > Thanks. > > Regards > Prashant Pillai > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jan 23 16:54:00 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F19dQ-0006lq-92 for msec-archive@megatron.ietf.org; Mon, 23 Jan 2006 16:54:00 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24221 for ; Mon, 23 Jan 2006 16:52:30 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id F20FC2BBCE; Mon, 23 Jan 2006 16:53:57 -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 8F89B2B984 for ; Mon, 23 Jan 2006 16:53:56 -0500 (EST) Received: (qmail 97608 invoked by uid 3269); 23 Jan 2006 21:53:56 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 97605 invoked from network); 23 Jan 2006 21:53:56 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 23 Jan 2006 21:53:56 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 2527668382 for ; Mon, 23 Jan 2006 16:53:56 -0500 (EST) Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0NLrr5m021270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 23 Jan 2006 13:53:54 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-214.qualcomm.com [10.50.68.214]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0NLrq9g008971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Jan 2006 13:53:52 -0800 (PST) Message-Id: <6.2.5.6.2.20060123134925.03c60d68@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 23 Jan 2006 13:53:50 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, There is an "Abstain" and a "DISCUSS" recorded as part of the IESG evaluation of the Policy Token spec. Andrea, Uri, and Russ have worked diligently to come up with the following resolution. Please look at the following link for the history of the document evaluation: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1841&filename=draft-ietf-msec-policy-token-sec If you have any thoughts or objections to the new text, please post your comments ASAP to the list. thanks and regards, Lakshminath >Please look for (overall consensus so far) and >(issues that haven't been covered yet, there is only one, on the >IANA comment) below. > >best regards, >Lakshminath > > > >1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a >number of choices and structures that seem like they are intended to >be extended in the future. Without extensibility markers, a >conforming implementation will reject a sequence or choice with >elements not permitted by the abstract syntax. > > >The EXPORTS statement is to be removed so that any structure def can be >exported. > > > > >2) There is no extensibility or versioning strategy described in the >document. How do we add fields? What should recipients of a token do >if they do not understand part of it? > > >A Policy Token version indicator is to be added to the TokenID. > > > > >Russ provided the following example that we might use: > TBSCertificate ::= SEQUENCE { > version [0] Version DEFAULT v1, > .... > > Version ::= INTEGER { v1(0), v2(1), v3(2) } > > > > > >"Implementations encountering unknown protocol identifiers MUST handle >this gracefully by providing indicators that an unknown protocol is among >the sequence of permissible protocols. If the unknown protocol is the only >allowable protocol in the sequence, then the implementation cannot support >that field and the member cannot join the group. >It is a matter of local policy whether a join is permitted when >an unknown protocol exists among other allowable, known protocols." > > >The above will be added to provide >handling instructions when encountering unknown protocols. > > > >Under the main token structure it will say that additional protocols >SHOULD NOT be added unless the MSEC architecture changes. > > > >3) It's not clear that the GSAKMP document combined with this document >provides enough mandatory to implement features that any two >implementations of this specification will work together. The GSAKMP >document specifies mandatory to implement mechanisms for GSAKMP. >However the policy token allows for a wide variety of combinations of >protocols. For example, a policy token could specify one protocol for >registration, one protocol for rekey, and a completely different >protocol for de-registration. If only one of these is GSAKMP, what >happens? Where is it specified what combinations a GM, a GC/KS etc >must support in terms of policy token contents? > >I understand the issue, but the token's purpose is to tie the >abstract MSEC >architecture to a configurable system. The MSEC architecture allows for any >of these protocols for registration, de-registration, etc. and does not >specify what the mandatory to implement protocols are. To say that the >appendix B and appendix C protocols are the mandatory-to-implement protocols >would mean that the MSEC architecture now requires those protocols. This is >one case where I believe a mandatory to implement scheme would be a >disservice to the community. > >Interoperability testing for the token, really becomes system >interoperability testing vs. protocol interoperability testing. > > > >4) IANA Comments: >The IANA Considerations section requests that 13 object identifiers >be assigned. >In which registry should these be assigned? IANA needs clarification. > > > >Statement to IANA section will essentially say that the spec is extended >through specification. Those specifying new objects will register them with >IANA. Those that change the structure of the PT must change the version >indicator. > > > > >The resolution does not address the question on "which registry" >should be used. I think this requires a new registry, right? > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Jan 23 19:24:13 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Byn-0000VP-Fi for msec-archive@megatron.ietf.org; Mon, 23 Jan 2006 19:24:13 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14284 for ; Mon, 23 Jan 2006 19:22:42 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 497E02C785; Mon, 23 Jan 2006 19:24:11 -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 C32C52C772 for ; Mon, 23 Jan 2006 19:24:09 -0500 (EST) Received: (qmail 28898 invoked by uid 3269); 24 Jan 2006 00:24:09 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 28895 invoked from network); 24 Jan 2006 00:24:09 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jan 2006 00:24:09 -0000 Received: from smtp-out1.oct.nac.net (smtp-out1.oct.nac.net [209.123.233.211]) by klesh.pair.com (Postfix) with SMTP id 877856837D for ; Mon, 23 Jan 2006 19:24:09 -0500 (EST) Received: (qmail 27184 invoked from network); 24 Jan 2006 00:24:08 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 24 Jan 2006 00:24:08 -0000 Received: (qmail 79562 invoked from network); 23 Jan 2006 19:24:08 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 23 Jan 2006 19:24:08 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k0NLuTS15810; Mon, 23 Jan 2006 16:56:29 -0500 Date: Mon, 23 Jan 2006 16:56:29 -0500 (EST) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary) In-Reply-To: <6.2.5.6.2.20060123134925.03c60d68@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi, I support the proposed set of resolutions listed below. Adding the PT version field incurrs a minor change in core PT implementation, but it makes sense, and it is not a hardship to add this. As for the core PT IANA registry, my first thought is that creating a distinct new IANA registry seems like the best way forward. I had not considered the "how to register at IANA" aspect of the PT design lifecycle. the current and our future MSEC OID definitions do need a home. I'm assuming that there isn't an IANA registry already in existence that could be placed into this role? the GSAKMP one is not the right place for this, since the core PT is key management protocol independent... hth, George On Mon, 23 Jan 2006, Lakshminath Dondeti wrote: > Hi all, > > There is an "Abstain" and a "DISCUSS" recorded as part of the IESG > evaluation of the Policy Token spec. Andrea, Uri, and Russ have > worked diligently to come up with the following resolution. Please > look at the following link for the history of the document evaluation: > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1841&filename=draft-ietf-msec-policy-token-sec > > If you have any thoughts or objections to the new text, please post > your comments ASAP to the list. > > thanks and regards, > Lakshminath > > > > >Please look for (overall consensus so far) and > >(issues that haven't been covered yet, there is only one, on the > >IANA comment) below. > > > >best regards, > >Lakshminath > > > > > > > >1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a > >number of choices and structures that seem like they are intended to > >be extended in the future. Without extensibility markers, a > >conforming implementation will reject a sequence or choice with > >elements not permitted by the abstract syntax. > > > > > >The EXPORTS statement is to be removed so that any structure def can be > >exported. > > > > > > > > > >2) There is no extensibility or versioning strategy described in the > >document. How do we add fields? What should recipients of a token do > >if they do not understand part of it? > > > > > >A Policy Token version indicator is to be added to the TokenID. > > > > > > > > > >Russ provided the following example that we might use: > > TBSCertificate ::= SEQUENCE { > > version [0] Version DEFAULT v1, > > .... > > > > Version ::= INTEGER { v1(0), v2(1), v3(2) } > > > > > > > > > > > >"Implementations encountering unknown protocol identifiers MUST handle > >this gracefully by providing indicators that an unknown protocol is among > >the sequence of permissible protocols. If the unknown protocol is the only > >allowable protocol in the sequence, then the implementation cannot support > >that field and the member cannot join the group. > >It is a matter of local policy whether a join is permitted when > >an unknown protocol exists among other allowable, known protocols." > > > > > >The above will be added to provide > >handling instructions when encountering unknown protocols. > > > > > > > >Under the main token structure it will say that additional protocols > >SHOULD NOT be added unless the MSEC architecture changes. > > > > > > > >3) It's not clear that the GSAKMP document combined with this document > >provides enough mandatory to implement features that any two > >implementations of this specification will work together. The GSAKMP > >document specifies mandatory to implement mechanisms for GSAKMP. > >However the policy token allows for a wide variety of combinations of > >protocols. For example, a policy token could specify one protocol for > >registration, one protocol for rekey, and a completely different > >protocol for de-registration. If only one of these is GSAKMP, what > >happens? Where is it specified what combinations a GM, a GC/KS etc > >must support in terms of policy token contents? > > > >I understand the issue, but the token's purpose is to tie the > >abstract MSEC > >architecture to a configurable system. The MSEC architecture allows for any > >of these protocols for registration, de-registration, etc. and does not > >specify what the mandatory to implement protocols are. To say that the > >appendix B and appendix C protocols are the mandatory-to-implement protocols > >would mean that the MSEC architecture now requires those protocols. This is > >one case where I believe a mandatory to implement scheme would be a > >disservice to the community. > > > >Interoperability testing for the token, really becomes system > >interoperability testing vs. protocol interoperability testing. > > > > > > > >4) IANA Comments: > >The IANA Considerations section requests that 13 object identifiers > >be assigned. > >In which registry should these be assigned? IANA needs clarification. > > > > > > > >Statement to IANA section will essentially say that the spec is extended > >through specification. Those specifying new objects will register them with > >IANA. Those that change the structure of the PT must change the version > >indicator. > > > > > > > > > >The resolution does not address the question on "which registry" > >should be used. I think this requires a new registry, right? > > > > > _______________________________________________ > msec mailing list > msec@securemulticast.org > http://six.pairlist.net/mailman/listinfo/msec > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jan 24 14:25:10 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1Tmw-0003HF-0e for msec-archive@megatron.ietf.org; Tue, 24 Jan 2006 14:25:10 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11329 for ; Tue, 24 Jan 2006 14:23:38 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C938B2C840; Tue, 24 Jan 2006 14:25:01 -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 37AC52C7ED for ; Tue, 24 Jan 2006 14:25:00 -0500 (EST) Received: (qmail 39975 invoked by uid 3269); 24 Jan 2006 19:24:59 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39972 invoked from network); 24 Jan 2006 19:24:59 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jan 2006 19:24:59 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 93CD268377 for ; Tue, 24 Jan 2006 14:24:59 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0OJOt8r023030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Jan 2006 11:24:56 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0OJOsFB027751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Jan 2006 11:24:55 -0800 (PST) Message-Id: <6.2.5.6.2.20060124112212.038650f8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 Jan 2006 11:24:54 -0800 To: George Gross From: Lakshminath Dondeti Subject: Re: [MSEC] Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary) In-Reply-To: References: <6.2.5.6.2.20060123134925.03c60d68@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi all, A small correction in my email below. The responses to #1 and #2 are to be read together as responses to issues #1 and #2. (I posted the correction immediately to the response to Brian C, but not here) Hi George, Thanks for your notes. Here is the latest from Sam on this: So, the response to issue 1 does not actually have anything to do with issue 1 at all. However, I think the response to issue 2 also happens to be a valid responsse to issue 1. The down side of how MSEC is handling versioning is that they cannot extend their structures without breaking old implementations. In order to extend the structure, they need to increase the version number. If they increase the version number and add fields, an implementation that does not know about these new fields must reject the encoding per 1997 ASN.1. An alternate strategy they could have adopted would be to add extensibility markers. Under that strategy, they could add fields and arms to sequences and choices. Receivers unfamiliar with a new field or arm would simply ignore that field or arm. Another alternative would be to cite an old enough ASN.1 specification before extensibility markers were introduced and claim that implementations must accept unknown additions to sequencesand choices. Any comments are welcome. regards, Lakshminath At 01:56 PM 1/23/2006, George Gross wrote: >Hi, > >I support the proposed set of resolutions listed below. Adding the PT >version field incurrs a minor change in core PT implementation, but it >makes sense, and it is not a hardship to add this. > >As for the core PT IANA registry, my first thought is that creating a >distinct new IANA registry seems like the best way forward. I had not >considered the "how to register at IANA" aspect of the PT design >lifecycle. the current and our future MSEC OID definitions do need a home. > >I'm assuming that there isn't an IANA registry already in existence that >could be placed into this role? the GSAKMP one is not the right place for >this, since the core PT is key management protocol independent... > >hth, > George > >On Mon, 23 Jan 2006, Lakshminath Dondeti wrote: > > > Hi all, > > > > There is an "Abstain" and a "DISCUSS" recorded as part of the IESG > > evaluation of the Policy Token spec. Andrea, Uri, and Russ have > > worked diligently to come up with the following resolution. Please > > look at the following link for the history of the document evaluation: > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1841&filename=draft-ietf-msec-policy-token-sec > > > > If you have any thoughts or objections to the new text, please post > > your comments ASAP to the list. > > > > thanks and regards, > > Lakshminath > > > > > > > > >Please look for (overall consensus so far) and > > >(issues that haven't been covered yet, there is only one, on the > > >IANA comment) below. > > > > > >best regards, > > >Lakshminath > > > > > > > > > > > >1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a > > >number of choices and structures that seem like they are intended to > > >be extended in the future. Without extensibility markers, a > > >conforming implementation will reject a sequence or choice with > > >elements not permitted by the abstract syntax. > > > > > > > > >The EXPORTS statement is to be removed so that any structure def can be > > >exported. > > > > > > > > > > > > > > >2) There is no extensibility or versioning strategy described in the > > >document. How do we add fields? What should recipients of a token do > > >if they do not understand part of it? > > > > > > > > >A Policy Token version indicator is to be added to the TokenID. > > > > > > > > > > > > > > >Russ provided the following example that we might use: > > > TBSCertificate ::= SEQUENCE { > > > version [0] Version DEFAULT v1, > > > .... > > > > > > Version ::= INTEGER { v1(0), v2(1), v3(2) } > > > > > > > > > > > > > > > > > >"Implementations encountering unknown protocol identifiers MUST handle > > >this gracefully by providing indicators that an unknown protocol is among > > >the sequence of permissible protocols. If the unknown protocol > is the only > > >allowable protocol in the sequence, then the implementation cannot support > > >that field and the member cannot join the group. > > >It is a matter of local policy whether a join is permitted when > > >an unknown protocol exists among other allowable, known protocols." > > > > > > > > >The above will be added to provide > > >handling instructions when encountering unknown protocols. > > > > > > > > > > > >Under the main token structure it will say that additional protocols > > >SHOULD NOT be added unless the MSEC architecture changes. > > > > > > > > > > > >3) It's not clear that the GSAKMP document combined with this document > > >provides enough mandatory to implement features that any two > > >implementations of this specification will work together. The GSAKMP > > >document specifies mandatory to implement mechanisms for GSAKMP. > > >However the policy token allows for a wide variety of combinations of > > >protocols. For example, a policy token could specify one protocol for > > >registration, one protocol for rekey, and a completely different > > >protocol for de-registration. If only one of these is GSAKMP, what > > >happens? Where is it specified what combinations a GM, a GC/KS etc > > >must support in terms of policy token contents? > > > > > >I understand the issue, but the token's purpose is to tie the > > >abstract MSEC > > >architecture to a configurable system. The MSEC architecture > allows for any > > >of these protocols for registration, de-registration, etc. and does not > > >specify what the mandatory to implement protocols are. To say that the > > >appendix B and appendix C protocols are the > mandatory-to-implement protocols > > >would mean that the MSEC architecture now requires those > protocols. This is > > >one case where I believe a mandatory to implement scheme would be a > > >disservice to the community. > > > > > >Interoperability testing for the token, really becomes system > > >interoperability testing vs. protocol interoperability testing. > > > > > > > > > > > >4) IANA Comments: > > >The IANA Considerations section requests that 13 object identifiers > > >be assigned. > > >In which registry should these be assigned? IANA needs clarification. > > > > > > > > > > > >Statement to IANA section will essentially say that the spec is extended > > >through specification. Those specifying new objects will > register them with > > >IANA. Those that change the structure of the PT must change the version > > >indicator. > > > > > > > > > > > > > > >The resolution does not address the question on "which registry" > > >should be used. I think this requires a new registry, right? > > > > > > > > > _______________________________________________ > > msec mailing list > > msec@securemulticast.org > > http://six.pairlist.net/mailman/listinfo/msec > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Tue Jan 24 18:15:23 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F1XNi-00045A-4e for msec-archive@megatron.ietf.org; Tue, 24 Jan 2006 18:15:23 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14138 for ; Tue, 24 Jan 2006 18:13:50 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E616C2C515; Tue, 24 Jan 2006 18:15: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 A38312C388 for ; Tue, 24 Jan 2006 18:15:17 -0500 (EST) Received: (qmail 83509 invoked by uid 3269); 24 Jan 2006 23:15:17 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 83506 invoked from network); 24 Jan 2006 23:15:17 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Jan 2006 23:15:17 -0000 Received: from smtp-out2.oct.nac.net (smtp-out2.oct.nac.net [209.123.233.212]) by klesh.pair.com (Postfix) with SMTP id 6004868389 for ; Tue, 24 Jan 2006 18:15:17 -0500 (EST) Received: (qmail 31995 invoked from network); 24 Jan 2006 18:15:16 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 24 Jan 2006 18:15:16 -0500 Received: (qmail 37983 invoked from network); 24 Jan 2006 18:15:15 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 24 Jan 2006 18:15:15 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k0OKlRA21453; Tue, 24 Jan 2006 15:47:27 -0500 Date: Tue, 24 Jan 2006 15:47:27 -0500 (EST) From: George Gross To: Lakshminath Dondeti Subject: Re: [MSEC] Resolving the DISCUSS on draft-ietf-msec-policy-token-sec-05.txt (Summary) In-Reply-To: <6.2.5.6.2.20060124112212.038650f8@qualcomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: George Gross , msec@securemulticast.org X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Hi Lakshminath, Arguably, the issue of policy token version handling is somewhat related to the broader MSEC problem of "composite groups". This problem is not documented in the MSEC architecture RFC3740, but since that RFC's publication it has become prominient as part of the "how do we transition from MD5/SHA-1 to SHA-ng" issue. As an aside, I'll mention that I owe Brian some verbage on this topic as part of the MSEC IPsec extensions draft. He and I arrived at a compromise on this topic off list earlier this month, plz stay tuned for the new draft. In the context of handling policy token versions, a composite group is the logical cryptographic group formed by the union of two sub-groups: those endpoints that understand and implement core PT v1 and those endpoints that understand and implement core PT v2 (and presumably v1 too). From an operational point of view, it is impractical to flash cut a large-scale group of endpoints from v1 to v2. Since there are usually fewer of them, one could operationally manage that all GCKS would be upgraded to support both v1 and v2 core PT. Consequently, an endpoint joining a composite group must signal to the GCKS as part of its registration protocol exchange which sub-group it will participate in. For example, the GSAKMP section 7.1.2 defines this version processing. There is also an explaination how to combine v1 and v2 information (including a PT payload) in one GSAKMP message without confusing v1 endpoints. When admitting a v1 endpoint into the group, the GCKS would download a v1 policy token, and direct the endpoint to receive v1 sub-group data SA transmissions. So I do not share Sam's concerns about the version backward compatibility problem. In fact, I would suggest that the GSAKMP co-authors have considered this problem more carefully than some other IETF protocols, and we do have a proactive solution specified in our current drafts. With regard to using 1997 ASN.1 extensibility marker mechanisms, I admit I am not an ASN.1 language lawyer ;o) My experience is with an ASN.1 compiler that handles the 1990 ASN.1 dialect. Perhaps the "fix" here is to make the core PT draft's normative reference point at the ASN.1 1990 version rather than 1997? It is not clear to me what benefit ASN.1 1997 brings to the table, given the above version handling strategy does not depend on its extensibility markers. hope this clarifies... br, George On Tue, 24 Jan 2006, Lakshminath Dondeti wrote: > Hi all, > > A small correction in my email below. The responses to #1 and #2 are > to be read together as responses to issues #1 and #2. (I posted the > correction immediately to the response to Brian C, but not here) > > Hi George, > > Thanks for your notes. Here is the latest from Sam on this: > > > So, the response to issue 1 does not actually have anything to do with > issue 1 at all. However, I think the response to issue 2 also happens > to be a valid responsse to issue 1. > > The down side of how MSEC is handling versioning is that they cannot > extend their structures without breaking old implementations. In > order to extend the structure, they need to increase the version > number. If they increase the version number and add fields, an > implementation that does not know about these new fields must reject > the encoding per 1997 ASN.1. > > > An alternate strategy they could have adopted would be to add > extensibility markers. Under that strategy, they could add fields and > arms to sequences and choices. Receivers unfamiliar with a new field > or arm would simply ignore that field or arm. > > Another alternative would be to cite an old enough ASN.1 specification > before extensibility markers were introduced and claim that > implementations must accept unknown additions to sequencesand choices. > > > Any comments are welcome. > > regards, > Lakshminath > > At 01:56 PM 1/23/2006, George Gross wrote: > >Hi, > > > >I support the proposed set of resolutions listed below. Adding the PT > >version field incurrs a minor change in core PT implementation, but it > >makes sense, and it is not a hardship to add this. > > > >As for the core PT IANA registry, my first thought is that creating a > >distinct new IANA registry seems like the best way forward. I had not > >considered the "how to register at IANA" aspect of the PT design > >lifecycle. the current and our future MSEC OID definitions do need a home. > > > >I'm assuming that there isn't an IANA registry already in existence that > >could be placed into this role? the GSAKMP one is not the right place for > >this, since the core PT is key management protocol independent... > > > >hth, > > George > > > >On Mon, 23 Jan 2006, Lakshminath Dondeti wrote: > > > > > Hi all, > > > > > > There is an "Abstain" and a "DISCUSS" recorded as part of the IESG > > > evaluation of the Policy Token spec. Andrea, Uri, and Russ have > > > worked diligently to come up with the following resolution. Please > > > look at the following link for the history of the document evaluation: > > > > > > > > https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1841&filename=draft-ietf-msec-policy-token-sec > > > > > > If you have any thoughts or objections to the new text, please post > > > your comments ASAP to the list. > > > > > > thanks and regards, > > > Lakshminath > > > > > > > > > > > > >Please look for (overall consensus so far) and > > > >(issues that haven't been covered yet, there is only one, on the > > > >IANA comment) below. > > > > > > > >best regards, > > > >Lakshminath > > > > > > > > > > > > > > > >1) Misuse of ASN.1. The document cites the 1997 ASN.1, but has a > > > >number of choices and structures that seem like they are intended to > > > >be extended in the future. Without extensibility markers, a > > > >conforming implementation will reject a sequence or choice with > > > >elements not permitted by the abstract syntax. > > > > > > > > > > > >The EXPORTS statement is to be removed so that any structure def can be > > > >exported. > > > > > > > > > > > > > > > > > > > >2) There is no extensibility or versioning strategy described in the > > > >document. How do we add fields? What should recipients of a token do > > > >if they do not understand part of it? > > > > > > > > > > > >A Policy Token version indicator is to be added to the TokenID. > > > > > > > > > > > > > > > > > > > >Russ provided the following example that we might use: > > > > TBSCertificate ::= SEQUENCE { > > > > version [0] Version DEFAULT v1, > > > > .... > > > > > > > > Version ::= INTEGER { v1(0), v2(1), v3(2) } > > > > > > > > > > > > > > > > > > > > > > > >"Implementations encountering unknown protocol identifiers MUST handle > > > >this gracefully by providing indicators that an unknown protocol is among > > > >the sequence of permissible protocols. If the unknown protocol > > is the only > > > >allowable protocol in the sequence, then the implementation cannot support > > > >that field and the member cannot join the group. > > > >It is a matter of local policy whether a join is permitted when > > > >an unknown protocol exists among other allowable, known protocols." > > > > > > > > > > > >The above will be added to provide > > > >handling instructions when encountering unknown protocols. > > > > > > > > > > > > > > > >Under the main token structure it will say that additional protocols > > > >SHOULD NOT be added unless the MSEC architecture changes. > > > > > > > > > > > > > > > >3) It's not clear that the GSAKMP document combined with this document > > > >provides enough mandatory to implement features that any two > > > >implementations of this specification will work together. The GSAKMP > > > >document specifies mandatory to implement mechanisms for GSAKMP. > > > >However the policy token allows for a wide variety of combinations of > > > >protocols. For example, a policy token could specify one protocol for > > > >registration, one protocol for rekey, and a completely different > > > >protocol for de-registration. If only one of these is GSAKMP, what > > > >happens? Where is it specified what combinations a GM, a GC/KS etc > > > >must support in terms of policy token contents? > > > > > > > >I understand the issue, but the token's purpose is to tie the > > > >abstract MSEC > > > >architecture to a configurable system. The MSEC architecture > > allows for any > > > >of these protocols for registration, de-registration, etc. and does not > > > >specify what the mandatory to implement protocols are. To say that the > > > >appendix B and appendix C protocols are the > > mandatory-to-implement protocols > > > >would mean that the MSEC architecture now requires those > > protocols. This is > > > >one case where I believe a mandatory to implement scheme would be a > > > >disservice to the community. > > > > > > > >Interoperability testing for the token, really becomes system > > > >interoperability testing vs. protocol interoperability testing. > > > > > > > > > > > > > > > >4) IANA Comments: > > > >The IANA Considerations section requests that 13 object identifiers > > > >be assigned. > > > >In which registry should these be assigned? IANA needs clarification. > > > > > > > > > > > > > > > >Statement to IANA section will essentially say that the spec is extended > > > >through specification. Those specifying new objects will > > register them with > > > >IANA. Those that change the structure of the PT must change the version > > > >indicator. > > > > > > > > > > > > > > > > > > > >The resolution does not address the question on "which registry" > > > >should be used. I think this requires a new registry, right? > > > > > > > > > > > > > _______________________________________________ > > > msec mailing list > > > msec@securemulticast.org > > > http://six.pairlist.net/mailman/listinfo/msec > > > > _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Thu Jan 26 00:58:25 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F209J-000156-8j for msec-archive@megatron.ietf.org; Thu, 26 Jan 2006 00:58:25 -0500 Received: from six.pairlist.net (six.pairlist.net [209.68.2.254]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13300 for ; Thu, 26 Jan 2006 00:56:53 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B89F22BA5E; Thu, 26 Jan 2006 00:58:23 -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 4E8392BA50 for ; Thu, 26 Jan 2006 00:58:22 -0500 (EST) Received: (qmail 90348 invoked by uid 3269); 26 Jan 2006 05:58:22 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 90345 invoked from network); 26 Jan 2006 05:58:22 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 26 Jan 2006 05:58:22 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 000BC68377 for ; Thu, 26 Jan 2006 00:58:21 -0500 (EST) Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0Q5wIRr012335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2006 21:58:19 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-131.qualcomm.com [10.50.69.131]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id k0Q5wHFB010029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jan 2006 21:58:17 -0800 (PST) Message-Id: <6.2.5.6.2.20060125215447.03f47fe0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 25 Jan 2006 21:58:16 -0800 To: Brian Weis From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: msec@securemulticast.org Subject: [MSEC] Fwd: RFC 4359 on The Use of RSA/SHA-1 Signatures within Encapsulating Security Payload (ESP) and Authentication Header (AH) X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org Brian, Many thanks for your initiative and diligence in getting this RFC published! best regards, Lakshminath >To: ietf-announce@ietf.org >From: rfc-editor@rfc-editor.org >Date: Wed, 25 Jan 2006 17:52:10 -0800 >X-ISI-4-43-8-MailScanner: Found to be clean >X-MailScanner-From: rfc-ed@isi.edu >X-Spam-Score: -14.6 (--------------) >X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 >Cc: msec@securemulticast.org, rfc-editor@rfc-editor.org >Subject: RFC 4359 on The Use of RSA/SHA-1 Signatures within Encapsulating > Security Payload (ESP) and Authentication Header (AH) >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.5 >List-Id: ietf-announce.ietf.org >List-Unsubscribe: , > >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org >X-PMX-Version: 4.7.0.111621 >X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.1.0.0, >Antispam-Data: 2006.01.25.172604 >X-OriginalArrivalTime: 26 Jan 2006 02:00:48.0222 (UTC) >FILETIME=[5383E7E0:01C6221C] > > >A new Request for Comments is now available in online RFC libraries. > > > RFC 4359 > > Title: The Use of RSA/SHA-1 Signatures within > Encapsulating Security Payload (ESP) and > Authentication Header (AH) > Author(s): B. Weis > Status: Standards Track > Date: January 2006 > Mailbox: bew@cisco.com > Pages: 12 > Characters: 26989 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-msec-ipsec-signatures-06.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4359.txt > > >This memo describes the use of the RSA digital signature algorithm as >an authentication algorithm within the revised IP Encapsulating >Security Payload (ESP) as described in RFC 4303 and the revised IP >Authentication Header (AH) as described in RFC 4302. The use of a >digital signature algorithm, such as RSA, provides data origin >authentication in applications when a secret key method (e.g., HMAC) >does not provide this property. One example is the use of ESP and AH >to authenticate the sender of an IP multicast packet. > >This document is a product of the Multicast Security Working Group of >the IETF. > >This is now a Proposed Standard Protocol. > >This document specifies an Internet standards track protocol for >the Internet community, and requests discussion and suggestions >for improvements. Please refer to the current edition of the >"Internet Official Protocol Standards" (STD 1) for the >standardization state and status of this protocol. Distribution >of this memo is unlimited. > >This announcement is sent to the IETF list and the RFC-DIST list. >Requests to be added to or deleted from the IETF distribution list >should be sent to IETF-REQUEST@IETF.ORG. Requests to be >added to or deleted from the RFC-DIST distribution list should >be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. > >Details on obtaining RFCs via FTP or EMAIL may be obtained by sending >an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body >help: ways_to_get_rfcs. For example: > > To: rfc-info@RFC-EDITOR.ORG > Subject: getting rfcs > > help: ways_to_get_rfcs > >Requests for special distribution should be addressed to either the >author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless >specifically noted otherwise on the RFC itself, all RFCs are for >unlimited distribution. > >Submissions for Requests for Comments should be sent to >RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC >Authors, for further information. > > >Joyce K. Reynolds and Sandy Ginoza >USC/Information Sciences Institute > >... > >Below is the data which will enable a MIME compliant Mail Reader >implementation to automatically retrieve the ASCII version >of the RFCs. > >Content-Type: text/plain >Content-ID: <060125175048.RFC@RFC-EDITOR.ORG> > >RETRIEVE: rfc >DOC-ID: rfc4359 > > > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From somatic@homerunpower.com Thu Jan 26 14:23:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F2Cij-0003yY-Fo for msec-archive@megatron.ietf.org; Thu, 26 Jan 2006 14:23:49 -0500 Received: from c-67-171-33-134.hsd1.wa.comcast.net (c-67-171-33-134.hsd1.wa.comcast.net [67.171.33.134]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18025 for ; Thu, 26 Jan 2006 14:22:13 -0500 (EST) Received: from joanne by microsoft.com with local (Exim 4.41 (FreeBSD)) id 6-6-2 for chump; Thu, 26 Jan 2006 23:32:42 -0500 Message-ID: <77107@honeybee> From: Loren Carroll To: msec-archive@ietf.org Subject: Amazing, Matilda Date: Fri, 27 Jan 2006 00:49:55 -0500 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 38314.19747.5921.284780 X-MimeOLE: Produced By Microsoft MimeOLE 4857.05158.335828.4617574 Content-Type: multipart/mixed; boundary="------=5217596704" Content-Transfer-Encoding: quoted-printable --------=5217596704 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Even if you have no erection problems Cialis would help you to make better sex more often and to bring unimaginable plesure to her. Just disolve half a pill under your tongue and get ready for action in 15 minutes. The tests showed that the majority of men after taking this medication were able to have perfect erection during 36 hours!

Package Quantity Price in your local drugstore* Our price

Learn
More
Now
10 softtabs 20 doses $149.95 $119.95
20 softtabs 40 doses $299.95 $159.95
30 softtabs 60 doses $849.95 $169.95
60 softtabs 120 doses $1 999.95 $259.95
90 softtabs 180 doses $3 099.95 $299.95

When you are young and stressed up…
When you are aged and never give up…
Cialis gives you confidence in any chance, every time.


The highest form of ignorance is when you reject something you don't know anything about.Man is more interesting than men. God made him and not them in his image. Each one is more precious than all.
Most games are lost, not won. --------=5217596704 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Carlton-> http://cclfae.mycompa.info/?23194401 --------=5217596704--