From bonner@harringtonraceway.com Wed Feb 01 02:26:07 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4CNT-0001CS-GR for msec-archive@megatron.ietf.org; Wed, 01 Feb 2006 02:26:07 -0500 Received: from otxvorhf.biz ([221.234.86.49]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17274 for ; Wed, 1 Feb 2006 02:24:17 -0500 (EST) Received: (from slouch@microsoft.com) by microsoft.com (9.2.7/87.9.5/Submit) id crankcase; Wed, 01 Feb 2006 02:23:48 -0500 Date: Tue, 31 Jan 2006 22:56:44 -0500 Message-Id: <5.3@microsoft.com> From: Kerri.Jones.bonner@harringtonraceway.com To: msec-archive@ietf.org Subject: Amazing, Dudley X-Priority: 3 X-Mailer: strange terminable Mailer Content-Type: multipart/mixed; boundary="------=29873363148401" Content-Transfer-Encoding: quoted-printable --------=29873363148401 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.


You have to defeat a great players aura more than his game.It is the passion that is in a kiss that gives to it its sweetness it is the affection in a kiss that sanctifies it.
These people abstain, it is true: but the bitch Sensuality glares enviously out of all they do.The self is not something ready-made, but something in continuous formation through choice of action. --------=29873363148401 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Good morning sir, Amazing, Sterling-> http://rumlst.your4you.info/?83746330 --------=29873363148401-- From msec-bounces@securemulticast.org Fri Feb 03 00:02:12 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4t1U-0003cX-1p for msec-archive@megatron.ietf.org; Thu, 02 Feb 2006 23:58:16 -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 XAA21949 for ; Thu, 2 Feb 2006 23:56:29 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 405442C820; Thu, 2 Feb 2006 23:58:02 -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 489082C7C6 for ; Thu, 2 Feb 2006 23:58:01 -0500 (EST) Received: (qmail 86731 invoked by uid 3269); 3 Feb 2006 04:58:01 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 86728 invoked from network); 3 Feb 2006 04:58:01 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Feb 2006 04:58:01 -0000 Received: from igw2.watson.ibm.com (igw2.watson.ibm.com [129.34.20.6]) by klesh.pair.com (Postfix) with ESMTP id 17B756837D for ; Thu, 2 Feb 2006 23:58:01 -0500 (EST) Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [129.34.20.41]) by igw2.watson.ibm.com (8.12.11/8.13.1/8.13.1-2005-04-25 igw) with ESMTP id k134vdWp015862; Thu, 2 Feb 2006 23:57:39 -0500 Received: from sp1n293en1.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_2) with ESMTP id k134vYR579342; Thu, 2 Feb 2006 23:57:34 -0500 Received: from mgsmtp00.watson.ibm.com (mgsmtp00.watson.ibm.com [9.2.40.58]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7/01-14-2004_1) with ESMTP id k134vXX579340; Thu, 2 Feb 2006 23:57:33 -0500 Received: from sibylla.watson.ibm.com (sibylla.watson.ibm.com [9.2.16.101]) by mgsmtp00.watson.ibm.com (8.12.11/8.12.11/2005/09/01) with ESMTP id k135uaxe007604; Fri, 3 Feb 2006 00:56:36 -0500 Received: from localhost (canetti@localhost) by sibylla.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id k134vU236864; Thu, 2 Feb 2006 23:57:31 -0500 Date: Thu, 2 Feb 2006 23:57:30 -0500 (EST) From: canetti To: msec@securemulticast.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: canetti@csail.mit.edu, mmusic@ietf.org, jo@acm.org, csp@csperkins.org Subject: [MSEC] Last Call for draft-ietf-msec-mikey-rsa-r-02.txt X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: canetti@csail.mit.edu 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 Folks, This is an MSEC last call on draft-ietf-msec-mikey-rsa-r-02.txt. Version 02 was posted recently, and the document seems quite stable. Please take time to read and comment. MMUSIC folks: The main intended use of the proposed mode of MIKEY is within mmusic protocols. Thus, although officially this is only an MSEC LC, you may want to read and comment as well. The LC will end in two weeks, on Friday Feb 17. Thanks, Ran The latest version of the draft is available at: http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-rsa-r-02.txt _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Feb 03 03:10:50 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F4w1q-0004BP-Eb for msec-archive@megatron.ietf.org; Fri, 03 Feb 2006 03:10:50 -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 DAA03905 for ; Fri, 3 Feb 2006 03:09:12 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id BDA3C2CAE2; Fri, 3 Feb 2006 03:10:48 -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 A13E62C9E4 for ; Fri, 3 Feb 2006 03:10:47 -0500 (EST) Received: (qmail 64105 invoked by uid 3269); 3 Feb 2006 08:10:47 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 64102 invoked from network); 3 Feb 2006 08:10:47 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Feb 2006 08:10:47 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 75BDB6837D for ; Fri, 3 Feb 2006 03:10:47 -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 k138ARQw023305 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2006 00:10:28 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-114.qualcomm.com [10.50.69.114]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k138APrk000117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2006 00:10:26 -0800 (PST) Message-Id: <6.2.5.6.2.20060203000849.04010d58@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Feb 2006 00:10:26 -0800 To: "Karl Norrman (KI/EAB)" , , From: Lakshminath Dondeti Subject: Re: [MSEC] Synchronization of SRTP roll-over counter In-Reply-To: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea. ericsson.se> References: <3AD208E1F0D5EB47AC3C5617420BCB02032D3D99@esealmw104.eemea.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 Karl, I think it makes sense to use this technique for SRTP ROC synchronization, especially in wireless networks. What are the next steps for this draft in your view? regards, Lakshminath At 04:35 AM 12/5/2005, Karl Norrman (KI/EAB) wrote: >Hello! > >3GPP has a service for multicast and broadcast distribution of data >called MBMS (Multimedia Broadcast/Multicast Service) >[http://www.3gpp.org/ftp/Specs/archive/33_series/33.246/33246-640.zip]. > >This service uses SRTP for protection of media streams. >To achieve robust synchronization of late joiners to a session, >3GPP has agreed on a mechanism that transports the SRTP roll-over >counter (ROC) in SRTP packets using the integrity transform hooks. > >To avoid collisions with IANA registered values in the future, >we would like to describe the transform in an IETF RFC and register >the required values with IANA. The mechanism and the associated >IANA registrations are defined in draft-lehtovirta-srtp-rcc-00.txt >[http://www.ietf.org/internet-drafts/draft-lehtovirta-srtp-rcc-00.txt]. >Comments on the draft are very welcome. > >Since MBMS is close to finalization, we would like to send the draft >to IESG for approval before the end of 2005. > >Regards, >Karl >_______________________________________________ >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 Fri Feb 03 12:39:55 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F54uY-0003i4-Vj for msec-archive@megatron.ietf.org; Fri, 03 Feb 2006 12:39:55 -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 MAA23008 for ; Fri, 3 Feb 2006 12:38:10 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id E36892CA3A; Fri, 3 Feb 2006 12:39:47 -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 461C62C96D for ; Fri, 3 Feb 2006 12:39:46 -0500 (EST) Received: (qmail 66468 invoked by uid 3269); 3 Feb 2006 17:39:46 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 66465 invoked from network); 3 Feb 2006 17:39:46 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 3 Feb 2006 17:39:46 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id E560B68382 for ; Fri, 3 Feb 2006 12:39:45 -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 k13HdhQw030301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2006 09:39:44 -0800 Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.20]) by sabrina.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k13Hde7Z007139 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2006 09:39:42 -0800 (PST) Message-Id: <6.2.5.6.2.20060203093448.05604568@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Feb 2006 09:39:41 -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 session at IETF-65 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, I've requested 60 minutes for our session at IETF-65, with the following topics in mind: 1. MSEC IPsec extensions (Brian et. al) 2. MIKEY discussion (Dragan et. al) 3. GKDP discussion (Lakshminath et. al) about 15-20 minutes each. A brief update of the progress, issues for discussion (majority of the time should be used for this -- each of the discussions should cover the applicability/impact of SHA-1 transition as one of the items), and next steps is what we'd be looking for. If there are any other items for presentation that'll need 10+ minutes, let me know and I will amend the request accordingly. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Feb 03 19:44:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5BXn-0005La-9U for msec-archive@megatron.ietf.org; Fri, 03 Feb 2006 19:44:51 -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 TAA06709 for ; Fri, 3 Feb 2006 19:43:09 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4354A2C3EE; Fri, 3 Feb 2006 19:44:45 -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 8DB632C353 for ; Fri, 3 Feb 2006 19:44:43 -0500 (EST) Received: (qmail 1620 invoked by uid 3269); 4 Feb 2006 00:44:43 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1617 invoked from network); 4 Feb 2006 00:44:43 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Feb 2006 00:44:43 -0000 Received: from numenor.qualcomm.com (numenor.qualcomm.com [129.46.51.58]) by klesh.pair.com (Postfix) with ESMTP id 5C9D868377 for ; Fri, 3 Feb 2006 19:44:43 -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 k140ieQw010820 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2006 16:44:41 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-211.qualcomm.com [10.50.69.211]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k140icMS019830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2006 16:44:40 -0800 (PST) Message-Id: <6.2.5.6.2.20060203164300.040e69e8@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Feb 2006 16:44:38 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Subject: Re: [MSEC] MSEC session at IETF-65 In-Reply-To: <6.2.5.6.2.20060203093448.05604568@qualcomm.com> References: <6.2.5.6.2.20060203093448.05604568@qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti 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 Based on additional requests, I have revised the request and asked for 2-hr slot. Other topics for discussion include: 4. Minor revisions to GDOI and discussion on hash algorithm agility 5. MIKEY-RSA-R LC items, if any, and MIKEY-ECC update 6. TESLA updates Please send any additional requests to Ran and me. Thanks. regards, Lakshminath At 09:39 AM 2/3/2006, Lakshminath Dondeti wrote: >Hi all, > >I've requested 60 minutes for our session at IETF-65, with the >following topics in mind: > >1. MSEC IPsec extensions (Brian et. al) >2. MIKEY discussion (Dragan et. al) >3. GKDP discussion (Lakshminath et. al) > >about 15-20 minutes each. A brief update of the progress, issues >for discussion (majority of the time should be used for this -- each >of the discussions should cover the applicability/impact of SHA-1 >transition as one of the items), and next steps is what we'd be looking for. > >If there are any other items for presentation that'll need 10+ >minutes, let me know and I will amend the request accordingly. > >thanks and regards, >Lakshminath > >_______________________________________________ >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 Fri Feb 03 19:45:51 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5BYl-0005bC-2f for msec-archive@megatron.ietf.org; Fri, 03 Feb 2006 19:45:51 -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 TAA06856 for ; Fri, 3 Feb 2006 19:43:55 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 25C092C0D6; Fri, 3 Feb 2006 19:45:34 -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 EA47A2C0A0 for ; Fri, 3 Feb 2006 19:45:32 -0500 (EST) Received: (qmail 1798 invoked by uid 3269); 4 Feb 2006 00:45:32 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 1795 invoked from network); 4 Feb 2006 00:45:32 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Feb 2006 00:45:32 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id 8339C6837D for ; Fri, 3 Feb 2006 19:45:32 -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 k140jUEN024179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 3 Feb 2006 16:45:31 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-69-211.qualcomm.com [10.50.69.211]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k140jTx0003281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2006 16:45:30 -0800 (PST) Message-Id: <6.2.5.6.2.20060203164442.041dd188@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 03 Feb 2006 16:45:29 -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] Need editors for ESP-TESLA work 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 Folks, anyone interested in working on ESP-TESLA PS I-D, please contact Ran and me ASAP. thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sat Feb 04 06:10:17 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5LJ3-0001Dr-Jv for msec-archive@megatron.ietf.org; Sat, 04 Feb 2006 06:10:17 -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 GAA26988 for ; Sat, 4 Feb 2006 06:08:26 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 437B92BECE; Sat, 4 Feb 2006 06:10:00 -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 7D7832BE35 for ; Sat, 4 Feb 2006 06:09:58 -0500 (EST) Received: (qmail 16358 invoked by uid 3269); 4 Feb 2006 11:09:58 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 16355 invoked from network); 4 Feb 2006 11:09:58 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 4 Feb 2006 11:09:58 -0000 Received: from web8408.mail.in.yahoo.com (web8408.mail.in.yahoo.com [202.43.219.156]) by klesh.pair.com (Postfix) with SMTP id 5D03068382 for ; Sat, 4 Feb 2006 06:09:57 -0500 (EST) Received: (qmail 53478 invoked by uid 60001); 4 Feb 2006 11:09:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=5BOLlesydeTVs/4pbPDWgaIMfXWYUjCFgm20F/ungjqGwRRolrWlussSE7S9aeEG3xSR9JkITrnHhfubqyStrdz7m1GpElDyapZJtlqaVksgV2o4cFrniZM3Dxxlabj82Rpia7/O/P8vi9Q03P1bd5AMPFz8aGwxhRklxWGdpbI= ; Message-ID: <20060204110955.53476.qmail@web8408.mail.in.yahoo.com> Received: from [203.145.159.44] by web8408.mail.in.yahoo.com via HTTP; Sat, 04 Feb 2006 11:09:55 GMT Date: Sat, 4 Feb 2006 11:09:55 +0000 (GMT) From: rajeshwar makwana To: msec@securemulticast.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [MSEC] Oueries 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 Respected Sir, We are the students of final year Engineering (B.E.) from Pune Institute of Computer Technology (PICT) and working on project JXTA . We are zapped by some queries so need your help. They are as follows : 1. How to install JXTA Shell on Linux ? 2. How to configure it on Linux ? 3. What are the .jar files required for running JXTA applications on Linux ? 4. What are the execution commands for JXTA application on Linux ? 5. Are any inbuilt libraries of JXTA available on Linux ? Waiting for your positive reply. Thanking you Yours Sincerely Rajeshwar Makwana __________________________________________________________ Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Feb 05 13:29:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F5odR-0007gC-HD for msec-archive@megatron.ietf.org; Sun, 05 Feb 2006 13:29:21 -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 NAA01741 for ; Sun, 5 Feb 2006 13:27:17 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C600B2B991; Sun, 5 Feb 2006 13:28: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 A45382B928 for ; Sun, 5 Feb 2006 13:28:50 -0500 (EST) Received: (qmail 9392 invoked by uid 3269); 5 Feb 2006 18:28:50 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 9389 invoked from network); 5 Feb 2006 18:28:50 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 5 Feb 2006 18:28: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 78ADE68377 for ; Sun, 5 Feb 2006 13:28:50 -0500 (EST) Received: (qmail 53113 invoked from network); 5 Feb 2006 13:28:49 -0500 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out2.oct.nac.net with SMTP; 5 Feb 2006 13:28:49 -0500 Received: (qmail 41040 invoked from network); 5 Feb 2006 13:28:48 -0500 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.81) by mail1.oct.nac.net with SMTP; 5 Feb 2006 13:28:48 -0500 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id k15Fx3R24581; Sun, 5 Feb 2006 10:59:03 -0500 Date: Sun, 5 Feb 2006 10:59:03 -0500 (EST) From: George Gross To: rajeshwar makwana Subject: Re: [MSEC] Oueries In-Reply-To: <20060204110955.53476.qmail@web8408.mail.in.yahoo.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, your query is abit off topic for this list. JXTA is a peer-to-peer networking framework, not a secure multicast technology. I'd suggest you visit www.jxta.org and ask your question at a JXTA related e-mail list that could help you... hth, George On Sat, 4 Feb 2006, rajeshwar makwana wrote: > Respected Sir, > We are the students of final year > Engineering (B.E.) from Pune Institute of Computer > Technology (PICT) and working on project JXTA . > We are zapped by some queries so need your help. > They are as follows : > 1. How to install JXTA Shell on Linux ? > 2. How to configure it on Linux ? > 3. What are the .jar files required for running > JXTA applications on Linux ? > 4. What are the execution commands for JXTA > application on Linux ? > 5. Are any inbuilt libraries of JXTA available on > Linux ? > > Waiting for your positive reply. > Thanking you > > > > Yours Sincerely > Rajeshwar Makwana > > > > __________________________________________________________ > Yahoo! India Matrimony: Find your partner now. Go to http://yahoo.shaadi.com > _______________________________________________ > 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 Feb 14 09:33:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F91F1-0000WG-WC for msec-archive@megatron.ietf.org; Tue, 14 Feb 2006 09:33:21 -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 JAA00494 for ; Tue, 14 Feb 2006 09:31:32 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id B548B2B858; Tue, 14 Feb 2006 09:32: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 BBA672CA11 for ; Tue, 14 Feb 2006 09:30:56 -0500 (EST) Received: (qmail 52309 invoked by uid 3269); 14 Feb 2006 14:30:55 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 52304 invoked from network); 14 Feb 2006 14:30:55 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 14 Feb 2006 14:30:55 -0000 Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by klesh.pair.com (Postfix) with ESMTP id 83F8868388 for ; Tue, 14 Feb 2006 09:30:54 -0500 (EST) Received: from esealmw129.eemea.ericsson.se (unknown [153.88.254.120]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id D51954F0002; Tue, 14 Feb 2006 15:30:50 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 15:30:50 +0100 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Feb 2006 15:30:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C63173.3FD11085" Date: Tue, 14 Feb 2006 15:30:48 +0100 Message-ID: X-MS-Has-Attach: yes Thread-Topic: Submission of draft-lehtovirta-srtp-rcc-01.txt Thread-Index: AcW0qYr7c8BcuLafRzyrTBuXzRPoch8DFfbQAAAmn+AALxrvUA== From: "Vesa Lehtovirta (JO/LMF)" To: , X-OriginalArrivalTime: 14 Feb 2006 14:30:49.0840 (UTC) FILETIME=[406B1F00:01C63173] X-Brightmail-Tracker: AAAAAA== Cc: "Magnus Westerlund (KI/EAB)" Subject: [MSEC] FW: Submission of draft-lehtovirta-srtp-rcc-01.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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C63173.3FD11085 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, Forwarding on behalf of Karl. -----Original Message----- From: Karl Norrman (KI/EAB)=20 Sent: 13. helmikuuta 2006 18:04 To: internet-drafts@ietf.org Cc: Vesa Lehtovirta (JO/LMF); Mats N=E4slund (KI/EAB) Subject: Submission of draft-lehtovirta-srtp-rcc-01.txt Dear Editor, Please submit the new version of draft-lehtovirta-srtp-rcc-01.txt. Best Regards, Karl Norrman Ericsson ------_=_NextPart_001_01C63173.3FD11085 Content-Type: text/plain; name="draft-lehtovirta-srtp-rcc-01.txt" Content-Description: draft-lehtovirta-srtp-rcc-01.txt Content-Disposition: attachment; filename="draft-lehtovirta-srtp-rcc-01.txt" Content-Transfer-Encoding: base64 DQoNCiAgIEludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgIExlaHRvdmlydGEs IE5hc2x1bmQsIE5vcnJtYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChFcmljc3NvbikNCiAgIElOVEVSTkVULURSQUZUDQogICBF WFBJUkVTOiBBdWd1c3QgMjAwNiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBGZWJy dWFyeSAyMDA2DQoNCg0KDQoNCg0KICAgICAgICAgICAgIEludGVncml0eSBUcmFuc2Zvcm0gQ2Fy cnlpbmcgUm9sbC1vdmVyIENvdW50ZXINCiAgICAgICAgICAgICAgICAgICA8ZHJhZnQtbGVodG92 aXJ0YS1zcnRwLXJjYy0wMS50eHQ+DQoNCg0KDQpTdGF0dXMgb2YgdGhpcyBtZW1vDQoNCiAgIEJ5 IHN1Ym1pdHRpbmcgdGhpcyBJbnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0 aGF0IGFueQ0KICAgYXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGlj aCBoZSBvciBzaGUgaXMgYXdhcmUNCiAgIGhhdmUgYmVlbiBvciB3aWxsIGJlIGRpc2Nsb3NlZCwg YW5kIGFueSBvZiB3aGljaCBoZSBvciBzaGUgYmVjb21lcw0KICAgYXdhcmUgd2lsbCBiZSBkaXNj bG9zZWQsIGluIGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5Lg0KDQogICBJbnRl cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVl cmluZw0KICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdy b3Vwcy4gIE5vdGUgdGhhdA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuDQoNCiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4DQogICBt b250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVy IGRvY3VtZW50cw0KICAgYXQgYW55IHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJ bnRlcm5ldC1EcmFmdHMgYXMNCiAgIHJlZmVyZW5jZSBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0g b3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcyIuDQoNCiAgIFRoZSBsaXN0IG9mIGN1cnJl bnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0Lg0KDQogICBUaGUgbGlzdCBvZiBJbnRlcm5ldC1E cmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sLg0KDQogICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhw aXJlIGluIEF1Z3VzdCAyMDA2Lg0KDQoNCkFic3RyYWN0DQoNCiAgIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhbiBpbnRlZ3JpdHkgdHJhbnNmb3JtIGZvciBTUlRQIFtSRkMzNzExXSwNCiAgIHdoaWNo IGFsbG93cyB0aGUgcm9sbC1vdmVyIGNvdW50ZXIgKFJPQykgdG8gYmUgdHJhbnNtaXR0ZWQgaW4g U1JUUA0KICAgcGFja2V0cyBhcyBwYXJ0IG9mIHRoZSBhdXRoZW50aWNhdGlvbiB0YWcuICBUaGUg bmVlZCBmb3Igc2VuZGluZyB0aGUNCiAgIFJPQyBpbiBTUlRQIHBhY2tldHMgYXJpc2VzIGluIHNp dHVhdGlvbnMgd2hlcmUgdGhlIHJlY2VpdmVyIGpvaW5zIGFuDQogICBvbmdvaW5nIFNSVFAgc2Vz c2lvbiwgYW5kIG5lZWRzIHRvIHF1aWNrbHkgYW5kIHJvYnVzdGx5IGdldCBpbnRvDQogICBzeW5j aHJvbml6YXRpb24uIFRoZSBtZWNoYW5pc20gYWxzbyBlbmhhbmNlcyBTUlRQIG9wZXJhdGlvbiBp biBjYXNlcw0KICAgd2hlcmUgdGhlcmUgaXMgYSByaXNrIG9mIGxvb3Npbmcgc2VuZGVyLXJlY2Vp dmVyIHN5bmNocm9uaXphdGlvbi4NCg0KDQoNCg0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICAg ICAgICAgICBzcnRwLXJjYyAgICAgICAgICAgICAgICBGZWJydWFyeSwgMjAwNg0KDQoNCg0KICAg VEFCTEUgT0YgQ09OVEVOVFMNCg0KICAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjINCiAgICAyLiBUaGUgdHJhbnNmb3Jt Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4zDQogICAg My4gVHJhbnNmb3JtIHZlcnNpb25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uNA0KICAgIDQuIFBhcmFtZXRlciBuZWdvdGlhdGlvbi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUNCiAgICA1LiBTZWN1cml0eSBDb25zaWRlcmF0aW9u cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi42DQogICAgNi4gSUFOQSBD b25zaWRlcmF0aW9ucy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Nw0KICAgIDguIEF1dGhvcidzIEFkZHJlc3Nlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjcNCiAgICA5LiBSZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi44DQoNCg0KMS4gSW50cm9kdWN0aW9uDQoN CiAgIFdoZW4gYSB1c2VyIGpvaW5zIGFuIG9uZ29pbmcgU1JUUCBzZXNzaW9uLCBoZSBtdXN0IGJl IGdpdmVuLCB1c2luZw0KICAgb3V0IG9mIGJhbmQgc2lnbmFsbGluZywgdGhlIHZhbHVlIG9mIHRo ZSBST0MgdGhlIHNlbmRlciBpcyBjdXJyZW50bHkNCiAgIHVzaW5nLiAgRm9yIGluc3RhbmNlLCBp dCBjYW4gYmUgdHJhbnNmZXJyZWQgaW4gdGhlIFNlY3VyaXR5IFBheWxvYWQNCiAgIG9mIGEgTUlL RVkgW1JGQzM4MzBdIG1lc3NhZ2UuICBJbiBzb21lIGNhc2VzIHRoZSByZWNlaXZlciB3aWxsIG5v dA0KICAgYmUgYWJsZSB0byBzeW5jaHJvbml6ZSBoaXMgUk9DIHdpdGggdGhlIG9uZSB1c2VkIGJ5 IHRoZSBzZW5kZXIgZXZlbg0KICAgaWYgaXQgaXMgc2lnbmFsZWQgdG8gaGltIG91dCBvZiBiYW5k LiAgRXhhbXBsZXMgb2Ygd2hlcmUNCiAgIHN5bmNocm9uaXphdGlvbiBmYWlsdXJlIHdpbGwgYXBw ZWFyIGFyZToNCg0KICAgMS4gVGhlIHJlY2VpdmVyIHJlY2VpdmVzIHRoZSBST0MgaW4gYSBNSUtF WSBtZXNzYWdlIHRvZ2V0aGVyIHdpdGgNCiAgICAgIGEga2V5IHJlcXVpcmVkIGZvciBhIHBhcnRp Y3VsYXIgY29udGludW91cyBzZXJ2aWNlLiAgSGUgZG9lcywNCiAgICAgIGhvd2V2ZXIsIG5vdCBq b2luIHRoZSBzZXJ2aWNlIHVudGlsIGFmdGVyIGEgZmV3IGhvdXJzLCBhdCB3aGljaA0KICAgICAg cG9pbnQgdGhlIHNlbmRlcidzIHNlcXVlbmNlIG51bWJlciAoU0VRKSBoYXMgd3JhcHBlZCBhcm91 bmQsIGFuZA0KICAgICAgdGhlIHNlbmRlciBoZW5jZSBoYXMgbWVhbndoaWxlIGluY3JlYXNlZCB0 aGUgdmFsdWUgb2YgUk9DLiAgV2hlbg0KICAgICAgdGhlIHVzZXIgam9pbnMgdGhlIHNlcnZpY2Ug aGUgZ3JhYnMgdGhlIFNFUSBmcm9tIHRoZSBmaXJzdCBzZWVuDQogICAgICBTUlRQIHBhY2tldCBh bmQgcHJlcGVuZHMgdGhlIFJPQyB0byBidWlsZCB0aGUgaW5kZXguICBJZg0KICAgICAgaW50ZWdy aXR5IHByb3RlY3Rpb24gaXMgdXNlZCwgdGhlIHBhY2tldCB3aWxsIGJlIGRpc2NhcmRlZC4gIElm DQogICAgICB0aGVyZSBpcyBubyBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgdGhlIHBhY2tldCBtYXkg KGlmIGtleQ0KICAgICAgZGVyaXZhdGlvbiByYXRlIGlzIG5vbi16ZXJvKSBiZSBkZWNyeXB0ZWQg dXNpbmcgdGhlIHdyb25nIHNlc3Npb24NCiAgICAgIGtleS4gIEluIGVpdGhlciBjYXNlLCB0aGUg cmVjZWl2ZXIgd2lsbCBub3QgaGF2ZSBpdHMgUk9DDQogICAgICBzeW5jaHJvbml6ZWQgd2l0aCB0 aGUgc2VuZGVyLCBhbmQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIHJlY292ZXINCiAgICAgIHdpdGhv dXQgb3V0LW9mLWJhbmQgc2lnbmFsbGluZy4NCg0KICAgMi4gSWYgdGhlIHJlY2VpdmVyIGxlYXZl cyB0aGUgc2Vzc2lvbiAoZHVlIHRvIGJlaW5nIG91dCBvZiByYWRpbw0KICAgICAgY292ZXJhZ2Ug b3IgYmVjYXVzZSBvZiBhIHVzZXIgYWN0aW9uKSwgYW5kIGRvZXMgbm90IHN0YXJ0DQogICAgICBy ZWNlaXZpbmcgdHJhZmZpYyBmcm9tIHRoZSBzZXJ2aWNlIGFnYWluIHVudGlsIGFmdGVyIDJeezE1 fQ0KICAgICAgcGFja2V0cyBoYXMgYmVlbiBzZW50LCB0aGUgcmVjZWl2ZXIgd2lsbCBiZSBvdXQg b2YNCiAgICAgIHN5bmNocm9uaXphdGlvbiAoZm9yIHRoZSBzYW1lIHJlYXNvbnMgYXMgaW4gZXhh bXBsZSAxKS4NCg0KICAgMy4gVGhlIHJlY2VpdmVyIGpvaW5zIGEgc2VydmljZSB3aGVuIHRoZSBT RVEgaXMgY2xvc2UgYWZ0ZXINCiAgICAgIHdyYXBhcm91bmQsIHNheSBTRVEgPSAweDAwMDEuICBU aGUgc2VuZGVyIGdlbmVyYXRlcyBhIE1JS0VZDQogICAgICBtZXNzYWdlLCBhbmQgaW5jbHVkZXMg dGhlIGN1cnJlbnQgdmFsdWUgb2YgUk9DLCBzYXkgUk9DID0gMSwgaW4NCiAgICAgIHRoZSBzZWN1 cml0eSBwb2xpY3kgcGF5bG9hZC4gVGhlIE1JS0VZIG1lc3NhZ2UgcmVhY2hlcyB0aGUNCiAgICAg IHJlY2VpdmVyLCB3aG8gcmVhZHMgdGhlIFJPQyB2YWx1ZSBhbmQgaW5pdGlhbGl6ZXMgaXRzIGxv Y2FsIFJPQw0KDQoNCg0KTGVodG92aXJ0YSBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSAyXQ0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICAg ICAgICAgICBzcnRwLXJjYyAgICAgICAgICAgICAgICBGZWJydWFyeSwgMjAwNg0KDQoNCiAgICAg IHRvIDEuICBOb3csIGlmIGEgU1JUUCBwYWNrZXQgcHJpb3IgdG8gd3JhcGFyb3VuZCwgaS5lLiwg d2l0aCBhDQogICAgICBTRVEgbG93ZXIgdGhhbiAwLCBzYXkgU0VRID0gMHhmZmZmLCB3YXMgZGVs YXllZCBhbmQgcmVhY2hlcyB0aGUNCiAgICAgIHJlY2VpdmVyIGFzIHRoZSBmaXJzdCBTUlRQIHBh Y2tldCBoZSBzZWVzLCB0aGUgcmVjZWl2ZXIgd2lsbA0KICAgICAgaW5pdGlhbGl6ZSBpdHMgaGln aGVzdCByZWNlaXZlZCBzZXF1ZW5jZSBudW1iZXIsIHNfbCwgdG8gMHhmZmZmLg0KICAgICAgTmV4 dCB0aGUgcmVjZWl2ZXIgd2lsbCByZWNlaXZlIFNSVFAgcGFja2V0cyB3aXRoIHNlcXVlbmNlIG51 bWJlcnMNCiAgICAgIGxhcmdlciB0aGFuIHplcm8sIGFuZCB3aWxsIGRlZHVjZSB0aGF0IHRoZSBT RVEgaGFzIHdyYXBwZWQuDQogICAgICBIZW5jZSwgdGhlIHJlY2VpdmVyIHdpbGwgaW5jb3JyZWN0 bHkgdXBkYXRlIHRoZSBST0MgYW5kIHdpbGwgYmUNCiAgICAgIG91dCBvZiBzeW5jaC4NCg0KICAg NC4gU2ltaWxhcmx5IHRvICgzKSwgc2luY2UgdGhlIGluaXRpYWwgU0VRIGlzIHNlbGVjdGVkIGF0 IHJhbmRvbSBieQ0KICAgICAgdGhlIHNlbmRlciwgaXQgbWF5IGhhcHBlbiB0byBiZSBzZWxlY3Rl ZCBhcyBhIHZhbHVlIHZlcnkgY2xvc2UgdG8NCiAgICAgIDB4ZmZmZi4gIEluIHRoaXMgY2FzZSwg c2hvdWxkIHRoZSBmaXJzdCBmZXcgcGFja2V0cyBiZSBsb3N0LCB0aGUNCiAgICAgIHJlY2VpdmVy IG1heSBzaW1pbGFybHkgZW5kIHVwIG91dCBvZiBzeW5jaC4NCg0KICAgVGhlc2UgcHJvYmxlbXMg aGF2ZSBiZWVuIHJlY29nbml6ZWQgaW4gM0dQUDIgYW5kIDNHUFAsIHdoZXJlIFNSVFAgaXMNCiAg IHVzZWQgZm9yIHN0cmVhbWluZyBtZWRpYSBwcm90ZWN0aW9uIGluIHRoZWlyIHJlc3BlY3RpdmUN CiAgIG11bHRpY2FzdC9icm9hZGNhc3Qgc29sdXRpb25zIFtCQ01DU11bTUJNU10uICBQcm9ibGVt IDQgYWN0dWFsbHkNCiAgIGV4aXN0cyBpbmhlcmVudGx5IGR1ZSB0byB0aGUgd2F5IFNFUSBpbml0 aWFsaXphdGlvbiBpcyBkb25lIGluIFJUUC4NCg0KICAgVG8gYXZvaWQgcHJvYmxlbXMsIDNHUFAy IGhhdmUgY2hvc2VuIHRvIGNhcnJ5IHRoZSBST0MgaW4gdGhlIE1LSQ0KICAgZmllbGQgb2YgZWFj aCBTUlRQIHBhY2tldC4gIFRoaXMgaGFzIHRoZSBhZHZhbnRhZ2UgdGhhdCB0aGUgcmVjZWl2ZXIN CiAgIGltbWVkaWF0ZWx5IGtub3dzIHRoZSBlbnRpcmUgaW5kZXggZm9yIGEgcGFja2V0LiAgVW5m b3J0dW5hdGVseSwgdGhlDQogICBNS0kgaGFzIG5vIHNlbWFudGljcyBpbiBSRkMgMzcxMSAob3Ro ZXIgdGhhbiBzcGVjaWZ5aW5nIG1hc3RlciBrZXkpLA0KICAgYW5kIGEgcmVndWxhciBSRkMgMzcx MSBjb21wbGlhbnQgaW1wbGVtZW50YXRpb24gd291bGQgbm90IGJlIGFibGUgdG8NCiAgIG1ha2Ug dXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjYXJyaWVkIGluIHRoZSBNS0kuICBGdXJ0aGVybW9yZSwg dGhlDQogICBNS0kgZmllbGQgaXMgbm90IGludGVncml0eSBwcm90ZWN0ZWQsIGFuZCBoZW5jZSBj YXJlIG11c3QgYmUgdGFrZW4NCiAgIHRvIGF2b2lkIG9idmlvdXMgYXR0YWNrcyBhZ2FpbnN0IHRo ZSBzeW5jaHJvbml6YXRpb24uDQoNCiAgIDNHUFAgaGFzIGFncmVlZCBvbiBhIHNvbHV0aW9uIGNh cnJ5aW5nIHRoZSBST0MgaW4gc2VsZWN0ZWQgU1JUUA0KICAgcGFja2V0cy4gSW4gdGhpcyBzb2x1 dGlvbiB0aGUgUk9DIGlzIGNhcnJpZWQgaW4gdGhlIGF1dGhlbnRpY2F0aW9uDQogICB0YWcgb2Yg YSBzcGVjaWFsIGludGVncml0eSB0cmFuc2Zvcm0uDQoNCiAgIFRoZSBiZW5lZml0IG9mIHRoaXMg YXBwcm9hY2ggaXMgdGhhdCB0aGUgZnVuY3Rpb25hbGl0eSBvZiBmYXN0IGFuZA0KICAgcm9idXN0 IHN5bmNocm9uaXphdGlvbiBjYW4gYmUgc3RhbmRhcmRpemVkIGFzIGEgc2VwYXJhdGUgaW50ZWdy aXR5DQogICB0cmFuc2Zvcm0gaW4gSUVURiwgdXNpbmcgdGhlIGhvb2tzIGV4aXN0aW5nIGluIFNS VFAuICBUaGlzIHdheSwNCiAgIHRoZXJlIHdpbGwgbm90IGJlIGludGVyb3BlcmFiaWxpdHkgcHJv YmxlbXMsIGFuZCBvdGhlciBzb2x1dGlvbnMNCiAgIHRoYW4gdGhlIDNHUFAgbXVsdGljYXN0L2Jy b2FkY2FzdCBtdWx0aW1lZGlhIHNlcnZpY2UgY2FuIG1ha2UgdXNlIG9mDQogICB0aGUgZnVuY3Rp b25hbGl0eSBhcyBkZXNpcmVkLiAgRnVydGhlcm1vcmUsIHdoZW4gdGhlIFJPQyBpcw0KICAgdHJh bnNtaXR0ZWQgdG8gdGhlIHJlY2VpdmVyIGl0IG5lZWRzIHRvIGJlIGludGVncml0eSBwcm90ZWN0 ZWQsIHRvDQogICBhdm9pZCBEb1MgYXR0YWNrcyBvciB0cmFuc21pc3Npb24gZXJyb3JzIGJyaW5n aW5nIHRoZSByZWNlaXZlciBvdXQNCiAgIG9mIHN5bmNoLiAgSGVuY2UsIGl0IG1ha2VzIHNlbnNl IHRvIGNhcnJ5IHRoZSBST0MgaW5zaWRlIHRoZQ0KICAgYXV0aGVudGljYXRpb24gdGFnIG9mIGFu IGludGVncml0eSB0cmFuc2Zvcm0uDQoNCjIuIFRoZSB0cmFuc2Zvcm0NCg0KICAgVGhlIHRyYW5z Zm9ybSwgaGVyZWFmdGVyIGNhbGxlZCBSb2xsLW92ZXIgQ291bnRlciBDYXJyeWluZyBUcmFuc2Zv cm0NCiAgIChvciBSQ0MgZm9yIHNob3J0KSwgd29ya3MgYXMgZm9sbG93cy4NCg0KDQoNCg0KTGVo dG92aXJ0YSBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBbUGFnZSAzXQ0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAgICAgICBzcnRwLXJjYyAg ICAgICAgICAgICAgICBGZWJydWFyeSwgMjAwNg0KDQoNCiAgIFRoZSBzZW5kZXIgcHJvY2Vzc2Vz IHRoZSBSVFAgcGFja2V0IGFjY29yZGluZyB0byBSRkMgMzcxMS4gIFdoZW4NCiAgIGFwcGx5aW5n IHRoZSBtZXNzYWdlIGludGVncml0eSB0cmFuc2Zvcm0sIHRoZSBzZW5kZXIgY2hlY2tzIGlmIHRo ZQ0KICAgU0VRIGlzIGVxdWFsIHRvIDAgbW9kdWxvIHNvbWUgbm9uLXplcm8gaW50ZWdlciBjb25z dGFudCBSLiAgSWYgdGhhdA0KICAgaXMgdGhlIGNhc2UsIHRoZSBzZW5kZXIgY29tcHV0ZXMgdGhl IGRlZmF1bHQgaW50ZWdyaXR5IHRyYW5zZm9ybQ0KICAgb3ZlciB0aGUgYXV0aGVudGljYXRlZCBw b3J0aW9uIG9mIHRoZSBwYWNrZXQoaS5lLiBwYWNrZXQgfHwgUk9DDQogICBzZW5kZXIpLCBvYnRh aW5pbmcgdGhlIHZhbHVlIE1BQy4gIE5leHQgdGhlIHNlbmRlciBjb25zdHJ1Y3RzIHRoZQ0KICAg dGFnIGFzIFRBRyA9IFJPQ19zZW5kZXIgfHwgTUFDLCB3aGVyZSBST0Nfc2VuZGVyIGlzIHRoZSB2 YWx1ZSBvZiBoaXMNCiAgIGxvY2FsIFJPQywgYW5kIGFwcGVuZHMgdGhlIHRhZyB0byB0aGUgcGFj a2V0Lg0KDQogICBJZiB0aGUgU0VRIGlzIG5vdCBlcXVhbCB0byAwIG1vZCBSLCB0aGUgc2VuZGVy IGp1c3QgcHJvY2VlZHMgdG8NCiAgIHByb2Nlc3MgdGhlIHBhY2tldCBhY2NvcmRpbmcgdG8gUkZD IDM3MTEgd2l0aG91dCBwZXJmb3JtaW5nIHRoZQ0KICAgYWN0aW9ucyBpbiB0aGUgcHJldmlvdXMg cGFyYWdyYXBoLg0KDQogICBUaGUgdmFsdWUgUiBpcyB0aGUgcmF0ZSBhdCB3aGljaCB0aGUgUk9D IGlzIGluY2x1ZGVkIGluIHRoZSBTUlRQDQogICBwYWNrZXRzLiAgU2luY2UgdGhlIFJPQyBjb25z dW1lcyBmb3VyIG9jdGV0cywgdGhpcyBnaXZlcyB0aGUNCiAgIHBvc3NpYmlsaXR5IHRvIHVzZSBp dCBzcGFyc2VseS4NCg0KICAgV2hlbiB0aGUgcmVjZWl2ZXIgcmVjZWl2ZXMgYW4gU1JUUCBwYWNr ZXQsIGl0IHByb2Nlc3NlcyB0aGUgcGFja2V0DQogICBhY2NvcmRpbmcgdG8gUkZDIDM3MTEuIElu IHRoZSBzdGVwIHdoZXJlIGludGVncml0eSBwcm90ZWN0aW9uIGlzIHRvDQogICBiZSB2ZXJpZmll ZCwgaWYgdGhlIFNFUSBpcyBlcXVhbCB0byAwIG1vZHVsbyBSLCB0aGUgcmVjZWl2ZXINCiAgIHZl cmlmaWVzIHRoZSBNQUMgdXNpbmcgdGhlIGRlZmF1bHQgaW50ZWdyaXR5IHRyYW5zZm9ybSwgYnV0 IGRvZXMgbm90DQogICBpbmNsdWRlIHRoZSBmb3VyIG9jdGV0cyBhdCB0aGUgZW5kIG9mIHRoZSBw YWNrZXQgY29udGFpbmluZyB0aGUNCiAgIHNlbmRlcidzIFJPQyB2YWx1ZS4gIEFjY29yZGluZyB0 byBSRkMgMzcxMSwgdGhlIHJlY2VpdmVyIHNoYWxsDQogICBpbmNsdWRlIGhpcyBvd24gUk9DIHZh bHVlIGluIHRoZSBNQUMgY2FsY3VsYXRpb24uICBJbiBSQ0MsIGhvd2V2ZXIsDQogICB0aGUgcmVj ZWl2ZXIgcmVwbGFjZXMgaGlzIGxvY2FsIFJPQyB2YWx1ZSBieSB0aGUgdmFsdWUgZm91bmQgaW4g dGhlDQogICBwYWNrZXQgaW4gdGhlIE1BQyBjYWxjdWxhdGlvbi4gIE5vdGUgdGhhdCB0aGUgc2Vz c2lvbiBrZXkgdXNlZCBpbg0KICAgdGhlIE1BQyBjYWxjdWxhdGlvbiBpcyBkZXBlbmRlbnQgb24g dGhlIFJPQywgYW5kIGR1cmluZyB0aGUNCiAgIGRlcml2YXRpb24gb2YgdGhlIHNlc3Npb24gaW50 ZWdyaXR5IGtleSwgdGhlIFJPQyBmb3VuZCBpbiB0aGUgcGFja2V0DQogICB1bmRlciBjb25zaWRl cmF0aW9uIE1VU1QgYmUgdXNlZC4gIElmIHRoZSB2ZXJpZmljYXRpb24gaXMNCiAgIHN1Y2Nlc3Nm dWwsIHRoZSByZWNlaXZlciBzZXRzIGhpcyBsb2NhbCBST0MgZXF1YWwgdG8gdGhlIFJPQyBjYXJy aWVkDQogICBpbiB0aGUgcGFja2V0LiAgSWYgdGhlIE1BQyBkb2VzIG5vdCB2ZXJpZnksIHRoZSBw YWNrZXRzIE1VU1QgYmUNCiAgIGRyb3BwZWQuICBUaGUgcmF0aW9uYWxlIGZvciB1c2luZyB0aGUg Uk9DIGZyb20gdGhlIHBhY2tldCBpbiB0aGUgTUFDDQogICBjYWxjdWxhdGlvbiBpcyB0aGF0IGlm IHRoZSByZWNlaXZlciBoYXMgYW4gaW5jb3JyZWN0IFJPQyB2YWx1ZSwgTUFDDQogICB2ZXJpZmlj YXRpb24gd2lsbCBmYWlsLCBhbmQgdGhlIHJlY2VpdmVyIHdpbGwgbm90IGNvcnJlY3QgaGlzIFJP Qw0KICAgYmVjYXVzZSBvZiB0aGlzLg0KDQogICBJZiB0aGUgU0VRIGlzIG5vdCBlcXVhbCB0byAw IG1vZCBSLCB0aGUgcmVjZWl2ZXIganVzdCBwcm9jZWVkcyB0bw0KICAgcHJvY2VzcyB0aGUgcGFj a2V0IGFjY29yZGluZyB0byBSRkMgMzcxMSB3aXRob3V0IHBlcmZvcm1pbmcgdGhlDQogICBhY3Rp b25zIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguDQoNCiAgIFNpbmNlIFNSVENQIGFscmVhZHkg Y2FycmllcyB0aGUgZW50aXJlIGluZGV4IGluYmFuZCwgdGhlcmUgaXMgbm8NCiAgIHJlYXNvbiB0 byBhcHBseSB0aGlzIHRyYW5zZm9ybSB0byBTUlRDUC4gIEhlbmNlLCB0aGUgdHJhbnNmb3JtIFNI QUxMDQogICBvbmx5IGJlIGFwcGxpZWQgdG8gU1JUUCwgYW5kIFNIQUxMIE5PVCBiZSB1c2VkIHdp dGggU1JUQ1AuDQoNCjMuIFRyYW5zZm9ybSB2ZXJzaW9ucw0KDQogICBUaGUgYWJvdmUgZ2l2ZW4g dHJhbnNmb3JtIG9ubHkgcHJvdmlkZXMgaW50ZWdyaXR5IHByb3RlY3Rpb24gZm9yIHRoZQ0KICAg cGFja2V0cyB0aGF0IGNhcnJ5IHRoZSBST0MgKHRoaXMgd2lsbCBiZSByZWZlcnJlZCB0byB2ZXJz aW9uIDEpLiAgSW4NCg0KDQoNCkxlaHRvdmlydGEgZXQgYWwuICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgW1BhZ2UgNF0NCgwNCklOVEVSTkVULURSQUZUICAgICAg ICAgICAgICAgICAgc3J0cC1yY2MgICAgICAgICAgICAgICAgRmVicnVhcnksIDIwMDYNCg0KDQog ICB0aGUgY2FzZXMgd2hlcmUgdGhlcmUgaXMgYSBuZWVkIHRvIGludGVncml0eSBwcm90ZWN0IGFs bCB0aGUNCiAgIHBhY2tldHMsIHRoZSBwYWNrZXRzIHRoYXQgZG8gbm90IGhhdmUgU0VRIGVxdWFs IHRvIDAgbW9kIFIsIE1VU1QgYmUNCiAgIHByb3RlY3RlZCB1c2luZyB0aGUgZGVmYXVsdCBpbnRl Z3JpdHkgdHJhbnNmb3JtICh0aGlzIHdpbGwgYmUNCiAgIHJlZmVycmVkIHRvIGFzIHZlcnNpb24g MikuDQoNCiAgIFRodXMsIG5vdGUgdGhlIGZvbGxvd2luZyBkaWZmZXJlbmNlLiBVc2luZyB2ZXJz aW9uIDIgd2lsbCBpbnRlZ3JpdHkNCiAgIHByb3RlY3QgYWxsIFJUUCBwYWNrZXRzLCBidXQgb25s eSBhZGQgUk9DIHRvIHRob3NlIGhhdmluZyBTRVENCiAgIGRpdmlzaWJsZSBieSBSLiAgVXNpbmcg dmVyc2lvbiAxIGFuZCBzZXR0aW5nIFIgZXF1YWwgdG8gb25lLCB3aWxsDQogICBhbHNvIGludGVn cml0eSBwcm90ZWN0IGFsbCBwYWNrZXRzLCBidXQgd2lsbCBpbiBhZGRpdGlvbiBhZGQgUk9DIHRv DQogICBlYWNoIHBhY2tldC4NCg0KDQo0LiBQYXJhbWV0ZXIgbmVnb3RpYXRpb24NCg0KICAgUkND IHJlcXVpcmVzIHRoYXQgYSBmZXcgcGFyYW1ldGVycyBhcmUgc2lnbmFsZWQgb3V0IG9mIGJhbmQu ICBUaGUNCiAgIHBhcmFtZXRlcnMgdGhhdCBtdXN0IGJlIGluIHBsYWNlIGJlZm9yZSB0aGUgdHJh bnNmb3JtIGNhbiBiZSB1c2VkDQogICBhcmUgaW50ZWdyaXR5IHRyYW5zZm9ybSB2ZXJzaW9uIGFu ZCB0aGUgcmF0ZSwgUiwgYXQgd2hpY2ggdGhlIFJPQw0KICAgd2lsbCBiZSB0cmFuc21pdHRlZC4g IFRoaXMgY2FuIGJlIGRvbmUgdXNpbmcsIGUuZy4sIE1JS0VZIFtSRkMzODMwXS4NCg0KICAgVG8g cGVyZm9ybSB0aGUgcGFyYW1ldGVyIG5lZ290aWF0aW9uIHVzaW5nIE1JS0VZLCB0aGVyZSBpcyBh IG5lZWQgdG8NCiAgIHJlZ2lzdGVyIHR3byBpbnRlZ3JpdHkgdHJhbnNmb3JtcywgUkNDdjEgYW5k IFJDQ3YyIGluIFRhYmxlIDYuMTAuMS5jDQogICBvZiBbUkZDMzgzMF0uDQoNCg0KDQogICAgICAg ICAgICAgICAgICAgICAgIFRhYmxlIDEuIEludGVncml0eSB0cmFuc2Zvcm1zDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgIFNSVFAgYXV0aCBhbGcgfCBWYWx1ZQ0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0rLS0tLS0tDQogICAgICAgICAgICAgICAgICAgICAg ICAgICBSQ0N2MSAgICAgICAgIHwgICAgIDINCiAgICAgICAgICAgICAgICAgICAgICAgICAgIFJD Q3YyICAgICAgICAgfCAgICAgMw0KDQoNCiAgIEZ1cnRoZXJtb3JlLCB0aGUgcGFyYW1ldGVyIFIs IG11c3QgYmUgcmVnaXN0ZXJlZCBpbiBUYWJsZSA2LjEwLjEuYQ0KICAgb2YgW1JGQzM4MzBdLg0K DQoNCiAgICAgICAgICAgICAgICAgICBUYWJsZSAyLiBJbnRlZ3JpdHkgdHJhbnNmb3JtIHBhcmFt ZXRlcg0KDQogICAgICAgICAgICAgVHlwZSB8IE1lYW5pbmcgICAgICAgICAgICAgICAgICAgICB8 IFBvc3NpYmxlIHZhbHVlcw0KICAgICAgICAgICAgIC0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0NCiAgICAgICAgICAgICAgMTMgIHwgUk9DIHRyYW5z bWlzc2lvbiByYXRlICAgICAgIHwgIDE2LWJpdCBpbnRlZ2VyDQoNCiAgIFRoZSBST0MgdHJhbnNt aXNzaW9uIHJhdGUsIFIsIGlzIGdpdmVuIHdpdGggdGhlIGxlZnRtb3N0IGJpdCBiZWluZw0KICAg dGhlIG1vc3Qgc2lnbmlmaWNhbnQuICBSIE1VU1QgYmUgYSBub24temVybyB1bnNpZ25lZCBpbnRl Z2VyLiAgSWYNCiAgIHRoZSBST0MgdHJhbnNtaXNzaW9uIHJhdGUgaXMgbm90IGluY2x1ZGVkIGlu IHRoZSBuZWdvdGlhdGlvbiwgdGhlDQogICBkZWZhdWx0IHZhbHVlIG9mIDEgU0hBTEwgYmUgdXNl ZC4NCg0KDQoNCg0KTGVodG92aXJ0YSBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBbUGFnZSA1XQ0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICAgICAg ICAgICBzcnRwLXJjYyAgICAgICAgICAgICAgICBGZWJydWFyeSwgMjAwNg0KDQoNCiAgIFRvIGJl IGFibGUgdG8gdXNlIGRpZmZlcmVudCBpbnRlZ3JpdHkgdHJhbnNmb3JtcyBmb3IgU1JUUCBhbmQg U1JUQ1AsDQogICB3aGljaCBpcyBuZWVkZWQgaW4gY29ubmVjdGlvbiB0byB0aGUgdXNlIG9mIFJD QywgdGhlIGZvbGxvd2luZw0KICAgYWRkaXRpb25hbCBwYXJhbWV0ZXJzIG11c3QgYmUgcmVnaXN0 ZXJlZCBpbiBUYWJsZSA2LjEwLjEuYSBvZg0KICAgW1JGQzM4MzBdOg0KDQogICAgICAgICAgICAg ICAgICAgICAgIFRhYmxlIDMuIEludGVncml0eSBwYXJhbWV0ZXJzDQoNCiAgICAgICAgICAgVHlw ZSB8IE1lYW5pbmcgICAgICAgICAgICAgICAgICAgICB8IFBvc3NpYmxlIHZhbHVlcw0KICAgICAg ICAgICAtLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0t DQogICAgICAgICAgICAxNCAgfCBTUlRQIEF1dGguIGFsZ29yaXRobSAgICAgICAgfCBzZWUgYmVs b3cNCiAgICAgICAgICAgIDE1ICB8IFNSVENQIEF1dGguIGFsZ29yaXRobSAgICAgICB8IHNlZSBi ZWxvdw0KICAgICAgICAgICAgMTYgIHwgU1JUUCBTZXNzaW9uIEF1dGguIGtleSBsZW4gIHwgc2Vl IGJlbG93DQogICAgICAgICAgICAxNyAgfCBTUlRDUCBTZXNzaW9uIEF1dGguIGtleSBsZW4gfCBz ZWUgYmVsb3cNCiAgICAgICAgICAgIDE4ICB8IFNSVFAgQXV0aGVudGljYXRpb24gdGFnIGxlbiB8 IHNlZSBiZWxvdw0KICAgICAgICAgICAgMTkgIHwgU1JUQ1AgQXV0aGVudGljYXRpb24gdGFnIGxl bnwgc2VlIGJlbG93DQoNCiAgIFRoZSBwb3NzaWJsZSB2YWx1ZXMgZm9yIGF1dGhlbnRpY2F0aW9u IGFsZ29yaXRobXMgKHR5cGUgMTQgYW5kIDE1KQ0KICAgYXJlIHRoZSBzYW1lIGFzIGZvciB0aGUg IkF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobSIgcGFyYW1ldGVyICh0eXBlDQogICAyKSBpbiBUYWJs ZSA2LjEwLjEuYSBvZiBSRkMzODMwIHdpdGggdGhlIGFkZGl0aW9uIG9mIHRoZSB2YWx1ZXMNCiAg IGZvdW5kIGluIFRhYmxlIDEgYWJvdmUuDQoNCiAgIFRoZSBwb3NzaWJsZSB2YWx1ZXMgZm9yIHNl c3Npb24gYXV0aGVudGljYXRpb24ga2V5IGxlbmd0aHMgKHR5cGUgMTYNCiAgIGFuZCAxNykgYXJl IHRoZSBzYW1lIGFzIGZvciB0aGUgIlNlc3Npb24gQXV0aC4ga2V5IGxlbmd0aCIgcGFyYW1ldGVy DQogICAodHlwZSAzKSBpbiBUYWJsZSA2LjEwLjEuYSBvZiBSRkMzODMwLg0KDQogICBUaGUgcG9z c2libGUgdmFsdWVzIGZvciBhdXRoZW50aWNhdGlvbiB0YWcgbGVuZ3RocyAodHlwZSAxOCBhbmQg MTkpDQogICBhcmUgdGhlIHNhbWUgYXMgZm9yIHRoZSAiQXV0aGVudGljYXRpb24gdGFnIGxlbmd0 aCIgcGFyYW1ldGVyICh0eXBlDQogICAxMSkgaW4gVGFibGUgNi4xMC4xLmEgb2YgUkZDMzgzMC4N Cg0KICAgVG8gYXZvaWQgYW1iaWd1aXRpZXMgd2hlbiBpbnRyb2R1Y2luZyB0aGVzZSBuZXcgcGFy YW1ldGVycyB0aGF0IGhhdmUNCiAgIG92ZXJsYXBwaW5nIGZ1bmN0aW9uYWxpdHkgdG8gZXhpc3Rp bmcgcGFyYW1ldGVycyBpbiBUYWJsZSA2LjEwLjEuYQ0KICAgb2YgUkZDMzgzMCwgdGhlIGZvbGxv d2luZyBhcHByb2FjaCBNVVNUIGJlIHRha2VuOiBJZiBhbnkgb2YgdGhlDQogICBwYXJhbWV0ZXIg dHlwZXMgMTQtMTkgKHNwZWNpZnlpbmcgYmVoYXZpb3Igc3BlY2lmaWMgdG8gU1JUUCBvcg0KICAg U1JUQ1ApIGFuZCBhIGNvcnJlc3BvbmRpbmcgZ2VuZXJhbCBwYXJhbWV0ZXIgKHR5cGUgMiwgMywg b3IgMTEpIGFyZQ0KICAgYm90aCBwcmVzZW50IGluIHRoZSBwb2xpY3ksIHRoZSBtb3JlIHNwZWNp ZmljIHBhcmFtZXRlciBTSEFMTCBoYXZlDQogICBwcmVjZWRlbmNlLiBGb3IgZXhhbXBsZSwgaWYg dGhlICJBdXRoZW50aWNhdGlvbiBhbGdvcml0aG0iIHBhcmFtZXRlcg0KICAgKHR5cGUgMikgaXMg c2V0IHRvIEhNQUMtU0hBLTEgYW5kIHRoZSAiU1JUUCBBdXRoLiBBbGdvcml0aG0iICh0eXBlDQog ICAxNCkgaXMgc2V0IHRvIFJDQ1YxLCBTUlRQIHdpbGwgdXNlIHRoZSBSQ0NWMSBhbGdvcml0aG0s IGJ1dCBzaW5jZQ0KICAgdGhlcmUgaXMgbm8gc3BlY2lmaWMgYWxnb3JpdGhtIGNob3NlbiBmb3Ig U1JUQ1AsIHRoZSBtb3JlIGdlbmVyYWxseQ0KICAgc3BlY2lmaWVkIG9uZSAoSE1BQy1TSEEtMSkg aXMgdXNlZCBmb3IgU1JUQ1AuDQoNCg0KNS4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICAg QW4gYW5hbG9nb3VzIG1ldGhvZCBhbHJlYWR5IGV4aXN0cyBpbiBTUlRDUCAodGhlIFNSVENQIGlu ZGV4IGlzDQogICBjYXJyaWVkIGluIGVhY2ggcGFja2V0IHVuZGVyIGludGVncml0eSBwcm90ZWN0 aW9uKSBhbmQgdG8gdGhlIGJlc3QNCiAgIG9mIG91ciBrbm93bGVkZ2UsIHRoZSBvbmx5IHNlY3Vy aXR5IGNvbnNpZGVyYXRpb24gaW50cm9kdWNlZCBoZXJlIGlzDQogICB0aGF0IHRoZSBlbnRpcmUg U1JUUCBpbmRleCAoUk9DIHx8IFNFUSkgd2lsbCBiZWNvbWUgcHVibGljIHNpbmNlIGl0DQoNCg0K DQpMZWh0b3ZpcnRhIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFtQYWdlIDZdDQoMDQpJTlRFUk5FVC1EUkFGVCAgICAgICAgICAgICAgICAgIHNydHAt cmNjICAgICAgICAgICAgICAgIEZlYnJ1YXJ5LCAyMDA2DQoNCg0KICAgaXMgdHJhbnNmZXJyZWQg d2l0aG91dCBlbmNyeXB0aW9uLiAoSW4gbm9ybWFsIFNSVFAgb3BlcmF0aW9uLCBvbmx5DQogICB0 aGUgU0VRLXBhcnQgb2YgdGhlIGluZGV4IGlzIGRpc2Nsb3NlZCkuIEhvd2V2ZXIsIFJGQyAzNzEx IGRvZXMgbm90DQogICBpZGVudGlmeSBhIG5lZWQgZm9yIGVuY3J5cHRpbmcgdGhlIFNSVFAgaW5k ZXguDQoNCiAgIEl0IGlzIGltcG9ydGFudCB0byByZWFsaXplIHRoYXQgb25seSBldmVyeSBSOnRo IHBhY2tldCBpcyBpbnRlZ3JpdHkNCiAgIHByb3RlY3RlZCBpbiB2ZXJzaW9uIDEsIHNvIHVubGVz cyBSID0gMSwgdGhlIG1lY2hhbmlzbSBzaG91bGQgYmUNCiAgIHNlZW4gZm9yIHdoYXQgaXQgaXM6 IGEgd2F5IHRvIGltcHJvdmUgc2VuZGVyLXJlY2VpdmVyDQogICBzeW5jaHJvbml6YXRpb24sIGFu ZCBub3QgYSByZXBsYWNlbWVudCBmb3IgaW50ZWdyaXR5IHByb3RlY3Rpb24uDQoNCjYuIElBTkEg Q29uc2lkZXJhdGlvbnMNCg0KICAgUGxlYXNlIGFkZCB0aGUgZm9sbG93aW5nIHRvIHRoZSBJQU5B IHJlZ2lzdHJ5IGF0DQogICBodHRwOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL21pa2V5LXBh eWxvYWRzIChUaGlzIHBhcmFncmFwaCB0byBiZQ0KICAgcmVtb3ZlZCBhZnRlciBJQU5BIHByb2Nl c3NpbmcpLg0KDQogICBBY2NvcmRpbmcgdG8gU2VjdGlvbiAxMCBvZiBSRkMgMzgzMCwgSUVURiBj b25zZW5zdXMgaXMgcmVxdWlyZWQgdG8NCiAgIHJlZ2lzdGVyIHZhbHVlcyBpbiB0aGUgcmFuZ2Ug MC0yNDAgaW4gdGhlIFNSVFAgYXV0aCBhbGcgbmFtZXNwYWNlDQogICBhbmQgdGhlIFNSVFAgVHlw ZSBuYW1lc3BhY2UuDQoNCiAgIEl0IGlzIHJlcXVlc3RlZCB0byByZWdpc3RlciB0aGUgdmFsdWUg MiBmb3IgUkNDdjEgYW5kIHRoZSB2YWx1ZSAzDQogICBmb3IgUkNDdjIgaW4gdGhlIFNSVFAgYXV0 aCBhbGcgbmFtZXNwYWNlIGFzIHNwZWNpZmllZCBpbiBUYWJsZSAxIGluDQogICBTZWN0aW9uIDQu DQoNCiAgIEl0IGlzIGFsc28gcmVxdWVzdGVkIHRvIHJlZ2lzdGVyIHRoZSB2YWx1ZSAxMyBmb3Ig Uk9DIHRyYW5zbWlzc2lvbg0KICAgcmF0ZSBpbiB0aGUgU1JUUCBUeXBlIG5hbWVzcGFjZSBhcyBz cGVjaWZpZWQgaW4gVGFibGUgMiBpbiBTZWN0aW9uDQogICA0Lg0KDQogICBJdCBpcyBhbHNvIHJl cXVlc3RlZCB0byByZWdpc3RlciB0aGUgdmFsdWVzIDE0IHRvIDE5IGFjY29yZGluZyB0bw0KICAg VGFibGUgMyBpbiBTZWN0aW9uIDQgdG8gdGhlIFNSVFAgVHlwZSBuYW1lc3BhY2UuDQoNCjguIEF1 dGhvcidzIEFkZHJlc3Nlcw0KDQogICBRdWVzdGlvbnMgYW5kIGNvbW1lbnRzIHNob3VsZCBiZSBk aXJlY3RlZCB0byB0aGUgYXV0aG9yczoNCg0KICAgICAgVmVzYSBMZWh0b3ZpcnRhDQogICAgICBF cmljc3NvbiBSZXNlYXJjaA0KICAgICAgMDI0MjAgSm9ydmFzICAgICAgICAgICBQaG9uZTogICsz NTggOSAyOTkzMzE0DQogICAgICBGaW5sYW5kICAgICAgICAgICAgICAgIEVNYWlsOiAgdmVzYS5s ZWh0b3ZpcnRhQGVyaWNzc29uLmNvbQ0KDQogICAgICBNYXRzIE5hc2x1bmQNCiAgICAgIEVyaWNz c29uIFJlc2VhcmNoDQogICAgICBTRS0xNjQ4MCBTdG9ja2hvbG0gICAgIFBob25lOiAgKzQ2IDgg NTg1MzM3MzkNCiAgICAgIFN3ZWRlbiAgICAgICAgICAgICAgICAgRU1haWw6ICBtYXRzLm5hc2x1 bmRAZXJpY3Nzb24uY29tDQoNCiAgICAgIEthcmwgTm9ycm1hbg0KICAgICAgRXJpY3Nzb24gUmVz ZWFyY2gNCiAgICAgIFNFLTE2NDgwIFN0b2NraG9sbSAgICAgUGhvbmU6ICArNDYgOCA0MDQ0NTAy DQogICAgICBTd2VkZW4gICAgICAgICAgICAgICAgIEVNYWlsOiAga2FybC5ub3JybWFuQGVyaWNz c29uLmNvbQ0KDQoNCg0KTGVodG92aXJ0YSBldCBhbC4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBbUGFnZSA3XQ0KDA0KSU5URVJORVQtRFJBRlQgICAgICAgICAg ICAgICAgICBzcnRwLXJjYyAgICAgICAgICAgICAgICBGZWJydWFyeSwgMjAwNg0KDQoNCg0KDQoN Cg0KOS4gUmVmZXJlbmNlcw0KDQogICBOb3JtYXRpdmUNCg0KICAgW1JGQzM4MzBdIEFya2tvIGV0 IGFsLiwgIk1JS0VZOiBNdWx0aW1lZGlhIEludGVybmV0IEtFWWluZyIsIFJGQw0KICAgMzgzMCwg QXVndXN0IDIwMDQuDQoNCiAgIFtSRkMzNzExXSBCYXVnaGVyIGV0IGFsLiwgIlRoZSBTZWN1cmUg UmVhbC10aW1lIFRyYW5zcG9ydCBQcm90b2NvbA0KICAgKFNSVFApIiwgUkZDMzcxMSwgTWFyY2gg MjAwNC4NCg0KDQogICBJbmZvcm1hdGl2ZQ0KDQogICBbTUJNU10gM0dQUCBUUyAzMy4yNDYsICJU ZWNobmljYWwgU3BlY2lmaWNhdGlvbiAzcmQgR2VuZXJhdGlvbg0KICAgUGFydG5lcnNoaXAgUHJv amVjdDsgVGVjaG5pY2FsIFNwZWNpZmljYXRpb24gR3JvdXAgU2VydmljZXMgYW5kDQogICBTeXN0 ZW0gQXNwZWN0czsgU2VjdXJpdHk7IFNlY3VyaXR5IG9mIE11bHRpbWVkaWEgQnJvYWRjYXN0L011 bHRpY2FzdA0KICAgU2VydmljZS4iDQoNCiAgIFtCQ01DU10gM0dQUDIgWC5TMDAyMi0wLCAiQnJv YWRjYXN0IGFuZCBNdWx0aWNhc3QgU2VydmljZSBpbg0KICAgY2RtYTIwMDAgV2lyZWxlc3MgSVAg bmV0d29yayINCg0KDQpJbnRlbGxlY3R1YWwgUHJvcGVydHkNCg0KICAgVGhlIElFVEYgdGFrZXMg bm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0eSBvciBzY29wZSBvZiBhbnkNCiAgIElu dGVsbGVjdHVhbCBQcm9wZXJ0eSBSaWdodHMgb3Igb3RoZXIgcmlnaHRzIHRoYXQgbWlnaHQgYmUg Y2xhaW1lZA0KICAgdG8gcGVydGFpbiB0byB0aGUgaW1wbGVtZW50YXRpb24gb3IgdXNlIG9mIHRo ZSB0ZWNobm9sb2d5IGRlc2NyaWJlZA0KICAgaW4gdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50 IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVuZGVyIHN1Y2gNCiAgIHJpZ2h0cyBtaWdodCBvciBtaWdo dCBub3QgYmUgYXZhaWxhYmxlOyBub3IgZG9lcyBpdCByZXByZXNlbnQgdGhhdA0KICAgaXQgaGFz IG1hZGUgYW55IGluZGVwZW5kZW50IGVmZm9ydCB0byBpZGVudGlmeSBhbnkgc3VjaCByaWdodHMu DQogICBJbmZvcm1hdGlvbiBvbiB0aGUgcHJvY2VkdXJlcyB3aXRoIHJlc3BlY3QgdG8gcmlnaHRz IGluIFJGQw0KICAgZG9jdW1lbnRzIGNhbiBiZSBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4N Cg0KICAgQ29waWVzIG9mIElQUiBkaXNjbG9zdXJlcyBtYWRlIHRvIHRoZSBJRVRGIFNlY3JldGFy aWF0IGFuZCBhbnkNCiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFi bGUsIG9yIHRoZSByZXN1bHQgb2YgYW4NCiAgIGF0dGVtcHQgbWFkZSB0byBvYnRhaW4gYSBnZW5l cmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVzZQ0KICAgb2Ygc3VjaCBwcm9wcmll dGFyeSByaWdodHMgYnkgaW1wbGVtZW50ZXJzIG9yIHVzZXJzIG9mIHRoaXMNCiAgIHNwZWNpZmlj YXRpb24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y eQ0KICAgYXQgaHR0cDovL3d3dy5pZXRmLm9yZy9pcHIuDQoNCiAgIFRoZSBJRVRGIGludml0ZXMg YW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNv cHlyaWdodHMsIHBhdGVudHMgb3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJp ZXRhcnkNCiAgIHJpZ2h0cyB0aGF0IG1heSBjb3ZlciB0ZWNobm9sb2d5IHRoYXQgbWF5IGJlIHJl cXVpcmVkIHRvIGltcGxlbWVudA0KDQoNCg0KDQpMZWh0b3ZpcnRhIGV0IGFsLiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJTlRFUk5FVC1E UkFGVCAgICAgICAgICAgICAgICAgIHNydHAtcmNjICAgICAgICAgICAgICAgIEZlYnJ1YXJ5LCAy MDA2DQoNCg0KICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBhZGRyZXNzIHRoZSBpbmZvcm1hdGlv biB0byB0aGUgSUVURiBhdCBpZXRmLQ0KICAgaXByQGlldGYub3JnLg0KDQoNCkNvcHlyaWdodCBO b3RpY2UNCg0KICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNikuICBU aGlzIGRvY3VtZW50IGlzIHN1YmplY3QNCiAgIHRvIHRoZSByaWdodHMsIGxpY2Vuc2VzIGFuZCBy ZXN0cmljdGlvbnMgY29udGFpbmVkIGluIEJDUCA3OCwgYW5kDQogICBleGNlcHQgYXMgc2V0IGZv cnRoIHRoZXJlaW4sIHRoZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLg0KDQoNCkRp c2NsYWltZXIgb2YgVmFsaWRpdHkNCg0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uDQogICBhbiAiQVMgSVMiIGJhc2lz IGFuZCBUSEUgQ09OVFJJQlVUT1IsIFRIRSBPUkdBTklaQVRJT04gSEUvU0hFDQogICBSRVBSRVNF TlRTIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5E IFRIRQ0KICAgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJTSBBTEwgV0FS UkFOVElFUywgRVhQUkVTUyBPUg0KICAgSU1QTElFRCwgSU5DTFVESU5HIEJVVCBOT1QgTElNSVRF RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GDQogICBUSEUgSU5GT1JNQVRJT04gSEVS RUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQNCiAgIFdBUlJB TlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQ T1NFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQpMZWh0b3ZpcnRhIGV0IGFsLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFtQYWdlIDldDQoMDQo= ------_=_NextPart_001_01C63173.3FD11085 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec ------_=_NextPart_001_01C63173.3FD11085-- From msec-bounces@securemulticast.org Fri Feb 17 06: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 1FA3g9-0005Ag-UI for msec-archive@megatron.ietf.org; Fri, 17 Feb 2006 06: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 GAA20463 for ; Fri, 17 Feb 2006 06:19:49 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 09FBC2BF11; Fri, 17 Feb 2006 05:15: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 7F3C62BEDD for ; Fri, 17 Feb 2006 05:15:33 -0500 (EST) Received: (qmail 45089 invoked by uid 3269); 17 Feb 2006 10:15:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45086 invoked from network); 17 Feb 2006 10:15:33 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Feb 2006 10:15:33 -0000 Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by klesh.pair.com (Postfix) with ESMTP id 35EFA68382 for ; Fri, 17 Feb 2006 05:15:33 -0500 (EST) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k1HAFIxw007678; Fri, 17 Feb 2006 11:15:19 +0100 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k1HAFHuB001459; Fri, 17 Feb 2006 11:15:17 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 11:15:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2006 11:15:15 +0100 Message-ID: Thread-Topic: Comments to draft-ietf-msec-mikey-rsa-r-02.txt thread-index: AcYpe44D2L0occfSR0OmydExhC/pRgKLn7vQ From: "Fries, Steffen" To: X-OriginalArrivalTime: 17 Feb 2006 10:15:16.0893 (UTC) FILETIME=[0C8254D0:01C633AB] Cc: canetti Subject: [MSEC] Comments to draft-ietf-msec-mikey-rsa-r-02.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 Content-Transfer-Encoding: quoted-printable Hi, just some minor comments to draft-ietf-msec-mikey-rsa-r-02.txt before the LC closes. =20 Just my 2 cents: - in section 2.1, when discussing the two DH approaches, it might be worth mentioning that DH-HMAC suffers the same limitations as PSK with respect to scalability - in section 3.2, first paragraph, there is a "SHOULD/MUST" statement. I would propose to make it a MUST becaus of the reasonning following that statement - in section 3.4.3 (and the IANA considerations section, the CSB-ID type added to the Type registry should be '3', as '2' has been taken for TESLA I-Key in draft-ietf-msec-bootstrapping-tesla-03.txt, which is in RFC editors queue. The draft is well written from my point of view and provides an interesting extension to MIKEY. Regards Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Feb 17 10:33:21 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA73s-0005T4-GS for msec-archive@megatron.ietf.org; Fri, 17 Feb 2006 09:58: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 JAA15986 for ; Fri, 17 Feb 2006 09:56:30 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C02852CA8F; Fri, 17 Feb 2006 09:06:52 -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 B99B52CAA6 for ; Fri, 17 Feb 2006 09:06:49 -0500 (EST) Received: (qmail 91218 invoked by uid 3269); 17 Feb 2006 14:06:49 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 91215 invoked from network); 17 Feb 2006 14:06:49 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Feb 2006 14:06:49 -0000 Received: from m5tmail1.m5t.com (m5tmail1.m5t.com [207.134.65.96]) by klesh.pair.com (Postfix) with ESMTP id 812A768382 for ; Fri, 17 Feb 2006 09:06:48 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 17 Feb 2006 09:06:44 -0500 Message-ID: <83F34964B9BBA546BF2584D46870EB99200F6A@m5tmail1.m5t.com> Thread-Topic: Mixing Session Level and Media Level a=key-mgmt:mikey lines Thread-Index: AcYyam1Pj/sTUjbsRQatYS5hCPetCwBYKHjgAAAKdfA= From: "Christian Beaulieu" To: Subject: [MSEC] Mixing Session Level and Media Level a=key-mgmt:mikey lines 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="===============1554420418==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org This is a multi-part message in MIME format. --===============1554420418== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C633CB.0AF7DB92" This is a multi-part message in MIME format. ------_=_NextPart_001_01C633CB.0AF7DB92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Guylain Lavoie=20 Hi everyone, =20 I have two questions related to the utilization of MIKEY with SDP. =20 As stated in draft-ietf-mmusic-kmgmt-ext-15.txt, a single SRTP media stream generates two MIKEY crypto sessions. The first is outgoing and includes the locally known outgoing SSRC and ROC. The second is incoming and includes zeroed SSRC and ROC since they are not known. The MIKEY responder will later provide them in its MIKEY response. =20 Now that being said, if a=3Dkey-mgmt:mikey line is located at the = session level and there are two m=3D lines, the session level MIKEY exchange = will contain four crypto sessions. Two for each of the SRTP streams. Here is the example. =20 v=3D0 o=3Dalice 2891092738 2891092738 IN IP4 w-land.example.com s=3DCool stuff e=3Dalice@w-land.example.com t=3D0 0 c=3DIN IP4 w-land.example.com a=3Dkey-mgmt:mikey AQAFgM0XflABZZZZZZZZZZZZZZZZZAy... <=3D=3D 4 CS m=3Daudio 49000 RTP/SAVP 98 a=3Drtpmap:98 AMR/8000 m=3Dvideo 52230 RTP/AVP 31 a=3Drtpmap:31 H261/90000 =20 =20 draft-ietf-mmusic-kmgmt-ext-15.txt also states that if a key-mgmt attribute exists at the media level, the session level attribute MUST be ignored. =20 Now, this puzzles me. If we reuse the previous example but with a single modification. If one of the media level also contains a = a=3Dkey-mgmt:mikey line. How many crypto sessions will now be created within the session level MIKEY initiate message? Four or Two? Four for both media lines even if the first one also contains a a=3Dkey-mgmt:mikey line or two, = only for the second media line. =20 For example, =20 v=3D0 o=3Dalice 2891092738 2891092738 IN IP4 w-land.example.com s=3DCool stuff e=3Dalice@w-land.example.com t=3D0 0 c=3DIN IP4 w-land.example.com a=3Dkey-mgmt:mikey AQAFgM0XflABZZZZZZZZZZZZZZZZZAy... <=3D=3D 4 or 2 = CS? m=3Daudio 49000 RTP/SAVP 98 a=3Drtpmap:98 AMR/8000 a=3Dkey-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... <=3D=3D 2 CS m=3Dvideo 52230 RTP/AVP 31 a=3Drtpmap:31 H261/90000 =20 My second question is "What should we do if the media level MIKEY exchange fails while the session level MIKE exchanges is successful?". draft-ietf-mmusic-kmgmt-ext-15.txt says that the session level must be ignored. I assume that if the media level MIKEY exchange fails, then there will be no automatic fallback to the session level MIKEY exchange event if the answer to the first question is four. If the answer was two, then it becomes obvious that there is no fallback. I would expect that no fallback is possible (in all cases). =20 Best Regards, Guylain Lavoie =20 ------_=_NextPart_001_01C633CB.0AF7DB92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From: = Guylain Lavoie

Hi everyone,

 

I have two questions related to the utilization of MIKEY with = SDP.

 

As stated in draft-ietf-mmusic-kmgmt-ext-15.txt, a single SRTP = media stream generates two MIKEY crypto sessions. The first is outgoing and = includes the locally known outgoing SSRC and ROC. The second is incoming and = includes zeroed SSRC and ROC since they are not known. The MIKEY responder will = later provide them in its MIKEY response.

 

Now that being said, if a=3Dkey-mgmt:mikey line is located at = the session level and there are two m=3D lines, the session level MIKEY exchange = will contain four crypto sessions. Two for each of the SRTP streams. Here is the = example.

 

   v=3D0

   o=3Dalice 2891092738 2891092738 IN IP4 = w-land.example.com

   s=3DCool stuff

   = e=3Dalice@w-land.example.com

   t=3D0 0

   c=3DIN IP4 = w-land.example.com

   a=3Dkey-mgmt:mikey = AQAFgM0XflABZZZZZZZZZZZZZZZZZAy... <=3D=3D 4 CS

   m=3Daudio 49000 RTP/SAVP = 98

   a=3Drtpmap:98 AMR/8000

   m=3Dvideo 52230 RTP/AVP = 31

   a=3Drtpmap:31 = H261/90000

 

 

draft-ietf-mmusic-kmgmt-ext-15.txt also states that if a = key-mgmt attribute exists at the media level, the session level attribute MUST be ignored.

 

Now, this puzzles me. If we reuse the previous example but with = a single modification. If one of the media level also contains a = a=3Dkey-mgmt:mikey line. How many crypto sessions will now be created within the session = level MIKEY initiate message? Four or Two? Four for both media lines even if = the first one also contains a a=3Dkey-mgmt:mikey line or two, only for the = second media line.

 

For example,

 

   v=3D0

   o=3Dalice 2891092738 2891092738 IN IP4 = w-land.example.com

   s=3DCool stuff

   = e=3Dalice@w-land.example.com

   t=3D0 0

   c=3DIN IP4 = w-land.example.com

   a=3Dkey-mgmt:mikey = AQAFgM0XflABZZZZZZZZZZZZZZZZZAy... <=3D=3D 4 or 2 CS?

   m=3Daudio 49000 RTP/SAVP = 98

   a=3Drtpmap:98 AMR/8000

   a=3Dkey-mgmt:mikey AQAFgM0XflABAAAAAAAAAAAAAAsAy... = <=3D=3D 2 CS

   m=3Dvideo 52230 RTP/AVP = 31

   a=3Drtpmap:31 = H261/90000

 

My second question is “What should we do if the media = level MIKEY exchange fails while the session level MIKE exchanges is = successful?”. draft-ietf-mmusic-kmgmt-ext-15.txt says that the session level must be = ignored. I assume that if the media level MIKEY exchange fails, then there will = be no automatic fallback to the session level MIKEY exchange event if the = answer to the first question is four. If the answer was two, then it becomes = obvious that there is no fallback. I would expect that no fallback is possible (in = all cases).

 

Best Regards,

Guylain = Lavoie

 

------_=_NextPart_001_01C633CB.0AF7DB92-- --===============1554420418== 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 --===============1554420418==-- From msec-bounces@securemulticast.org Fri Feb 17 13:24:11 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAH5-0006kK-4t for msec-archive@megatron.ietf.org; Fri, 17 Feb 2006 13:24:11 -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 NAA19131 for ; Fri, 17 Feb 2006 13:22:23 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DD2CA2C874; Fri, 17 Feb 2006 13:24:09 -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 33C572C85D for ; Fri, 17 Feb 2006 13:24:08 -0500 (EST) Received: (qmail 40299 invoked by uid 3269); 17 Feb 2006 18:24:08 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 40296 invoked from network); 17 Feb 2006 18:24:08 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Feb 2006 18:24:08 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id F024868377 for ; Fri, 17 Feb 2006 13:24:07 -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 k1HIO4c4026805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Feb 2006 10:24:05 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-211.qualcomm.com [10.50.68.211]) by neophyte.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1HIO3P8018645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Feb 2006 10:24:03 -0800 (PST) Message-Id: <6.2.5.6.2.20060217102009.05f16708@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 17 Feb 2006 10:24:02 -0800 To: "Fries, Steffen" , From: Lakshminath Dondeti In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: canetti Subject: [MSEC] Re: Comments to draft-ietf-msec-mikey-rsa-r-02.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 Hi Steffen, Many thanks for your review. Please see inline for some notes: At 02:15 AM 2/17/2006, Fries, Steffen wrote: >Hi, > >just some minor comments to draft-ietf-msec-mikey-rsa-r-02.txt before >the LC closes. > >Just my 2 cents: >- in section 2.1, when discussing the two DH approaches, it might be >worth mentioning that DH-HMAC suffers the same limitations as PSK with >respect to scalability We'll do this. >- in section 3.2, first paragraph, there is a "SHOULD/MUST" statement. I >would propose to make it a MUST becaus of the reasonning following that >statement With the qualifier "for the RTP streams it (Initiator) originates," MUST makes sense to me. Dragan, Ping, Francois, any opinions? >- in section 3.4.3 (and the IANA considerations section, the CSB-ID type >added to the Type registry should be '3', as '2' has been taken for >TESLA I-Key in draft-ietf-msec-bootstrapping-tesla-03.txt, which is in >RFC editors queue. Will do. >The draft is well written from my point of view and provides an >interesting extension to MIKEY. Many thanks for your comments, Steffen. best regards, Lakshminath >Regards > Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Feb 17 13:55:02 2006 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FAAkw-0008S0-Gi for msec-archive@megatron.ietf.org; Fri, 17 Feb 2006 13:55:02 -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 NAA21674 for ; Fri, 17 Feb 2006 13:53:14 -0500 (EST) Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9E0072C258; Fri, 17 Feb 2006 13:55: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 A74272C051 for ; Fri, 17 Feb 2006 13:55:00 -0500 (EST) Received: (qmail 45093 invoked by uid 3269); 17 Feb 2006 18:55:00 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 45090 invoked from network); 17 Feb 2006 18:55:00 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 17 Feb 2006 18:55:00 -0000 Received: from milpmailbhs.milpitas.polycom.com (mail.polycom.com [140.242.16.3]) by klesh.pair.com (Postfix) with ESMTP id 6E82768382 for ; Fri, 17 Feb 2006 13:55:00 -0500 (EST) Received: from vanmail01.vancouver.polycom.com ([172.16.1.119]) by milpmailbhs.milpitas.polycom.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Feb 2006 10:54:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 17 Feb 2006 10:54:58 -0800 Message-ID: <4280DB4085C0FC4BAA41AB503C1024D07DB38F@vanmail01.vancouver.polycom.com> Thread-Topic: Comments to draft-ietf-msec-mikey-rsa-r-02.txt Thread-Index: AcYz72UW9jqK6mvRR5menT7wraO1dwAA9jSg From: "Ignjatic, Dragan" To: "Lakshminath Dondeti" , "Fries, Steffen" , X-OriginalArrivalTime: 17 Feb 2006 18:54:59.0196 (UTC) FILETIME=[A69C2BC0:01C633F3] Cc: canetti Subject: [MSEC] RE: Comments to draft-ietf-msec-mikey-rsa-r-02.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 Content-Transfer-Encoding: quoted-printable Steffen, Thank you for the review. > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com] > Sent: February 17, 2006 10:24 AM > To: Fries, Steffen; msec@securemulticast.org > Cc: Ignjatic, Dragan; canetti > Subject: Re: Comments to draft-ietf-msec-mikey-rsa-r-02.txt >=20 > Hi Steffen, >=20 > Many thanks for your review. Please see inline for some notes: >=20 > At 02:15 AM 2/17/2006, Fries, Steffen wrote: > >Hi, > > > >just some minor comments to draft-ietf-msec-mikey-rsa-r-02.txt before > >the LC closes. > > > >Just my 2 cents: > >- in section 2.1, when discussing the two DH approaches, it might be > >worth mentioning that DH-HMAC suffers the same limitations as PSK with > >respect to scalability >=20 > We'll do this. >=20 > >- in section 3.2, first paragraph, there is a "SHOULD/MUST" statement. I > >would propose to make it a MUST becaus of the reasonning following that > >statement >=20 > With the qualifier "for the RTP streams it (Initiator) originates," > MUST makes sense to me. >=20 > Dragan, Ping, Francois, any opinions? I fully agree, should be a MUST with that qualifier. Thanks again for catching all of these. Regards, Dragan >=20 >=20 > >- in section 3.4.3 (and the IANA considerations section, the CSB-ID type > >added to the Type registry should be '3', as '2' has been taken for > >TESLA I-Key in draft-ietf-msec-bootstrapping-tesla-03.txt, which is in > >RFC editors queue. >=20 > Will do. >=20 >=20 > >The draft is well written from my point of view and provides an > >interesting extension to MIKEY. >=20 > Many thanks for your comments, Steffen. >=20 > best regards, > Lakshminath >=20 > >Regards > > Steffen _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Sun Feb 19 01:21:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FAhx6-0004RP-28 for msec-archive@lists.ietf.org; Sun, 19 Feb 2006 01:21:48 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FAhx4-000062-RK for msec-archive@lists.ietf.org; Sun, 19 Feb 2006 01:21:48 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 0F2A32C7AA; Sun, 19 Feb 2006 01:21:46 -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 3F6392C7A8 for ; Sun, 19 Feb 2006 01:21:44 -0500 (EST) Received: (qmail 26039 invoked by uid 3269); 19 Feb 2006 06:21:44 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 26036 invoked from network); 19 Feb 2006 06:21:44 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 19 Feb 2006 06:21:44 -0000 Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by klesh.pair.com (Postfix) with ESMTP id F05776838B for ; Sun, 19 Feb 2006 01:21:43 -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 k1J6Lfc4001881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 18 Feb 2006 22:21:42 -0800 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-36.qualcomm.com [10.50.68.36]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k1J6LeTx023060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 18 Feb 2006 22:21:40 -0800 (PST) Message-Id: <6.2.5.6.2.20060218221632.03c943e0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 18 Feb 2006 22:21:38 -0800 To: msec@securemulticast.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [MSEC] MSEC meeting in Dallas X-BeenThere: msec@securemulticast.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "IETF Multicast Security \(MSEC\) WG list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Hi all, As it stands now, we are meeting on Tuesday, but please do remember that scheduling changes are possible until the agenda is finalized (especially this time; apparently a few groups are yet to be scheduled). The final agenda will be published on the 27th of February. TUESDAY, March 21, 2006 1300-1500 Afternoon Session I -- 2 hour SEC msec Multicast Security WG thanks and regards, Lakshminath _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Fri Feb 24 04:25:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCZCI-0007wO-SM for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 04:25:10 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCZCH-00045p-9Q for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 04:25:10 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id C4D012C258; Fri, 24 Feb 2006 04:25:08 -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 E4B952C1CA for ; Fri, 24 Feb 2006 04:25:06 -0500 (EST) Received: (qmail 92397 invoked by uid 3269); 24 Feb 2006 09:25:06 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 92394 invoked from network); 24 Feb 2006 09:25:06 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Feb 2006 09:25:06 -0000 Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by klesh.pair.com (Postfix) with ESMTP id 5B62568382 for ; Fri, 24 Feb 2006 04:25:06 -0500 (EST) Received: from esealmw126.eemea.ericsson.se (unknown [153.88.254.123]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 2100F1B0; Fri, 24 Feb 2006 10:25:05 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 10:25:04 +0100 Received: from esealmw114.eemea.ericsson.se ([153.88.200.5]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Feb 2006 10:25:04 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt Date: Fri, 24 Feb 2006 10:25:03 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Comments to draft draft-ietf-msec-mikey-rsa-r-02.txt thread-index: AcY5JDE3EyNS6HxFSN60zhPECqlMuQ== From: "Vesa Lehtovirta (JO/LMF)" To: "Lakshminath Dondeti" , "Ignjatic, Dragan" , X-OriginalArrivalTime: 24 Feb 2006 09:25:04.0754 (UTC) FILETIME=[3206A520:01C63924] X-Brightmail-Tracker: AAAAAA== Cc: 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="===============1844815989==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.1 (/) X-Scan-Signature: fb93e867a11a29ac1dc5018706b412ac This is a multi-part message in MIME format. --===============1844815989== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C63924.31920B16" This is a multi-part message in MIME format. ------_=_NextPart_001_01C63924.31920B16 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Here are some comments, and also questions, to the draft-ietf-msec-mikey-rsa-r-02.txt. In general the draft is well written and an interesting approach.=20 Best regards, Vesa - Issue: Abstract says that=20 "The Multimedia Internet Keying (MIKEY) specification describes=20 several modes of key distribution to setup Secure Real-time Rransport=20 Protocol (SRTP) sessions..."=20 Comment: The draft generally gives the impression that MIKEY is used solely for setting up keys for SRTP. However, MIKEY is not restricted to SRTP only, although certain parameters have been specified already for SRTP in MIKEY RFC3830. MIKEY is extensible to be used with other security protocols also but this may require that needed parameters can be specified also for other security protocols. Therefore, it would be good to mention SRTP as one possible security protocol and not the only possible one. Or is it the intention that this would be used only with SRTP? - Issue: One of the main points in the draft is that the Initiator may not know the Responder's ID and in 3.2 it is said for the I_MESSAGE: "If the Responder has multiple Identities, the Initiator MAY also=20 include the specific ID, IDr, of the Responder that it wants to=20 communicate with."=20 Comment: The question is, if the IDr is not indicated in the I_MESSAGE, how can the message be routed to the correct responder? If this is assumed to be done in some other layer, e.g. SIP, how can the initiator know the SIP layer identity if it does not know the MIKEY layer identity? Or is it assumed then that e.g. the SIP layer identity may be known even though the MIKEY layer identity is not known? - Issue: In 3.2 it is said that "The Initiator MAY indicate the number of CSs supported,.." but in 3.2 it is said that "The Responder MUST fill in the number of CSs"=20 Comment: Why is it differently? Should both be MUST?=20 - Issue: In 5 (last para) it is said that "Unicast and multicast keys have different=20 security properties and should not be derived from the same pool."=20 Comment: Usually we can trust to one-way key derivation functions to provide key separation. Is there a reason why we cannot assume it here?=20 - Issue: In 5 (last para) it is said that=20 "The authors believe that multiple TGK payloads can be used for this=20 purpose but the exact method is not specified in MIKEY."=20 Comment: When checking this seems to be specified in 6.2 and 6.13 of RFC 3830.=20 - Smaller stuff: In 3.3 (page 7): What is "complete CS map"? Is it "CS ID map info"?=20 - Smaller stuff: In 3.4.1, 3.4.2 and 3.4.3 it could be indicated what is new information.=20 - Finally some comments on some "extra" messages on the proposed procedure: The current draft proposes a solution where the Initiator prompts the Responder to send the TGK key. I wonder if the procedure could be extended with a Verification message to know that the key has been delivered (as in current MIKEY): Init Resp=20 ----- ----=20 I_MSG[CERTi] --> =20 <-- R_MSG(TGK)[CERTr] =20 I_MSG[Verif] --> =20 Also, the current draft does not allow the Initiator to choose the TGK. I wonder if the procedure could be also extended with a new message in the beginning of the procedure where the Init could ask the Resp to request the key from Init. I guess you have thought of this since this case has been shortly discussed in 4.1 but then you have abandobed it as too complex?: "For instance, A might ask C to contact B or itself to get the TGK, in effect initiating a 3-way exchange. " =20 Init Resp=20 ----- ----=20 I_MSG[CERTi] --> =20 <-- R_MSG[CERTr] =20 I_MSG(TGK) --> =20 =20 ------_=_NextPart_001_01C63924.31920B16 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi=20 all,

Here are = some=20 comments, and also questions, to the=20 draft-ietf-msec-mikey-rsa-r-02.txt.

In = general the draft=20 is well written and an interesting approach.

Best=20 regards,

  =20 Vesa

- Issue: Abstract says that
"The = Multimedia=20 Internet Keying (MIKEY) specification describes
several modes of key = distribution to setup Secure Real-time Rransport
Protocol (SRTP)=20 sessions..."

Comment: The draft generally gives the = impression=20 that MIKEY is used solely for setting up keys for SRTP. However, MIKEY = is not=20 restricted to SRTP only, although certain parameters have been specified = already=20 for SRTP in MIKEY RFC3830. MIKEY is extensible to be used with other = security=20 protocols also but this may require that needed parameters can be = specified also=20 for other security protocols. Therefore, it would be good to mention = SRTP as one=20 possible security protocol and not the only possible one. Or is it the = intention=20 that this would be used only with SRTP?

- Issue: One of the main points in the = draft is that=20 the Initiator may not know the Responder's ID and in 3.2 it is said for = the=20 I_MESSAGE:

"If the Responder has multiple = Identities, the=20 Initiator MAY also
include the specific ID, IDr, of the Responder = that it=20 wants to
communicate with."

Comment: The question is, if the IDr is = not indicated=20 in the I_MESSAGE, how can the message be routed to the correct = responder? If=20 this is assumed to be done in some other layer, e.g. SIP, how can the = initiator=20 know the SIP layer identity if it does not know the MIKEY layer = identity? Or is=20 it assumed then that e.g. the SIP layer identity may be known even = though the=20 MIKEY layer identity is not known?

- Issue: In 3.2 it is said that "The = Initiator MAY=20 indicate the number of CSs supported,.." but in 3.2 it is said that "The = Responder MUST fill in the number of CSs"
Comment: Why is it = differently?=20 Should both be MUST?

- Issue: In 5 (last para) it is said that = "Unicast=20 and multicast keys have different
security properties and should not = be=20 derived from the same pool."

Comment: Usually we can trust to one-way = key=20 derivation functions to provide key separation. Is there a reason why we = cannot=20 assume it here?

- Issue: In 5 (last para) it is said that =
"The=20 authors believe that multiple TGK payloads can be used for this =
purpose but=20 the exact method is not specified in MIKEY."

Comment: When checking this seems to be = specified in=20 6.2 and 6.13 of RFC 3830.

- Smaller stuff: In 3.3 (page 7): What is = "complete=20 CS map"? Is it "CS ID map info"?

- Smaller stuff: In 3.4.1, 3.4.2 and = 3.4.3 it could=20 be indicated what is new information.

- Finally some comments on some "extra" = messages on=20 the proposed procedure: The current draft proposes a solution where the=20 Initiator prompts the Responder to send the TGK key. I wonder if the = procedure=20 could be extended with a Verification message to know that the key has = been=20 delivered (as in current MIKEY):

Init          =   =20 Resp =
-----          &nbs= p;=20 ----
I_MSG[CERTi]  = -->       =20
       <--=20 R_MSG(TGK)[CERTr]         =20
I_MSG[Verif]=20 -->           &= nbsp; =20

Also, the current draft does not allow = the Initiator=20 to choose the TGK. I wonder if the procedure could be also extended with = a new=20 message in the beginning of the procedure where the Init could ask the = Resp to=20 request the key from Init. I guess you have thought of this = since this case has been shortly discussed = in 4.1 but=20 then you have abandobed it as too complex?: "For instance, A might ask C = to=20 contact B or itself to get the TGK, in effect initiating a 3-way = exchange.=20 " 

Init          =   =20 Resp =
-----          &nbs= p;=20 ----
I_MSG[CERTi]=20 -->          
&nb= sp;     =20 <-- = R_MSG[CERTr]         =20
I_MSG(TGK) --> 

 
------_=_NextPart_001_01C63924.31920B16-- --===============1844815989== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============1844815989==-- From msec-bounces@securemulticast.org Fri Feb 24 10:40:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FCf3b-000464-KO for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 10:40:35 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FCf3Z-0006mP-8M for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 10:40:35 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id DC33F2B94E; Fri, 24 Feb 2006 10:40:32 -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 1AE2D2B931 for ; Fri, 24 Feb 2006 10:40:32 -0500 (EST) Received: (qmail 35328 invoked by uid 3269); 24 Feb 2006 15:40:31 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 35325 invoked from network); 24 Feb 2006 15:40:31 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Feb 2006 15:40:31 -0000 Received: from ns1.cpanel.btnaccess.com (ns1.cpanel.btnaccess.com [205.177.121.2]) by klesh.pair.com (Postfix) with ESMTP id ADB0768382 for ; Fri, 24 Feb 2006 10:40:31 -0500 (EST) Received: from [65.213.193.135] (helo=ISODELL001) by ns1.cpanel.btnaccess.com with esmtp (Exim 4.52) id 1FCf3V-0004Wv-R4 for msec@securemulticast.org; Fri, 24 Feb 2006 10:40:29 -0500 From: "Robert Holliday" To: Date: Fri, 24 Feb 2006 10:40:29 -0500 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcY5WKPBG3s3aYOtROmr6QqFQs7E1w== X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - securemulticast.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20060224154031.ADB0768382@klesh.pair.com> Subject: [MSEC] International Conference on Network Security 2006 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="===============0438248520==" Sender: msec-bounces@securemulticast.org Errors-To: msec-bounces@securemulticast.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e This is a multi-part message in MIME format. --===============0438248520== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01C6392E.BC2136D0" This is a multi-part message in MIME format. ------=_NextPart_000_0040_01C6392E.BC2136D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Registration Open!!! Reston Virginia, April 17-19 Early Registration Benefits Now Available The conference offers cutting edge discussion and presentations on the contemporary issues in network security and critical information infrastructure. Technical Program: http://www.isocore.com/networksecurity2006/program.htm Discounts still available for early registration. Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm Hotel space is limited but currently available and reservation can be made on-line. Hotel Reservations: http://www.isocore.com/networksecurity2006/hotel.htm To obtain special rates for student or group please contact Robert Holliday at rholliday@isocore.com. www.networksecurity2006.com ------=_NextPart_000_0040_01C6392E.BC2136D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Registration = Open!!!

 

Reston Virginia, April = 17-19

Early Registration Benefits = Now Available

 

The conference offers cutting edge discussion and presentations on the contemporary issues in network security and = critical information infrastructure. 

 

Technical = Program: http://ww= w.isocore.com/networksecurity2006/program.htm

 

Discounts still available for early = registration.

 

Registration: http://www.isocore.com/networksecurity2006/onlineregis.htm

 

Hotel space is limited but currently available and reservation can be made on-line.

 

Hotel = Reservations: http://www.= isocore.com/networksecurity2006/hotel.htm

 

To obtain special rates for student or group please = contact Robert Holliday at rholliday@isocore.com.

 

www.networksecurity2006.com<= /a>

 

 

 

------=_NextPart_000_0040_01C6392E.BC2136D0-- --===============0438248520== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --===============0438248520==-- From msec-bounces@securemulticast.org Fri Feb 24 13:01:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FChFx-0007ok-W7 for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 13:01:29 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FChFw-0003kU-Je for msec-archive@lists.ietf.org; Fri, 24 Feb 2006 13:01:29 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 74C752CA29; Fri, 24 Feb 2006 13:01:19 -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 CAE972CA51 for ; Fri, 24 Feb 2006 13:01:18 -0500 (EST) Received: (qmail 63605 invoked by uid 3269); 24 Feb 2006 18:01:18 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 63602 invoked from network); 24 Feb 2006 18:01:18 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 24 Feb 2006 18:01:18 -0000 Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by klesh.pair.com (Postfix) with ESMTP id 6A2F868386 for ; Fri, 24 Feb 2006 13:01:18 -0500 (EST) Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 24 Feb 2006 10:01:02 -0800 X-IronPort-AV: i="4.02,144,1139212800"; d="asc'?scan'208"; a="1779484587:sNHT4094765736" Received: from [128.107.163.158] (dhcp-128-107-163-158.cisco.com [128.107.163.158]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k1OI10uh006293; Fri, 24 Feb 2006 10:01:01 -0800 (PST) Message-ID: <43FF49DE.4030307@cisco.com> Date: Fri, 24 Feb 2006 10:01:02 -0800 From: Brian Weis User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec Content-Type: multipart/mixed; boundary="------------030101080805020609030303" Subject: [MSEC] [Fwd: I-D ACTION:draft-weis-gdoi-update-00.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 This is a multi-part message in MIME format. --------------030101080805020609030303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At IETF 64, Russ Housley directed all Security Area WGs to analyze their protocols with respect to adding SHA-256 as a replacement for SHA-1, and more generally to ensure that the protocols supported algorithm agility such that new algorithms can be added. The attached announcement describes our analysis of the GDOI protocol. Since changes are required to add SHA-256, we also took the opportunity to add some clarification text, as well as propose a few new algorithm attributes. We would like to propose this to be an MSEC WG draft. We'd appreciate any comments the WG would have on both the draft itself, as well as its applicability as a WG draft. Thanks, Brian -------- Original Message -------- Subject: I-D ACTION:draft-weis-gdoi-update-00.txt Date: Tue, 21 Feb 2006 23:53:37 GMT From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Updates to the Group Domain of Interpretation (GDOI) Author(s) : B. Weis, S. Rowles Filename : draft-weis-gdoi-update-00.txt Pages : 19 Date : 2006-2-21 This memo describes additional updates to the Group Domain of Interpretation (GDOI) [RFC3547] . It provides clarification where the original text is unclear. It also includes a discussion of algorithm agility within GDOI, and proposes several new algorithm attribute values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-weis-gdoi-update-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-weis-gdoi-update-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-weis-gdoi-update-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ I-D-Announce mailing list I-D-Announce at ietf.org --------------030101080805020609030303 Content-Type: text/plain; x-mac-type="0"; x-mac-creator="0"; name="file:///tmp/nsmail.asc" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="file:///tmp/nsmail.asc" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --------------030101080805020609030303 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec --------------030101080805020609030303-- From msec-bounces@securemulticast.org Mon Feb 27 03:37:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDdsv-0001i2-Gz for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 03:37:37 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDdst-0000zR-VJ for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 03:37:37 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 4F24C2C2E4; Mon, 27 Feb 2006 03:37: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 054262C1C3 for ; Mon, 27 Feb 2006 03:37:34 -0500 (EST) Received: (qmail 39714 invoked by uid 3269); 27 Feb 2006 08:37:33 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 39710 invoked from network); 27 Feb 2006 08:37:32 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Feb 2006 08:37:32 -0000 Received: from thoth.sbs.de (thoth.sbs.de [192.35.17.2]) by klesh.pair.com (Postfix) with ESMTP id 378C768388 for ; Mon, 27 Feb 2006 03:37:31 -0500 (EST) Received: from mail3.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id k1R8bIWe008293; Mon, 27 Feb 2006 09:37:19 +0100 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id k1R8bI7u001612; Mon, 27 Feb 2006 09:37:18 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 09:37:17 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 27 Feb 2006 09:37:17 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Last minute edits in draft-ietf-msec-mikey-dhhmac-11.txt thread-index: AcXrF+7Ov1Ly9eptS8qX6oxI3XsRfBPG1nKA From: "Euchner, Martin" To: "Lakshminath Dondeti" , , "Euchner, Martin" X-OriginalArrivalTime: 27 Feb 2006 08:37:17.0995 (UTC) FILETIME=[048B2FB0:01C63B79] Cc: canetti Subject: [MSEC] Last minute edits in draft-ietf-msec-mikey-dhhmac-11.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Dear MSECers, Following the call of the SAAG Security Area Directorate and the general advice giving by the MSEC WG chair, I've investigated the situation on the security of hash functions in the context of MIKEY-DHHMAC. I've added some new text to the MIKEY-DHHMAC security consideration section where I provide considerations on the security of HMAC-SHA1 in the context of DHHMAC and the formerly reported attacks on hash functions. In particular; let me propose the following new paragraph to be added to the end of section 5.5 "Residual risk": >>> HMAC-SHA1 is a key security mechanism within DHHMAC upon which the overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-SHA1 in combination with the classic Diffie-Hellman key agreement scheme. HMAC-SHA1 is a keyed one-way hash function that involves a secret in its computation. DHHMAC applies HMAC-SHA1 for protection of the MIKEY payload. Likewise, the pseudo-random function PRF within MIKEY [3] uses the HMAC-SHA1 mechanism as a key derivation function. While certain attacks have been reported against SHA1 and MD5 (see [38]), with current knowledge (see [38], [39]), no collision attacks have been reported against the HMAC-SHA1 security mechanism. It is believed that MIKEY DHHMAC should be considered secure enough for the time being. Thus, there is no need to change the underlying security mechanism within the MIKEY DHHMAC protocol. <<< Further, I've added the following two related references to the section 8.2 "Informative References": >>> [38] P. Hoffman, B. Schneier; "Attacks on Cryptographic Hashes in Internet Protocols"; RFC 4270; IETF, November 2005. [39] S.M. Bellovin, E.K. Rescorla: "Deploying a New Hash Algorithm", October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf <<< I've also added a reference to MIKEY-RSA-r by replacing the reference [15] (which is duplicate with [9] and has become RFC 4086 in the meantime) with >>> [15] D. Ignjatic, L. Dondeti et al: "An additional mode of key distribution in MIKEY: MIKEY-RSA-R", Internet Draft, Work in Progress, draft-ietf-msec-mikey-rsa-r-02, IETF, January 2006. <<< Further, I've added reference to the MIKEY-ECC draft >>> [40] A. Milne et al: "ECC Algorithms For MIKEY", Internet Draft, Work in Progress, draft-ietf-msec-mikey-ecc-00, IETF, June 2005. <<< and by replacing the former statement in section 5.5 >>>Note, that an elliptic-curve Diffie-Hellman variant of MIKEY remains for further study.<<< by the new statement >>> Note, that elliptic-curve variants of MIKEY are defined in [40]. <<< There are a few other, very minor typos and editorial corrections that I've made to the -11 version since, which should not be worth mentioning here. Please let me know, if these proposed editorial changes are ok, and if not how the new text should be modified. (No feedback means acceptance). FYI: draft-ietf-msec-mikey-dhhmac-11.txt is IESG approved and is currently sitting in the RFC editors queue and is waiting there for publication. However, DHHMAC is stuck from progress due to various dependencies of other referenced normative draft RFC documents which are yet to enter the RFC editor's queue. With kind regards Martin Euchner. --------------------------------------------------------------------- | Dipl.-Inf. =20 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | COM GCM PS 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany =20 --------------------------------------------------------------------- -----Original Message----- From: msec-bounces@securemulticast.org [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath Dondeti Sent: Donnerstag, 17. November 2005 02:40 To: msec@securemulticast.org Cc: canetti Subject: [MSEC] SHA-1 replacement analyses for MSEC protocols At the SAAG meeting, Russ directed all SEC area WGs to analyze the=20 protocols they are working (worked) on and plan for SHA-1=20 replacement. Here are the directives (1) and (2): "1.Do the Bellovin-Rescorla analysis before IETF 65 for each protocol=20 in the WG" "2.Start standards work for transition to SHA-256, but remember=20 another transition is coming, so plan for it" MSEC has the following documents/protocols to analyze: GSAKMP GDOI MSEC-signatures MIKEY related TESLA Did I miss any? Our first request to everyone is to read the Belloving-Rescorla paper=20 (the relevant NIST and SAAG presentations materials should help as=20 well). Feel free to discuss the analysis method and your review of=20 that paper with other MSEC contributors. References: http://www.cs.columbia.edu/~smb/papers/new-hash.pdf http://www.csrc.nist.gov/pki/HashWorkshop/2005/Oct31_Presentations/Bello vin_new-hash.pdf https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 4 (search for SAAG meeting materials) Next, if you are interested in analyzing any of the MSEC documents or=20 protocols, please contact Ran and me. Some of you have already done=20 so; thanks. We need to start work on this ASAP as we need to finish this work=20 before the March IETF meeting, **February 27, 2006 would be the -00- deadline We'll post the protocol analysis assignments :-) toward the end of=20 next week. (Please hurry and volunteer). thanks and regards, Lakshminath for Ran & Lakshminath PS: Current document authors MUST do the analysis as part of their=20 next document revision. Thanks. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Feb 27 06:44:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDgna-0006Wo-De for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 06:44:18 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDgnV-00072c-Ti for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 06:44:18 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 656A02C5AC; Mon, 27 Feb 2006 06:44:13 -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 7C7D12C2E4 for ; Mon, 27 Feb 2006 06:44:09 -0500 (EST) Received: (qmail 67396 invoked by uid 3269); 27 Feb 2006 11:44:03 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 67393 invoked from network); 27 Feb 2006 11:44:03 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Feb 2006 11:44:03 -0000 Received: from sj-iport-3.cisco.com (sj-iport-3-in.cisco.com [171.71.176.72]) by klesh.pair.com (Postfix) with ESMTP id E1D9C68389 for ; Mon, 27 Feb 2006 06:44:02 -0500 (EST) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 27 Feb 2006 03:44:02 -0800 X-IronPort-AV: i="4.02,149,1139212800"; d="scan'208"; a="410232229:sNHT35426432" 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 k1RBi1Vb014036; Mon, 27 Feb 2006 03:44:01 -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.211); Mon, 27 Feb 2006 03:44:01 -0800 Received: from [192.168.1.100] ([10.32.254.210]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 27 Feb 2006 03:44:00 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10CFE1EB-416C-4A32-B4B4-995675484137@cisco.com> Content-Transfer-Encoding: 7bit From: David McGrew Subject: Re: [MSEC] Last minute edits in draft-ietf-msec-mikey-dhhmac-11.txt Date: Mon, 27 Feb 2006 03:43:53 -0800 To: "Euchner, Martin" X-Mailer: Apple Mail (2.746.2) X-OriginalArrivalTime: 27 Feb 2006 11:44:00.0673 (UTC) FILETIME=[19DC3110:01C63B93] Cc: canetti , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e Martin, On Feb 27, 2006, at 12:37 AM, Euchner, Martin wrote: > Dear MSECers, > > Following the call of the SAAG Security Area Directorate and the > general > advice giving by the MSEC WG chair, I've investigated the situation on > the security of hash functions in the context of MIKEY-DHHMAC. > I've added some new text to the MIKEY-DHHMAC security consideration > section where I provide considerations on the security of HMAC-SHA1 in > the context of DHHMAC and the formerly reported attacks on hash > functions. > > In particular; let me propose the following new paragraph to be > added to > the end of section 5.5 "Residual risk": > >>>> > HMAC-SHA1 is a key security mechanism within DHHMAC upon which the > overall security of MIKEY DHHMAC depends. MIKEY DHHMAC uses HMAC-SHA1 > in combination with the classic Diffie-Hellman key agreement scheme. > HMAC-SHA1 is a keyed one-way hash function that involves a secret > in its > computation. DHHMAC applies HMAC-SHA1 for protection of the MIKEY > payload. Likewise, the pseudo-random function PRF within MIKEY [3] > uses > the HMAC-SHA1 mechanism as a key derivation function. > While certain attacks have been reported against SHA1 and MD5 (see > [38]), with current knowledge (see [38], [39]), no collision attacks > have been reported against the HMAC-SHA1 security mechanism. here is a nit: in the above you should probably strike the word "collision", since HMAC is most likely used just as a MAC and a PRF. You might also want to cite the recent work http://eprint.iacr.org/ 2006/043 as evidence that HMAC can be a good PRF even when the underlying hash is not collision resistant. David > It is believed that MIKEY DHHMAC should be considered secure enough > for > the time being. Thus, there is no need to change the underlying > security > mechanism within the MIKEY DHHMAC protocol. > <<< > > Further, I've added the following two related references to the > section > 8.2 "Informative References": >>>> > [38] P. Hoffman, B. Schneier; "Attacks on Cryptographic Hashes in > Internet Protocols"; RFC 4270; IETF, November 2005. > > [39] S.M. Bellovin, E.K. Rescorla: "Deploying a New Hash Algorithm", > October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf > <<< > > I've also added a reference to MIKEY-RSA-r by replacing the reference > [15] (which is duplicate with [9] and has become RFC 4086 in the > meantime) with >>>> > [15] D. Ignjatic, L. Dondeti et al: "An additional mode of key > distribution > in MIKEY: MIKEY-RSA-R", Internet Draft, Work in Progress, > draft-ietf-msec-mikey-rsa-r-02, IETF, January 2006. > <<< > > Further, I've added reference to the MIKEY-ECC draft >>>> > [40] A. Milne et al: "ECC Algorithms For MIKEY", Internet Draft, > Work in > Progress, draft-ietf-msec-mikey-ecc-00, IETF, June 2005. > <<< > and by replacing the former statement in section 5.5 >>>Note, that an > elliptic-curve Diffie-Hellman variant of MIKEY remains for further > study.<<< by the new statement >>>> > Note, that elliptic-curve variants of MIKEY are defined in [40]. > <<< > > There are a few other, very minor typos and editorial corrections that > I've made to the -11 version since, which should not be worth > mentioning > here. > > Please let me know, if these proposed editorial changes are ok, and if > not how the new text should be modified. (No feedback means > acceptance). > > > FYI: draft-ietf-msec-mikey-dhhmac-11.txt is IESG approved and is > currently sitting in the RFC editors queue and is waiting there for > publication. However, DHHMAC is stuck from progress due to various > dependencies of other referenced normative draft RFC documents > which are > yet to enter the RFC editor's queue. > > > With kind regards > > Martin Euchner. > --------------------------------------------------------------------- > | Dipl.-Inf. > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | COM GCM PS 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > --------------------------------------------------------------------- > > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath > Dondeti > Sent: Donnerstag, 17. November 2005 02:40 > To: msec@securemulticast.org > Cc: canetti > Subject: [MSEC] SHA-1 replacement analyses for MSEC protocols > > At the SAAG meeting, Russ directed all SEC area WGs to analyze the > protocols they are working (worked) on and plan for SHA-1 > replacement. Here are the directives (1) and (2): > > "1.Do the Bellovin-Rescorla analysis before IETF 65 for each protocol > in the WG" > "2.Start standards work for transition to SHA-256, but remember > another transition is coming, so plan for it" > > MSEC has the following documents/protocols to analyze: > > GSAKMP > GDOI > MSEC-signatures > MIKEY related > TESLA > > Did I miss any? > > Our first request to everyone is to read the Belloving-Rescorla paper > (the relevant NIST and SAAG presentations materials should help as > well). Feel free to discuss the analysis method and your review of > that paper with other MSEC contributors. > > References: > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf > http://www.csrc.nist.gov/pki/HashWorkshop/2005/Oct31_Presentations/ > Bello > vin_new-hash.pdf > https://datatracker.ietf.org/public/meeting_materials.cgi? > meeting_num=64 > > (search for SAAG meeting materials) > > Next, if you are interested in analyzing any of the MSEC documents or > protocols, please contact Ran and me. Some of you have already done > so; thanks. > > We need to start work on this ASAP as we need to finish this work > before the March IETF meeting, **February 27, 2006 would be the -00- > deadline > > We'll post the protocol analysis assignments :-) toward the end of > next week. (Please hurry and volunteer). > > thanks and regards, > Lakshminath > > for > Ran & Lakshminath > > PS: Current document authors MUST do the analysis as part of their > next document revision. Thanks. > > _______________________________________________ > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Feb 27 09:28:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjMT-0005x1-Au for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 09:28:29 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjMS-0003zM-2b for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 09:28:29 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 9C7452C95D; Mon, 27 Feb 2006 09:28:27 -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 D4D392C870 for ; Mon, 27 Feb 2006 09:28:25 -0500 (EST) Received: (qmail 5106 invoked by uid 3269); 27 Feb 2006 14:28:25 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 5103 invoked from network); 27 Feb 2006 14:28:25 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Feb 2006 14:28:25 -0000 Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171]) by klesh.pair.com (Postfix) with ESMTP id CB97B68377 for ; Mon, 27 Feb 2006 09:28:25 -0500 (EST) Received: from 71-81-78-136.dhcp.stls.mo.charter.com ([71.81.78.136] helo=[192.168.30.38]) by outbound.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51) id 1FDjMP-000OR6-9B; Mon, 27 Feb 2006 09:28:25 -0500 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 71.81.78.136 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: digitalari Message-ID: <44030C7D.3060003@sipstation.com> Date: Mon, 27 Feb 2006 08:28:13 -0600 From: Alan Johnston User-Agent: Mozilla Thunderbird 1.0.7 (Macintosh/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: msec@securemulticast.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Philip Zimmermann Subject: [MSEC] draft-zimmermann-avt-zrtp-00.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 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 All, We have just submitted a new Internet-Draft draft-zimmermann-avt-zrtp-00.txt. Until it becomes available in the archives, you can get a copy at: http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.txt http://www.philzimmermann.com/zfone/draft-zimmermann-avt-zrtp-00.html We will request a slot in AVT in Dallas to discuss. Discussion about the RTP extensions and mechanism are best held on the AVT list while discussions about key management for SRTP are best held on the MMUSIC list, with some cross posting as needed. Apologies for the multiple postings. Thanks, Alan - - - ZRTP: Extensions to RTP for Diffie-Hellman Key Agreement for SRTP draft-zimmermann-avt-zrtp-00 Abstract This document defines ZRTP, RTP (Real-time Transport Protocol) header extensions for a Diffie-Hellman exchange to agree on a session key and parameters for establishing Secure RTP (SRTP) sessions. The ZRTP protocol is completely self-contained in RTP and does not require support in the signaling protocol or assume a Public Key Infrastructure (PKI) infrastructure. For the media session, ZRTP provides confidentiality and, in cases where a secret is available from the signaling protocol, authentication. _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec From msec-bounces@securemulticast.org Mon Feb 27 10:03:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FDjuT-0007vU-VK for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 10:03:37 -0500 Received: from six.pairlist.net ([209.68.2.254]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FDjuS-0005Xm-B4 for msec-archive@lists.ietf.org; Mon, 27 Feb 2006 10:03:37 -0500 Received: from six.pairlist.net (localhost [127.0.0.1]) by six.pairlist.net (Postfix) with ESMTP id 09EE22B89F; Mon, 27 Feb 2006 10:03:36 -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 C92CC2C84D for ; Mon, 27 Feb 2006 10:03:34 -0500 (EST) Received: (qmail 12524 invoked by uid 3269); 27 Feb 2006 15:03:34 -0000 Delivered-To: ietfsmug-securemulticast:org-msec@securemulticast.org Received: (qmail 12521 invoked from network); 27 Feb 2006 15:03:34 -0000 Received: from localhost.pair.com (HELO klesh.pair.com) (127.0.0.1) by localhost.pair.com with SMTP; 27 Feb 2006 15:03:34 -0000 Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by klesh.pair.com (Postfix) with ESMTP id 40DC66837D for ; Mon, 27 Feb 2006 10:03:34 -0500 (EST) Received: from mail2.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.12.6/8.12.6) with ESMTP id k1RF3RPG022556; Mon, 27 Feb 2006 16:03:27 +0100 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id k1RF3Rgi014768; Mon, 27 Feb 2006 16:03:27 +0100 Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Feb 2006 16:03:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [MSEC] Last minute edits in draft-ietf-msec-mikey-dhhmac-11.txt Date: Mon, 27 Feb 2006 16:03:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MSEC] Last minute edits in draft-ietf-msec-mikey-dhhmac-11.txt thread-index: AcY7kx1MX9I6b63LTAWr0Et+OPjJCwAF0z1Q From: "Euchner, Martin" To: "David McGrew" , "Euchner, Martin" X-OriginalArrivalTime: 27 Feb 2006 15:03:26.0838 (UTC) FILETIME=[F6401160:01C63BAE] Cc: canetti , 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 X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 David, many thanks for the hint. You're fully correct in that the "collision attacks" apply only in the context of SHA1 and/or MD5. I'm also happy to include M. Bellare's analysis [41] as a new informational bibliographic reference. I've corrected and amended the statement as follows: >>> ... While certain attacks have been reported against SHA1 and MD5 (see [38]), with current knowledge (see [38], [39]), no attacks have been reported against the HMAC-SHA1 security mechanism. In fact, [41] proves that HMAC possesses the property of a pseudo-random function PRF assuming solely that the (SHA1) hash function is a pseudo-random function. [41] provides also evidence that HMAC is robust against collision attacks on the underlying hash function. ... <<< Regards Martin here is a nit: in the above you should probably strike the word =20 "collision", since HMAC is most likely used just as a MAC and a PRF. =20 You might also want to cite the recent work http://eprint.iacr.org/=20 2006/043 as evidence that HMAC can be a good PRF even when the =20 underlying hash is not collision resistant. David > It is believed that MIKEY DHHMAC should be considered secure enough =20 > for > the time being. Thus, there is no need to change the underlying =20 > security > mechanism within the MIKEY DHHMAC protocol. > <<< > > Further, I've added the following two related references to the =20 > section > 8.2 "Informative References": >>>> > [38] P. Hoffman, B. Schneier; "Attacks on Cryptographic Hashes in > Internet Protocols"; RFC 4270; IETF, November 2005. > > [39] S.M. Bellovin, E.K. Rescorla: "Deploying a New Hash Algorithm", > October 2005, http://www.cs.columbia.edu/~smb/papers/new-hash.pdf > <<< > > I've also added a reference to MIKEY-RSA-r by replacing the reference > [15] (which is duplicate with [9] and has become RFC 4086 in the > meantime) with >>>> > [15] D. Ignjatic, L. Dondeti et al: "An additional mode of key > distribution > in MIKEY: MIKEY-RSA-R", Internet Draft, Work in Progress, > draft-ietf-msec-mikey-rsa-r-02, IETF, January 2006. > <<< > > Further, I've added reference to the MIKEY-ECC draft >>>> > [40] A. Milne et al: "ECC Algorithms For MIKEY", Internet Draft, =20 > Work in > Progress, draft-ietf-msec-mikey-ecc-00, IETF, June 2005. > <<< > and by replacing the former statement in section 5.5 >>>Note, that an > elliptic-curve Diffie-Hellman variant of MIKEY remains for further > study.<<< by the new statement >>>> > Note, that elliptic-curve variants of MIKEY are defined in [40]. > <<< > > There are a few other, very minor typos and editorial corrections that > I've made to the -11 version since, which should not be worth =20 > mentioning > here. > > Please let me know, if these proposed editorial changes are ok, and if > not how the new text should be modified. (No feedback means =20 > acceptance). > > > FYI: draft-ietf-msec-mikey-dhhmac-11.txt is IESG approved and is > currently sitting in the RFC editors queue and is waiting there for > publication. However, DHHMAC is stuck from progress due to various > dependencies of other referenced normative draft RFC documents =20 > which are > yet to enter the RFC editor's queue. > > > With kind regards > > Martin Euchner. > --------------------------------------------------------------------- > | Dipl.-Inf. > | Martin Euchner Phone: +49 89 722 55790 > | Siemens AG.....................Fax : +49 89 722 62366 > | COM GCM PS 3 mailto:Martin.Euchner@siemens.com > | mailto:martin.euchner@ties.itu.int > | Hofmannstr. 51 Intranet: > http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ > | D-81359 Muenchen Internet: http://www.siemens.de/ > | __________________ > | Germany > --------------------------------------------------------------------- > > -----Original Message----- > From: msec-bounces@securemulticast.org > [mailto:msec-bounces@securemulticast.org] On Behalf Of Lakshminath > Dondeti > Sent: Donnerstag, 17. November 2005 02:40 > To: msec@securemulticast.org > Cc: canetti > Subject: [MSEC] SHA-1 replacement analyses for MSEC protocols > > At the SAAG meeting, Russ directed all SEC area WGs to analyze the > protocols they are working (worked) on and plan for SHA-1 > replacement. Here are the directives (1) and (2): > > "1.Do the Bellovin-Rescorla analysis before IETF 65 for each protocol > in the WG" > "2.Start standards work for transition to SHA-256, but remember > another transition is coming, so plan for it" > > MSEC has the following documents/protocols to analyze: > > GSAKMP > GDOI > MSEC-signatures > MIKEY related > TESLA > > Did I miss any? > > Our first request to everyone is to read the Belloving-Rescorla paper > (the relevant NIST and SAAG presentations materials should help as > well). Feel free to discuss the analysis method and your review of > that paper with other MSEC contributors. > > References: > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf > http://www.csrc.nist.gov/pki/HashWorkshop/2005/Oct31_Presentations/=20 > Bello > vin_new-hash.pdf > https://datatracker.ietf.org/public/meeting_materials.cgi?=20 > meeting_num=3D64 > > (search for SAAG meeting materials) > > Next, if you are interested in analyzing any of the MSEC documents or > protocols, please contact Ran and me. Some of you have already done > so; thanks. > > We need to start work on this ASAP as we need to finish this work > before the March IETF meeting, **February 27, 2006 would be the -00- > deadline > > We'll post the protocol analysis assignments :-) toward the end of > next week. (Please hurry and volunteer). > > thanks and regards, > Lakshminath > > for > Ran & Lakshminath > > PS: Current document authors MUST do the analysis as part of their > next document revision. Thanks. > > _______________________________________________ > 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 _______________________________________________ msec mailing list msec@securemulticast.org http://six.pairlist.net/mailman/listinfo/msec