From turners@ieca.com Thu Jul 1 12:50:46 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B5443A66B4 for ; Thu, 1 Jul 2010 12:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=0.619, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5+3BoVwciT2 for ; Thu, 1 Jul 2010 12:50:35 -0700 (PDT) Received: from smtp113.biz.mail.re2.yahoo.com (smtp113.biz.mail.re2.yahoo.com [66.196.116.98]) by core3.amsl.com (Postfix) with SMTP id 182293A67ED for ; Thu, 1 Jul 2010 12:50:34 -0700 (PDT) Received: (qmail 64950 invoked from network); 1 Jul 2010 19:50:43 -0000 Received: from thunderfish.local (turners@71.191.5.145 with plain) by smtp113.biz.mail.re2.yahoo.com with SMTP; 01 Jul 2010 12:50:43 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: H2Got88VM1kUAhAt7PlNy1VUwz5WZUb6ZzCg1.nWipGtf1T X6g93M26UPgXgFBtcmHNk.qGmc8YgJoyglDGB9ZIlpzwbjXJCW2rfEVsWiiP AsapjdtYf8oI3eRHScs0sLprUgT5vCQVqmMId1dAbed4mShDN4glqyyWgpvD 0g393csBt4NKeVqold.Nb9NvIG2HFYA1FGgs33YXQG_YpmnoVQ6slb5d_GFG J055oK1lcC1scHd0uisdqs9ZDdYyaMKQHS6kVWqhCQRRxlf6Bdv4T7Fj8FvR fhM_rwchozPhG1Ywpx21dJDy2afUnpLd4Ix.X7l_SUWY6U9QXJuSrvFHsNo9 dXNhpoegEBZ.F1zTJfR2DdsdREhdON0Fyahk80IquuExwbhX1EHOvhjHrtnW gAGMBDBCvx4fQLZBH0xt5E6iRtmmPIz_CuUeWXyZZPQwmIMIm2nl56A-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C2CF192.9010509@ieca.com> Date: Thu, 01 Jul 2010 15:50:42 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Yaron Sheffer References: <4C251BBE.1060908@gmail.com> <4C2A2BD0.2010505@ieca.com> In-Reply-To: <4C2A2BD0.2010505@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Comments on draft-turner-ssl-must-not-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:50:46 -0000 >> - The draft should talk a bit about deployment considerations, not >> just security. During the RI episode, there were numbers mentioned >> (published?) about the prevalence of different protocol versions. This >> is certainly relevant to the current discussion, and readers would >> benefit from having these statistics included. I'll dig up the emails and include a reference to the statistics. >> - Speaking about which, I'm surprised the draft does not mention that >> support of RFC 5746 (RI) is mandatory. After all this one has a >> practical exploit, which I'm not sure is the case for other security >> issues mentioned here. A glaring oversight on my part. >> - The reference to the original Netscape spec is kind of useless. >> Please also mention that it was published as an I-D, still available >> at http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00. >> I'll point to this I-D instead. >> - The document provides some motivation on why TLS 1.1 is a SHOULD. >> However it RECOMMENDS TLS 1.2 (which today is very rarely implemented, >> AFAIK) and does not provide any motivation for that. I would say the >> document as written only supports a statement like "use of TLS 1.1 or >> higher is RECOMMENDED." I was thinking that we really need to be recommending the latest and greatest. I mean it was developed for a reason right? Based on Nikos these recommendations will probably get tweaked. spt From yaronf.ietf@gmail.com Fri Jul 2 02:00:52 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C423A693E for ; Fri, 2 Jul 2010 02:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGua5dtYj0Oh for ; Fri, 2 Jul 2010 02:00:51 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id B155C3A689C for ; Fri, 2 Jul 2010 02:00:50 -0700 (PDT) Received: by wwb24 with SMTP id 24so295763wwb.13 for ; Fri, 02 Jul 2010 02:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=iH1sR7iZolQxb0x97nxsQsFTjlg+BAZSrE6Uz42ZShg=; b=o2ndl7Oi4hBCPpIiC4mAzqs2S8t5rmgfut0/EpXFLpd1pVOURPvJNT5hIDSoNhw1FY aOR9HPLw08UizKK8h3rEPYKjwBzWG68kCR7/BFD4RxpRfyZ4tORSEIZ0nos5praiElF5 2B9DDqxLXjWqLojQ3BzNnMREAYm8YFqgRXnoA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=gw7w/b1ONscnQcG2AhAq6GNZfiZ125W8AGNyUQKm2zaIkMDH82sv4Etsy8iDyjE+kH kyJbI/Ar8XT0vcKpqAcwhQRaZPH1AmH8eIuByG+6xARH1GkPQ4jRZpoA2fhZIW4eBjwO u+LKZUBj7mowwTvZfXpBFSiGHs7GUIYqOA3oA= Received: by 10.227.72.213 with SMTP id n21mr234376wbj.186.1278061259171; Fri, 02 Jul 2010 02:00:59 -0700 (PDT) Received: from [10.0.0.1] ([109.67.47.233]) by mx.google.com with ESMTPS id i25sm3067387wbi.16.2010.07.02.02.00.56 (version=SSLv3 cipher=RC4-MD5); Fri, 02 Jul 2010 02:00:57 -0700 (PDT) Message-ID: <4C2DAAC6.3040009@gmail.com> Date: Fri, 02 Jul 2010 12:00:54 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: Sean Turner References: <4C251BBE.1060908@gmail.com> <4C2A2BD0.2010505@ieca.com> <4C2CF192.9010509@ieca.com> In-Reply-To: <4C2CF192.9010509@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Comments on draft-turner-ssl-must-not-01 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jul 2010 09:00:52 -0000 Hi Sean, we should be "recommending" the latest and greatest. But when we are "RECOMMENDING" (all caps), it's really a RFC 2119 SHOULD, and we need stronger justification than the draft being nice and shiny. Thanks, Yaron On 07/01/2010 10:50 PM, Sean Turner wrote: >>> - The draft should talk a bit about deployment considerations, not >>> just security. During the RI episode, there were numbers mentioned >>> (published?) about the prevalence of different protocol versions. >>> This is certainly relevant to the current discussion, and readers >>> would benefit from having these statistics included. > > I'll dig up the emails and include a reference to the statistics. > >>> - Speaking about which, I'm surprised the draft does not mention that >>> support of RFC 5746 (RI) is mandatory. After all this one has a >>> practical exploit, which I'm not sure is the case for other security >>> issues mentioned here. > > A glaring oversight on my part. > >>> - The reference to the original Netscape spec is kind of useless. >>> Please also mention that it was published as an I-D, still available >>> at http://tools.ietf.org/html/draft-ietf-tls-ssl-version3-00. >>> > > I'll point to this I-D instead. > >>> - The document provides some motivation on why TLS 1.1 is a SHOULD. >>> However it RECOMMENDS TLS 1.2 (which today is very rarely >>> implemented, AFAIK) and does not provide any motivation for that. I >>> would say the document as written only supports a statement like "use >>> of TLS 1.1 or higher is RECOMMENDED." > > I was thinking that we really need to be recommending the latest and > greatest. I mean it was developed for a reason right? Based on Nikos > these recommendations will probably get tweaked. > > spt From turners@ieca.com Tue Jul 6 09:40:24 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D1393A6878 for ; Tue, 6 Jul 2010 09:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.664 X-Spam-Level: X-Spam-Status: No, score=-1.664 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdMhfvMufpxh for ; Tue, 6 Jul 2010 09:40:23 -0700 (PDT) Received: from smtp115.biz.mail.sp1.yahoo.com (smtp115.biz.mail.sp1.yahoo.com [69.147.92.217]) by core3.amsl.com (Postfix) with SMTP id 8A6893A698C for ; Tue, 6 Jul 2010 09:40:23 -0700 (PDT) Received: (qmail 61567 invoked from network); 6 Jul 2010 16:40:23 -0000 Received: from thunderfish.local (turners@96.231.127.211 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 06 Jul 2010 09:40:22 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: H3XKEykVM1kss_AyRW.edWyeUo7GVWYhf7nntHLeebAp2qd SckNwoFk_gLvtox_VSvAOGegHKo6QuMgZ87oezt.JJwA6VLZjAqm8HoiIEDH hE9zAxgnShLHbwmzQ05ZNKjbK7g0o0bk.QDPKTrE3Aes543LgSipQ5QuyN8B chWObWug3xUlfgYEDOySRx5PKGSwgEwe36pPF_4Swfjk47qa.IMMjq2IW_Lh Z_sNCdG8tGMK8Jjs3EPVc4YpH1dSVOmNSwIaGsvvfb9R.MjtwbpeokhZhZBH rDAf0h_nW2YgXC4BPpWI4vXc1RsvfNZt7iO0awwC8K65a_tFqSXPwgA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C335C75.7070508@ieca.com> Date: Tue, 06 Jul 2010 12:40:21 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org, smime@ietf.org, pkix@ietf.org, cfrg@irtf.org References: <4C10E308.9060503@ieca.com> In-Reply-To: <4C10E308.9060503@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jul 2010 16:40:24 -0000 To summarize the comments I received on this I-D: 1) Finally! 2) Is there any precedent with moving informational to historic. Russ suggested I ask Scott Bradner what he thought about this. His response (repeated here with permission): "1/ my personal view is that historic should be only used for cases where we want to say 'do not use' 2/ seems like a reasonable thing to do in this case fwiw, I have always felt that it is important to document any such move that is done for a real reason (not just because people think it is not used) with a RFC" I'd consider this support for moving informational RFCs to historic. 3) Why target MD2? This was really a trial balloon. I'm planning on doing something with MD4 and MD5 too ;) 4) It's better to have a security algorithms roadmap. I tend to agree, but I thought I was shooting for the low hanging fruit. 5) Remove keywords and delete obsolete references. Anything to track less references is a good thing! 6) Do an updates document instead, because there might still be other uses for MD2/MD4/MD5 that don't require collision resistance (e.g., HMAC). I'd like to treat MD2/MD4/MD5 the same, but some HMAC uses are probably still okay for a little while (at least that what's I'm turning up through research). But, I can't really see us saying that HAMC-MD2 and HMAC-MD4 are okay to keep using in the mid/long term. I think we ought to be saying "jump off the sinking ship now" because it takes a while for crypto to go away just like it does to get fielded. Luckily, there are only a few places where HMAC-MD2 or HMAC-MD4 are specified. MD5/HMAC-MD5 is another story. I like the idea of just updating MD5's security considerations to say don't use MD5 if you need collision resistance and that it is (or is probably) okay for HMAC. I updated the md2-to-historic I-D (http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/) to actually talk about attacks against MD2 and submitted a similar draft for MD4 (http://datatracker.ietf.org/doc/draft-turner-md4-to-historic/). I also submitted one that updates the MD5 security considerations (http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/). Comments on all are welcome. spt Sean Turner wrote: > (apologies if you get this multiple times) > > I'm looking for feedback on this draft that proposes moving MD2 to > historic status. > > Thanks, > > spt > > ------------------------------------------------------------------------ > > Subject: > I-D ACTION:draft-turner-md2-to-historic-00.txt > From: > Internet-Drafts@ietf.org > Date: > Wed, 9 Jun 2010 15:00:02 -0700 (PDT) > To: > i-d-announce@ietf.org > > To: > i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : MD2 to Historic Status > Author(s) : S. Turner > Filename : draft-turner-md2-to-historic-00.txt > Pages : 6 > Date : 2010-6-8 > > This document recommends the retirement of MD2 and discusses the > reasons for doing so. This document recommends RFC 1319 be moved to > Historic status. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > 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@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From SChokhani@cygnacom.com Wed Jul 7 10:17:17 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 478F63A6887; Wed, 7 Jul 2010 10:17:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq7sQU1v2YKU; Wed, 7 Jul 2010 10:17:15 -0700 (PDT) Received: from mail166.messagelabs.com (mail166.messagelabs.com [216.82.253.163]) by core3.amsl.com (Postfix) with SMTP id 4462B3A685B; Wed, 7 Jul 2010 10:17:14 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: SChokhani@cygnacom.com X-Msg-Ref: server-3.tower-166.messagelabs.com!1278523034!27516574!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.25] Received: (qmail 12968 invoked from network); 7 Jul 2010 17:17:15 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.25) by server-3.tower-166.messagelabs.com with SMTP; 7 Jul 2010 17:17:15 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 7 Jul 2010 13:17:14 -0400 Message-ID: In-Reply-To: <4C335C75.7070508@ieca.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] Thread-Index: AcsdKfgzqsB/uxx1TUS1IAJUwQMjagArsSqw References: <4C10E308.9060503@ieca.com> <4C335C75.7070508@ieca.com> From: "Santosh Chokhani" To: "Sean Turner" , , , , Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic-00.txt] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 17:17:17 -0000 Sean, It may be worth discussing DSSC (RFC 5698) from LTANS WG that provides a capability to specify suitable crypto algorithms. > -----Original Message----- > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of > Sean Turner > Sent: Tuesday, July 06, 2010 12:40 PM > To: saag@ietf.org; smime@ietf.org; pkix@ietf.org; cfrg@irtf.org > Subject: Re: [saag] [Fwd: I-D ACTION:draft-turner-md2-to-historic- > 00.txt] >=20 > To summarize the comments I received on this I-D: >=20 > 1) Finally! >=20 > 2) Is there any precedent with moving informational to historic. >=20 > Russ suggested I ask Scott Bradner what he thought about this. His > response (repeated here with permission): >=20 > "1/ my personal view is that historic should be only used for > cases where we want to say 'do not use' >=20 > 2/ seems like a reasonable thing to do in this case >=20 > fwiw, I have always felt that it is important to document > any such move that is done for a real reason (not just because > people think it is not used) with a RFC" >=20 > I'd consider this support for moving informational RFCs to historic. >=20 > 3) Why target MD2? >=20 > This was really a trial balloon. I'm planning on doing something with > MD4 and MD5 too ;) >=20 > 4) It's better to have a security algorithms roadmap. >=20 > I tend to agree, but I thought I was shooting for the low hanging > fruit. >=20 > 5) Remove keywords and delete obsolete references. >=20 > Anything to track less references is a good thing! >=20 > 6) Do an updates document instead, because there might still be other > uses for MD2/MD4/MD5 that don't require collision resistance (e.g., > HMAC). >=20 > I'd like to treat MD2/MD4/MD5 the same, but some HMAC uses are > probably still okay for a little while (at least that what's I'm > turning up through research). But, I can't really see us saying that > HAMC-MD2 and HMAC-MD4 are okay to keep using in the mid/long term. I > think we ought to be saying "jump off the sinking ship now" because it > takes a while for crypto to go away just like it does to get fielded. > Luckily, there are only a few places where HMAC-MD2 or HMAC-MD4 are > specified. MD5/HMAC-MD5 is another story. I like the idea of just > updating MD5's security considerations to say don't use MD5 if you > need collision resistance and that it is (or is probably) okay for > HMAC. >=20 > I updated the md2-to-historic I-D > (http://datatracker.ietf.org/doc/draft-turner-md2-to-historic/) to > actually talk about attacks against MD2 and submitted a similar draft > for MD4 (http://datatracker.ietf.org/doc/draft-turner-md4-to- > historic/). > I also submitted one that updates the MD5 security considerations > (http://datatracker.ietf.org/doc/draft-turner-md5-seccon-update/). > Comments on all are welcome. >=20 > spt >=20 > Sean Turner wrote: > > (apologies if you get this multiple times) > > > > I'm looking for feedback on this draft that proposes moving MD2 to > > historic status. > > > > Thanks, > > > > spt > > > > --------------------------------------------------------------------- > --- > > > > Subject: > > I-D ACTION:draft-turner-md2-to-historic-00.txt > > From: > > Internet-Drafts@ietf.org > > Date: > > Wed, 9 Jun 2010 15:00:02 -0700 (PDT) > > To: > > i-d-announce@ietf.org > > > > To: > > i-d-announce@ietf.org > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : MD2 to Historic Status > > Author(s) : S. Turner > > Filename : draft-turner-md2-to-historic-00.txt > > Pages : 6 > > Date : 2010-6-8 > > > > This document recommends the retirement of MD2 and discusses the > > reasons for doing so. This document recommends RFC 1319 be moved > to > > Historic status. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-turner-md2-to-historic- > 00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > 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@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From hartmans@mit.edu Wed Jul 7 10:58:45 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FFA3A6838 for ; Wed, 7 Jul 2010 10:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvsOWF1mbsS0 for ; Wed, 7 Jul 2010 10:58:45 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 07B713A67E5 for ; Wed, 7 Jul 2010 10:58:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B4F77203C7; Wed, 7 Jul 2010 13:58:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8144440D4; Wed, 7 Jul 2010 13:58:38 -0400 (EDT) From: Sam Hartman To: "Sean Turner" , , ietf-krb-wg@anl.gov, cfrg@irtf.org References: <4C10E308.9060503@ieca.com> <4C335C75.7070508@ieca.com> Date: Wed, 07 Jul 2010 13:58:38 -0400 In-Reply-To: (Santosh Chokhani's message of "Wed, 7 Jul 2010 13:17:14 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [saag] draft-turner-md4-to-historic and Microsoft use of Md4 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jul 2010 17:58:45 -0000 Sean, I've mentioned this in private mail, but I believe your draft should discuss the Microsoft uses of md4 particularly for converting passwords to key and discuss the impact of attacks on this use before it is published. I am not intending to imply you're ignoring my comment: it was made recently. I just wanted to get it into the public discussion so others could think about it. It's not entirely clear what properties are desired of a cryptographic function in these uses. In the Kerberos string-to-key operation, I think there are at least two goals: 1) Take a password of sufficient quality and produce a good key 2) Make it difficult to recover the password given the key. There may be other goals. This is an area where the Kerberos community has struggled to come up with security requirements. It's clear that md4 fails at the second goal. However, it's not clear that the Microsoft protocol uses of md4 actually try to achieve this goal. In the case of Kerberos, one of the main reasons you want to prevent recovery of the password is so you can use the same password in different realms without exposing it. For this reason, an identifier of the principal and realm is included in the key computation. However, rc4-hmac-md5 (the Kerberos enctype that uses md4 for string2key) explicitly does not produce different keys for different realms. So, I'm not actually sure whether one-way is a security goal or not for this use of md4. I have not been able to determine the impact of attacks on md4 on its use as a funtion to produce high-quality keys from high-quality passwords. In conclusion, I think we need to be able to tell people what the impact of the attacks on md4 is on widely deployed uses before publishing. From Hannes.Tschofenig@gmx.net Thu Jul 8 00:16:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32BB3A67E9 for ; Thu, 8 Jul 2010 00:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.025 X-Spam-Level: X-Spam-Status: No, score=-1.025 tagged_above=-999 required=5 tests=[AWL=1.574, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gJ2IxpgtdQU for ; Thu, 8 Jul 2010 00:16:50 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 63F943A6359 for ; Thu, 8 Jul 2010 00:16:50 -0700 (PDT) Received: (qmail 25910 invoked by uid 0); 8 Jul 2010 07:16:53 -0000 Received: from 213.162.68.169 by www095.gmx.net with HTTP; Thu, 08 Jul 2010 09:16:50 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Thu, 08 Jul 2010 09:16:50 +0200 From: "Hannes Tschofenig" Message-ID: <20100708071650.159820@gmx.net> MIME-Version: 1.0 To: saag@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19KIphiKVxKDh4SHU+vAmV9v+Hd6rzb9ZDxFQPmLA NeqZbvNWe632oN5m9fuFSPQs6dQ1Bm1vLXRg== Content-Transfer-Encoding: 8bit X-GMX-UID: UEIGdFsKMmA6V5gPqWBnedM5MjQ1N10g X-FuHaFi: 0.63 Subject: [saag] HASMAT BOF Preparation: Conference Call and Video X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 07:16:51 -0000 Hi all, I would like to remind you about the upcoming BOF on HTTP Application Security Minus Authentication and Transport (HASMAT). For those who have not closely followed the topic we will have a pre-BOF conference call next week (Wed 14-Jul, 9am PDT). My announcement of the conference call can be found here: http://www.ietf.org/mail-archive/web/hasmat/current/msg00031.html. Webex details will follow. Finally, Jeff Hodges gave a presentation about the HTTPS security policy work he is doing at the 10th Internet Identity Workshop (IIWX). The recording can be found here: http://idcoach.blip.tv/file/3650497 Ciao Hannes PS: The mailing list can be found here (https://www.ietf.org/mailman/listinfo/hasmat) and the charter text writeup is here (http://www.ietf.org/mail-archive/web/hasmat/current/msg00000.html). From turners@ieca.com Thu Jul 8 06:25:01 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C5353A6AB3 for ; Thu, 8 Jul 2010 06:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.38 X-Spam-Level: X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[AWL=1.218, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jX39i5kIUcD4 for ; Thu, 8 Jul 2010 06:25:00 -0700 (PDT) Received: from smtp114.biz.mail.mud.yahoo.com (smtp114.biz.mail.mud.yahoo.com [209.191.68.79]) by core3.amsl.com (Postfix) with SMTP id BAE4C3A6A0C for ; Thu, 8 Jul 2010 06:25:00 -0700 (PDT) Received: (qmail 92130 invoked from network); 8 Jul 2010 13:24:57 -0000 Received: from thunderfish.local (turners@96.231.124.229 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 08 Jul 2010 06:24:57 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: adPwcb8VM1mCjMKeNqcJyn5DimUcdkU6QZQgo2rSrsNDJ3D EJ6RF0WEmk_zThzLcgy3b0GPAKLfWE6XBcozbJMGn81fMCjnQPpZvmZDQ3K0 6TnH5rFg8legdEtJ6CZbluKpTZMn01ZlPm14OCXtN8w46.vKF76MKgnxAA8f HZCqTZ46m76IRFnbtWxcy_BJ8TJJhgWtf.f94XHoPI37_De_ukzZx059V13s FhEStlqKKJDTx.JsxjYLfWprDM8x6vpl5Ac8seim78vOUGpin4TuGd.FMgLC ZpZq0ltgin8HY30ay_8fB7V8- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C35D1A8.3090401@ieca.com> Date: Thu, 08 Jul 2010 09:24:56 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4C10E308.9060503@ieca.com> <4C335C75.7070508@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ietf-krb-wg@anl.gov, cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] draft-turner-md4-to-historic and Microsoft use of Md4 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jul 2010 13:25:01 -0000 Sam, Definitely not ignoring the comment. I just wanted to get the -00 version out before the deadline. I haven't heard back from the folks I queried about this topic. At least one person has suggested that we can't change this status of this I-D (or the MD2 I-D) because it probably came via the independent stream (i.e., RSA was just publishing an open publication of proprietary specifications). They suggested it might be better to just update the security considerations and not try to move it to historic. Any thoughts? spt Sam Hartman wrote: > > Sean, I've mentioned this in private mail, but I believe your draft > should discuss the Microsoft uses of md4 particularly for converting > passwords to key and discuss the impact of attacks on this use before it > is published. I am not intending to imply you're ignoring my comment: it > was made recently. I just wanted to get it into the public discussion so > others could think about it. > > It's not entirely clear what properties are desired of a cryptographic > function in these uses. > > In the Kerberos string-to-key operation, I think there are at least two > goals: > > 1) Take a password of sufficient quality and produce a good key > > 2) Make it difficult to recover the password given the key. > > There may be other goals. This is an area where the Kerberos community > has struggled to come up with security requirements. > > It's clear that md4 fails at the second goal. However, it's not clear > that the Microsoft protocol uses of md4 actually try to achieve this > goal. In the case of Kerberos, one of the main reasons you want to > prevent recovery of the password is so you can use the same password in > different realms without exposing it. For this reason, an identifier of > the principal and realm is included in the key computation. However, > rc4-hmac-md5 (the Kerberos enctype that uses md4 for string2key) > explicitly does not produce different keys for different realms. > > So, I'm not actually sure whether one-way is a security goal or not for > this use of md4. > > I have not been able to determine the impact of attacks on md4 on its > use as a funtion to produce high-quality keys from high-quality > passwords. > > In conclusion, I think we need to be able to tell people what the impact > of the attacks on md4 is on widely deployed uses before publishing. > From hannes.tschofenig@nsn.com Mon Jul 12 09:35:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EB1E3A6B95 for ; Mon, 12 Jul 2010 09:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xni5dXy9vprb for ; Mon, 12 Jul 2010 09:35:52 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 9372B3A6B35 for ; Mon, 12 Jul 2010 09:35:47 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6CGZrWl025394 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Jul 2010 18:35:53 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6CGZqwo025044 for ; Mon, 12 Jul 2010 18:35:53 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:35:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 19:36:23 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502CB8A0C@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF Thread-Index: AcsevKYjQSWbt2Q4T2KKNdywuVACVADIwiNQAAAo91A= From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Jul 2010 16:35:49.0538 (UTC) FILETIME=[493DF820:01CB21E0] Subject: [saag] FW: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:35:59 -0000 FYI >-----Original Message----- >From: hasmat-bounces@ietf.org [mailto:hasmat-bounces@ietf.org] On=20 >Behalf Of ext Peter Saint-Andre >Sent: 08 July, 2010 19:43 >To: hasmat@ietf.org >Subject: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF > >Here is the invite for the HASMAT call next week. > > >-------- Original Message -------- > > >Topic: HASMAT Pre-BoF >Date: Wednesday, July 14, 2010 >Time: 10:00 am, Mountain Daylight Time (Denver, GMT-06:00) Meeting=20 >Number: 491 333 963 Meeting Password: Maastricht > > >------------------------------------------------------- >To join the online meeting (Now from iPhones and other Smartphones=20 >too!) >------------------------------------------------------- >1. Go to >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&PW=3DNZTJmMzAwN2Vi&RT=3DMiM2 >3&PW=3DNZTJmMzAwN2Vi&RT=3DMiM2> > >2. If requested, enter your name and email address. >3. If a password is required, enter the meeting password:=20 >Maastricht 4. Click "Join". > >To view in other time zones or languages, please click the link: >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&PW=3DNZTJmMzAwN2Vi&ORT=3DMiM2 >3&PW=3DNZTJmMzAwN2Vi&ORT=3DMiM2> > > >------------------------------------------------------- >To join the audio conference only >------------------------------------------------------- >To receive a call back, provide your phone number when you join the=20 >meeting, or call the number below and enter the access code. >Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in toll=20 >number (US/Canada): 1-650-429-3300 Toll-free dialing restrictions: >http://www.webex.com/pdf/tollfree_restrictions.pdf > >Access code:491 333 963 > >------------------------------------------------------- >For assistance >------------------------------------------------------- >1. Go to https://welcome.webex.com/welcome/mc >2. On the left navigation bar, click "Support". > >You can contact me at: >peter.saintandre@webex.com > > >To add this meeting to your calendar program (for example Microsoft=20 >Outlook), click this link: >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA7RiflXMUsxxeuzlSryX1K54530qKYRqae= P >SJ66NPZI=3D&RT=3DMiM2 >3&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA7RiflXMUsxxeuzlSryX1K54530qKYRqa= e >PSJ66NPZI=3D&RT=3DMiM2> > > >The playback of UCF (Universal Communications Format) rich media files=20 >requires appropriate players. To view this type of rich media files in=20 >the meeting, please check whether you have the players installed on=20 >your computer by going to=20 >https://welcome.webex.com/welcome/systemdiagnosis.php > > > > >http://www.webex.com >We've got to start meeting like this(TM) > >CCP:+16504293300x491333963# > >IMPORTANT NOTICE: This WebEx service includes a feature that allows=20 >audio and any documents and other materials exchanged or viewed during=20 >the session to be recorded. By joining this session, you automatically=20 >consent to such recordings. If you do not consent to the recording, do=20 >not join the session. >_______________________________________________ >HASMAT mailing list >HASMAT@ietf.org >https://www.ietf.org/mailman/listinfo/hasmat > From turners@ieca.com Tue Jul 13 07:49:01 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A0F13A693A for ; Tue, 13 Jul 2010 07:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.949 X-Spam-Level: X-Spam-Status: No, score=-0.949 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_40=-0.185, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xp8C3-VmZpgb for ; Tue, 13 Jul 2010 07:49:00 -0700 (PDT) Received: from smtp115.biz.mail.mud.yahoo.com (smtp115.biz.mail.mud.yahoo.com [209.191.68.75]) by core3.amsl.com (Postfix) with SMTP id 245C03A6899 for ; Tue, 13 Jul 2010 07:49:00 -0700 (PDT) Received: (qmail 8199 invoked from network); 13 Jul 2010 14:49:03 -0000 Received: from thunderfish.local (turners@96.241.2.232 with plain) by smtp115.biz.mail.mud.yahoo.com with SMTP; 13 Jul 2010 07:49:03 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: 6FD4vegVM1k.bxAYl4ZKhtP.WfblM6uibX.xeNBxExebraD 1X08VTYL9jrtzER9n3Y6MrF23xFepN0swjKaRC1xu9z7FAklAXAfYFRJGAjR TLpZML6va9Y0Nw.l3aVwklco8iZcvnkYORo5VJG3m4kdDm4LkzVh6N9_yCnl 5G0zt50uAlbfB.LDuUsDYtJDwTLWnXwQrcPkDksT35ztXgUjhkBJ49UaWOBk 0vCjbrkMtmDDtRkfgtXkSQWeKtpDrBTXSeYGSVtrY8WwYq_4rO4PQmFQdxzC gW29p9cEcElPORoPHyeG8uJ2I9SrlSO7C0c1fpwwkWG3.y1KDSChnAw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C3C7CDE.9090203@ieca.com> Date: Tue, 13 Jul 2010 10:49:02 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Sean's AD Notes for 2010-07 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 14:49:01 -0000 These notes are identical (minus the wiki links) to those posted on:http://trac.tools.ietf.org/area/sec/trac/wiki/SeansMonthlyUpdate. Note that there's also a blog with an RSS feed at: http://trac.tools.ietf.org/area/sec/trac/blog = Sean Turner's Monthly AD Notes - 2010-07-13 = Here's my monthly AD notes. It's a short status update about what things are going on from my point-of-view. If you notice anything that doesn't look right, let me know -- miscommunication and mix-ups do happen. == MISC NOTES == * IETF 78 planning continued with Tim: SAAG presentations. Agenda posted: http://www.ietf.org/proceedings/78/agenda/saag.txt * Participated in weekly calls with Tim. * Tim and I continue to be slack wrt errata. == WORKING GROUPS == === DKIM === * Revised charter approved. * draft-ietf-dkim-mailinglists. First version posted. * Errata 1532 and 1596: Awaiting WG chairs proposal for new text and recommended status. 2010-05-05. === EMU === * draft-ietf-emu-eaptunnel-req: Completed WG LC. Waiting for proto write-up. * Lots of channel bindings. * draft-ietf-emu-chbind: Version -05 published. === IPSECME === * PAKE: Work dropped from WG. I'll AD-sponsor the individual drafts. * draft-ietf-ipsecme-aes-ctr-ikev2: In the RFC editor's queue. * draft-ietf-ipsecme-ikev2bis: In the RFC editor's queue. * draft-ietf-ipsecme-roadmap: Issued and passed through IETF LC. GEN-ART comments received (new version likely needed). Placed on 2010-08-12 telechat. * draft-ietf-ipsecme-ipsec-ha: Issued and passed through IETF LC. Discussed on 2010-07-01 telechat. IPR statement submitted the morning of telechat. Further discussion was deferred to 2010-07-15 while IPR statement was reviewed by WG. WG Chairs reviewed the IPR statement and do not believe it should prevent the HA problem statement or the solutions work from progressing. http://www.ietf.org/mail-archive/web/ipsec/current/msg06400.html * draft-ietf-ipsecme-eap-mutual: In RFC editor's queue. * HA design team started their work. * Kicking off Failure Detection Proposals. === ISMS === * draft-ietf-isms-dtls-tm: In RFC editor's queue. * draft-ietf-isms-radius-vacm: Final last called issued on 2010-07-06 ends 2010-07-13. This is after the submission deadline for IETF 78 so the plan is to submit it when the submission window reopens. Expecting to issue IETF LC in early August. === KEYPROV === (I know it's Tim's but I am following it closely) * draft-ietf-keyprov-dskpp: Dealing with IESG DISCUSS positions. 2nd IETF LC passed to address DOWNREF. * draft-ietf-keyprov-pskc: Dealing with IESG DISCUSS positions. 2nd IETF LC passed to address DOWNREF. * draft-ietf-keyprov-symmetrickeyformat: Dealing with IESG DISCUSS positions. === SASL === * SASL/KITTEN merge progressing. * RFC5801 (was draft-ietf-sasl-gs2) published. * RFC5802 (was draft-ietf-sasl-scram) published. * (not WG item): RFC5929 (was draft-altman-tls-channel-bindings). === SYSLOG === * draft-ietf-syslog-dtls: IESG DISCUSS positions resolved. Now in RFC editor's queue. * Though all of the WG's work items are approved, the WG not be closed until the syslog-dtls I-Ds is actually published. === TLS === * draft-ietf-tls-rfc4366-bis: Revised. Issued Second IETF LC. Assuming it goes well, I will add it to the 2010-08-12 IESG telechat. * draft-ietf-tls-cached-info: Revised. I'm hoping for WG LC in August. * draft-ietf-tls-heartbeat: First draft posted. * draft-ietf-tls-rfc4347-bis-04. Revised draft posted. Note that a couple of people asked about this I-D. == OTHER DOCUMENTS == * draft-hoffman-tls-master-secret-input: Discussed on 2010-07-01 IESG telechat. Some comments received and addressed. Waiting for an AD to clear. * BTW - I've currently got about 13 (or maybe 14) requests to AD-sponsor I-Ds. At least 7 are I-Ds for cipher suites. == DISCUSSES == As an AD, the more DISCUSS positions you enter the more work you have to do (information for all those would be ADs). * draft-cheshire-dnsext-nbp: I picked up part of Pasi's DISCUSS and Russ picked up the rest. 2010-04-08. * draft-ietf-csi-hash-threat: A new draft! I need to review. 2010-07-13. * draft-denenberg-mods-etc-media-types-02: Awaiting response from authors. 2010-04-29. This one will probably be pinned for a while waiting for OASIS to stabilize a draft. * draft-ietf-sipping-config-framework: Waiting for revised I-D. 2010-04-22. * draft-ietf-avt-register-srtp-02: Waiting for revised I-D. 2010-05-06. * draft-ietf-avt-rtp-ipmr-12: Waiting for revised I-D. 2010-05-06. * draft-ietf-mext-flow-binding-06: Waiting for revised I-D. 2010-05-06. * draft-ietf-6lowpan-routing-requirements-06: Waiting for revised I-D. 2010-05-20. * draft-ietf-hip-hiccups-05: Waiting for revised I-D. 2010-06-02. * draft-ietf-sip-certs-14: This one is on me. I need to provide some mother-hood-and-apple-pie text on keeping the private key private. Was looking for text to use, but think I might need to do it from scratch. 2010-06-17. * draft-c1222-transport-over-ip-04: Need to review latest version. I'm still concerned that I don't have the ANSI draft that described the security and whether the AES-EAX mode has been reviwwed by the CFRG. 2010-07-09. From turners@ieca.com Tue Jul 20 14:31:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAFF3A6892 for ; Tue, 20 Jul 2010 14:31:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.17 X-Spam-Level: X-Spam-Status: No, score=-2.17 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVBHAVNHtPd8 for ; Tue, 20 Jul 2010 14:30:59 -0700 (PDT) Received: from smtp113.biz.mail.sp1.yahoo.com (smtp113.biz.mail.sp1.yahoo.com [69.147.92.226]) by core3.amsl.com (Postfix) with SMTP id 7AB143A67EF for ; Tue, 20 Jul 2010 14:30:47 -0700 (PDT) Received: (qmail 72572 invoked from network); 20 Jul 2010 21:30:57 -0000 Received: from thunderfish.local (turners@96.231.116.83 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 20 Jul 2010 14:30:56 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: vBfgM9kVM1nnbBqyLsOCEaRtE42oyT4VjB6PzlyYg7PJ.Pu v8VqXzRdVp3OlPF6PF30Ru_ghMplMPpv.cUf2qyJ9nSkIMzH3Gbw4IXATep2 Voo6dgzyJIs3c8Ulb6zyd9EQTNXmjhb6z84VSZ89M2SA_Tin.XdH7MWsJ6ro c1z7gwO4iAPBAO5mccYi4FzFwYGQirzcSP9Y_LCDQHe0JtI6E6Ed_0pOj32o 1D6Ms9SWbWeMM6Iuc4c2fWPAYpTkPE.9VyVQ1.T3m_Wwm8QHfSIombuyKVao V171nSLP80JQ2EMcWLRvBhO4yPRROa6AN5OaSKkIaLzFY7bIUV_L2xw-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C46158F.7050709@ieca.com> Date: Tue, 20 Jul 2010 17:30:55 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: multipart/mixed; boundary="------------050605060606070504070602" Subject: [saag] [Fwd: New Non-WG Mailing List: cgasec@ietf.org] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2010 21:31:02 -0000 This is a multi-part message in MIME format. --------------050605060606070504070602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In case you're not subscribed to the ietf-announce list, I thought I'd forward this along. I'm curious what people think about this and the following I-D: https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ I know that there was push back on this approach in the past. Curious about what if anything has changed. Is this a good idea? spt --------------050605060606070504070602 Content-Type: message/rfc822; name="New Non-WG Mailing List: cgasec@ietf.org.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="New Non-WG Mailing List: cgasec@ietf.org.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.78; Mon, 19 Jul 2010 15:22:46 -0700 Received-SPF: pass (mta1002.biz.mail.sk1.yahoo.com: domain of ietf-announce-bounces@ietf.org designates 64.170.98.32 as permitted sender) X-YMailISG: lhxsSKocZApGJVJZvb.bgd10yDk5IFbvisi.fb4dgaYF90ka EakYIwuU_.Sy6NuhDAQLQmUdeDKSpP6Nd0RoYqYwfODeV_LHfvnSRotl.fsH ho5lcrwFRZEhE55q7TkLjN9XQmFlbuRqA8B589NLWpBy3daK_z8E2dN4GVCW MDm13IPCHbehza6KC7sE69vP9UTggaYDp9xQSZx51CwS77tNpsdT8cD1uUNc OdRsbYQ4.aWDe.iSrNc7Af.u3glPIg_UKKvv.TYQnV2JX6wpNO9jSROdMivd 9j7iZIR1Es_rusw.zWQZ7NFEKLBa2f9GB5p9W8Jo8Y356dZRFbl5BakqBaJs 6g25Q50k.Q5Mh_S0g7MCOk5XynhFH0G1uuCfbreSDNYWqzQ_m5NGs59chhC7 RCKMCj80wIoQMXrqw2qBDwivooy_RDT.Ml2.ie8e6cdVQblGGCVZhmMJQ.YE vD1GiPiAggWoUW4Cr2QTX5xz_K55VEoUI1J.X0N77Uw1ZR8MaSfJ02AeDic_ VqwrvK7.4BD4kHEY3QMltsl1DqtKky3WwvygZEM3MQz3IBWNZdgII7wSaYab e1nX8zrYPAPpQeNUFzGmvnPAq9eUDOnzWmpXFhYvXgun0iL9tTFKxFuSnKn0 OG8- X-Originating-IP: [64.170.98.32] Authentication-Results: mta1002.biz.mail.sk1.yahoo.com from=ietf.org; domainkeys=neutral (no sig); from=ietf.org; dkim=neutral (no sig) Received: from 64.170.98.32 (EHLO mail.ietf.org) (64.170.98.32) by mta1002.biz.mail.sk1.yahoo.com with SMTP; Mon, 19 Jul 2010 15:22:46 -0700 Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783C93A6B7C; Mon, 19 Jul 2010 15:22:19 -0700 (PDT) X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id F3D0E3A698C; Mon, 19 Jul 2010 15:22:16 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Subject: New Non-WG Mailing List: cgasec@ietf.org Mime-Version: 1.0 Message-Id: <20100719222216.F3D0E3A698C@core3.amsl.com> Date: Mon, 19 Jul 2010 15:22:16 -0700 (PDT) Cc: cgasec@ietf.org, mrw@painless-security.com X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ietf-announce-bounces@ietf.org Errors-To: ietf-announce-bounces@ietf.org A new IETF non-working group email list has been created. List address: cgasec@ietf.org Archive: http://www.ietf.org/mail-archive/web/cgasec/ To subscribe: https://www.ietf.org/mailman/listinfo/cgasec Description: The cgasec list is a non-WG (or pre-WG) mailing list used to discuss how CGAs can be used to provide secure CGA-based access control across a multi-hop network, such as the Internet. For additional information, please contact the list administrator, Margaret Wasserman. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --------------050605060606070504070602-- From kent@bbn.com Tue Jul 20 18:04:02 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E008F3A6A85; Tue, 20 Jul 2010 18:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVtm0zbVpO4c; Tue, 20 Jul 2010 18:04:02 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E259C3A6A84; Tue, 20 Jul 2010 18:04:01 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38710 helo=[10.84.131.109]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObNjN-000IOT-Bz; Tue, 20 Jul 2010 21:04:17 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 20 Jul 2010 21:03:08 -0400 To: Sam Hartman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Margaret Wasserman , PaddyNallur , saag@ietf.org, Dong Zhang , secdir@ietf.org Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 01:04:03 -0000 Sam, Based on a quick reading, I am troubled by many aspects of this proposal. CGAs were intended to afford privacy for IPv6 users, while allowing a first-hop router to verify the binding between the host asserting the address and the address in question. The proposal to use CGAs in ACLs seems to negate the privacy feature, because it would (I assume) call for the CGAs to be static (for ease of ACL management). The proposal says that "any host along the path" can engage in an exchange to cause the subject host to verify itself as the "owner" of the address. this is a very big deviation from the much more limited, local SeND context. The proposal also calls for the sender to generate the signature on the payload of the packet, ala IPsec in Transport mode. The document cites RFC 3971 (the SeND) spec, which calls for sig generation is a very different context, i.e., NDP packets in the SeND exchange. This proposal includes an example (from the wireless context) suggesting that the sig is to be generated for every packet sent by a host, a requirement that would place a substantial burden on a host. IPsec rejected solutions of this sort for performance reasons. Conversely, if only an initial packet exchange, involves the signed packet from the host, the secruity offered is much lower, making it vulnerable to MITM attacks. Also note that SeND requires a trust anchor to be shared between the host and its local router. This is a reasonable assumption for that local context, but it less viable in a more general source/destination context that may extend outside a local space, as many of the offered examples do. Steve From kent@bbn.com Tue Jul 20 18:04:04 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 289383A6B07 for ; Tue, 20 Jul 2010 18:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp-3fcQ5fBP2 for ; Tue, 20 Jul 2010 18:04:03 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 472A33A6A84 for ; Tue, 20 Jul 2010 18:04:03 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:38710 helo=[10.84.131.109]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObNjP-000IOT-1g; Tue, 20 Jul 2010 21:04:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4C46158F.7050709@ieca.com> References: <4C46158F.7050709@ieca.com> Date: Tue, 20 Jul 2010 21:04:11 -0400 To: Sean Turner From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: saag@ietf.org Subject: Re: [saag] [Fwd: New Non-WG Mailing List: cgasec@ietf.org] X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 01:04:04 -0000 At 5:30 PM -0400 7/20/10, Sean Turner wrote: >In case you're not subscribed to the ietf-announce list, I thought >I'd forward this along. I'm curious what people think about this >and the following I-D: > >https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ > >I know that there was push back on this approach in the past. >Curious about what if anything has changed. Is this a good idea? > >spt > I find this a very questionable concept. I have copied saag on my reply to Sam's message to secdir, where he solicited feedback, so I won't repeat those comments in this message. Steve From julienl@qualcomm.com Wed Jul 21 15:58:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1922F3A688C for ; Wed, 21 Jul 2010 15:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJtBRcdnqOCi for ; Wed, 21 Jul 2010 15:58:08 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D4C5C3A6818 for ; Wed, 21 Jul 2010 15:58:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279753103; x=1311289103; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Stephen=20Kent=20,=20Sam=20Hartman =20|CC:=20Margaret=20Wasserman=20< mrw@painless-security.com>,=20PaddyNallur=0D=0A=09,=20"saag@ietf.org"=20, =20Dong=20Zhang=0D=0A=09|Date: =20Wed,=2021=20Jul=202010=2015:58:23=20-0700|Subject:=20R E:=20[secdir]=20Interest=20in=20draft-dong-savi-cga-heade r-03.txt=3B=0D=0A=20possibility=20of=20a=20five=20minute =20slot=20at=20saag?|Thread-Topic:=20[secdir]=20Interest =20in=20draft-dong-savi-cga-header-03.txt=3B=0D=0A=20poss ibility=20of=20a=20five=20minute=20slot=20at=20saag? |Thread-Index:=20AcsocKd4SicpdHDxRZSxcRwNZ8KtsAAt4Ptg |Message-ID:=20|References:=20=20 |In-Reply-To:=20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=j1mFGU2unsTE+pn+zs/YmckNY8ByqBEV2wvEeldHYBs=; b=FQPFOFszAPPQMQvebxUgeluBr6lUZIeg8Xhd0nV0rnj82/UO29QFeGnt 1wb1Zngy+21X2OBqUkefzGUT0OeP/5cICspORynBXyZpaDo8GpdR3j+Pr U7ifKMCJK8LGL8vobB27W3yt6NIZTmPWrDzjw2owLDtH5juKpQCE6+2D+ 0=; X-IronPort-AV: E=McAfee;i="5400,1158,6050"; a="48064310" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 21 Jul 2010 15:58:23 -0700 X-IronPort-AV: E=Sophos;i="4.55,238,1278313200"; d="scan'208";a="45411122" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Jul 2010 15:58:23 -0700 Received: from nalasexhc03.na.qualcomm.com (10.47.129.194) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 15:58:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhc03.na.qualcomm.com ([10.47.129.194]) with mapi; Wed, 21 Jul 2010 15:58:24 -0700 From: "Laganier, Julien" To: Stephen Kent , Sam Hartman Date: Wed, 21 Jul 2010 15:58:23 -0700 Thread-Topic: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? Thread-Index: AcsocKd4SicpdHDxRZSxcRwNZ8KtsAAt4Ptg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Margaret Wasserman , PaddyNallur , "saag@ietf.org" , Dong Zhang Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 22:58:10 -0000 Steve, Stephen Kent wrote: >=20 > Sam, >=20 > Based on a quick reading, I am troubled by many aspects of this=20 > proposal. >=20 > CGAs were intended to afford privacy for IPv6 users, while allowing a=20 > first-hop router to verify the binding between the host asserting the=20 > address and the address in question. My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable = at a care-of address (via a MIPv6 Binding Update) and the home address in q= uestion. >From my perspective the key intent behind the use CGA's was the ability to = verify the binding without recourse to an infrastructure, not privacy. I also don't see how the use of CGA's would afford to an IPv6 user any bett= er privacy than another IPv6 address given that it is uniquely bound to a l= ong (1024+ bits) public key. =20 > The proposal to use CGAs in ACLs seems to negate the privacy feature,=20 > because it would (I assume) call for the CGAs to be static (for ease=20 > of ACL management). I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not= have. =20 > The proposal says that "any host along the path" can engage in an=20 > exchange to cause the subject host to verify itself as the "owner" of=20 > the address. this is a very big deviation from the much more limited,=20 > local SeND context. As above, CGA use is not limited to a local context such as SEND. In partic= ular, the use of CGA's for Mobile IPv6 security is in a _global_ context. =20 > The proposal also calls for the sender to generate the signature on=20 > the payload of the packet, ala IPsec in Transport mode. The document=20 > cites RFC 3971 (the SeND) spec, which calls for sig generation is a=20 > very different context, i.e., NDP packets in the SeND exchange. >=20 > This proposal includes an example (from the wireless context)=20 > suggesting that the sig is to be generated for every packet sent by a=20 > host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons. If there were to be only one intermediary on-path node going to verify that= the packets were generated by the CGA owner, it would be possible to execu= te a key exchange protocol bound to the CGAs of the sending host and the ve= rifying node, and use symmetric keying material derived from that exchange = to afford integrity protection to every packet at a cost comparable to that= of IPsec providing integrity protection. =20 > Conversely, if only an initial packet exchange, involves the signed=20 > packet from the host, the secruity offered is much lower, making it=20 > vulnerable to MITM attacks. As above, an initial packet exchange could be used to derive symmetric keys= bound to the CGA's of the parties involved. =20 > Also note that SeND requires a trust anchor to be shared between the=20 > host and its local router. This is a reasonable assumption for that=20 > local context, but it less viable in a more general source/destination=20 > context that may extend outside a local space, as many of the offered=20 > examples do. The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router adverti= sement messages of the router discovery function of ND.=20 In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the addr= ess resolution function of ND. =20 Thus the SEND requirement of hosts and router sharing a trust anchor is ent= irely orthogonal to the use and generation of CGA's. --julien From kent@bbn.com Thu Jul 22 04:15:38 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89F6B3A6A90; Thu, 22 Jul 2010 04:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-0.535, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3y5z9K81alK; Thu, 22 Jul 2010 04:15:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DBA8A3A6828; Thu, 22 Jul 2010 04:15:36 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55735 helo=[192.168.9.234]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1ObtkO-0005ZX-6d; Thu, 22 Jul 2010 07:15:28 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 21 Jul 2010 20:45:49 -0400 To: "Laganier, Julien" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-932325169==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 11:15:38 -0000 --============_-932325169==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:35 AM -0700 7/21/10, Laganier, Julien wrote: >Steve, > >Stephen Kent wrote: >> >> Sam, >> >> Based on a quick reading, I am troubled by many aspects of this >> proposal. >> >> CGAs were intended to afford privacy for IPv6 users, while allowing a >> first-hop router to verify the binding between the host asserting the >> address and the address in question. > >My recollection is that a form of CGA were first proposed to secure >the binding between a host asserting that a Mobile IPv6 home address >is reachable at a care-of address (via a MIPv6 Binding Update) and >the home address in question. Section 7.3 of RFC 3792 (the original CGA RFC) says: 7.3. Privacy Considerations CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750]. This text motivates my characterization of the privacy aspects of CGAs, which depends on the ability of a hos to use different CGAs, either serially or in parallel. I think of the CGA mechanism as a way to enable use of varried address by a host, but to also enable a first hop router, to have confidence that an address of this sort (generated in an auto-config fashion) is not being hijacked by another local host. > >From my perspective the key intent behind the use CGA's was the >ability to verify the binding without recourse to an infrastructure, >not privacy. > >I also don't see how the use of CGA's would afford to an IPv6 user >any better privacy than another IPv6 address given that it is >uniquely bound to a long (1024+ bits) public key. I think the text above, and the cited text in RFC 3041 explains the rationale for privacy assertions re CGAs. > >> The proposal to use CGAs in ACLs seems to negate the privacy feature, >> because it would (I assume) call for the CGAs to be static (for ease >> of ACL management). > >I agree that if CGAs were to be used in ACLs they would need to be >static (or long-term), but this does not negate a privacy feature >that CGA's do not have. yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes. > >> The proposal says that "any host along the path" can engage in an >> exchange to cause the subject host to verify itself as the "owner" of >> the address. this is a very big deviation from the much more limited, >> local SeND context. > >As above, CGA use is not limited to a local context such as SEND. In >particular, the use of CGA's for Mobile IPv6 security is in a >_global_ context. I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes. > > The proposal also calls for the sender to generate the signature on >> the payload of the packet, ala IPsec in Transport mode. The document >> cites RFC 3971 (the SeND) spec, which calls for sig generation is a >> very different context, i.e., NDP packets in the SeND exchange. >> >> This proposal includes an example (from the wireless context) > > suggesting that the sig is to be generated for every packet sent by a >> host, a requirement that would place a substantial burden on a host. >> IPsec rejected solutions of this sort for performance reasons. > >If there were to be only one intermediary on-path node going to >verify that the packets were generated by the CGA owner, it would be >possible to execute a key exchange protocol bound to the CGAs of the >sending host and the verifying node, and use symmetric keying >material derived from that exchange to afford integrity protection >to every packet at a cost comparable to that of IPsec providing >integrity protection. yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-). > > Conversely, if only an initial packet exchange, involves the signed >> packet from the host, the secruity offered is much lower, making it >> vulnerable to MITM attacks. > >As above, an initial packet exchange could be used to derive >symmetric keys bound to the CGA's of the parties involved. and IPsec would be a good idea here too :-). > >> Also note that SeND requires a trust anchor to be shared between the >> host and its local router. This is a reasonable assumption for that >> local context, but it less viable in a more general source/destination >> context that may extend outside a local space, as many of the offered >> examples do. > >The SEND trust anchor is used by hosts to verify a router >certificates chain. The router public key being certified is used to >sign the router advertisement messages of the router discovery >function of ND. > >In contrast, hosts uses uncertified public keys that are used to >generate CGA's and sign neighbor solicitations and advertisement >messages of the address resolution function of ND. > >Thus the SEND requirement of hosts and router sharing a trust anchor >is entirely orthogonal to the use and generation of CGA's. Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack? Steve --============_-932325169==_ma============ Content-Type: text/html; charset="us-ascii" RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt
At 10:35 AM -0700 7/21/10, Laganier, Julien wrote:
Steve,

Stephen Kent wrote:
>
> Sam,
>
> Based on a quick reading, I am troubled by many aspects of this
> proposal.
>
> CGAs were intended to afford privacy for IPv6 users, while allowing a
> first-hop router to verify the binding between the host asserting the
> address and the address in question.

My recollection is that a form of CGA were first proposed to secure the binding between a host asserting that a Mobile IPv6 home address is reachable at a care-of address (via a MIPv6 Binding Update) and the home address in question.

Section 7.3 of RFC 3792 (the original CGA RFC) says:

7.3.  Privacy Considerations

   CGAs can give the same level of pseudonymity as the IPv6 address
   privacy extensions defined in RFC 3041 [RFC3041].  An IP host can
   generate multiple pseudo-random CGAs by executing the CGA generation
   algorithm of Section 4 multiple times and by using a different random
   or pseudo-random initial value for the modifier every time.  The host
   should change its address periodically as in [RFC3041].  When privacy
   protection is needed, the (pseudo)random number generator used in
   address generation SHOULD be strong enough to produce unpredictable
   and unlinkable values.  Advice on random number generation can be
   found in [RFC1750].
This text  motivates my characterization of the privacy aspects of CGAs, which depends on the ability of a hos to use different CGAs, either serially or in parallel.  I think of the CGA mechanism as a way to enable use of varried address by a host, but to also enable a first hop router, to have confidence that an address of this sort (generated in an auto-config fashion) is not being hijacked by another local host.

>From my perspective the key intent behind the use CGA's was the ability to verify the binding without recourse to an infrastructure, not privacy.
I also don't see how the use of CGA's would afford to an IPv6 user any better privacy than another IPv6 address given that it is uniquely bound to a long (1024+ bits) public key.

I think the text above, and the cited text in RFC 3041 explains the rationale for privacy assertions re CGAs.

 
> The proposal to use CGAs in ACLs seems to negate the privacy feature,
> because it would (I assume) call for the CGAs to be static (for ease
> of ACL management).

I agree that if CGAs were to be used in ACLs they would need to be static (or long-term), but this does not negate a privacy feature that CGA's do not have.

yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.

 
> The proposal says that "any host along the path" can engage in an
> exchange to cause the subject host to verify itself as the "owner" of
> the address. this is a very big deviation from the much more limited,
> local SeND context.

As above, CGA use is not limited to a local context such as SEND. In particular, the use of CGA's for Mobile IPv6 security is in a _global_ context.

I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.

 > The proposal also calls for the sender to generate the signature on
> the payload of the packet, ala IPsec in Transport mode.  The document
> cites RFC 3971 (the SeND) spec, which calls for sig generation is a
> very different context, i.e., NDP packets in the SeND exchange.
>
> This proposal includes an example (from the wireless context)
> suggesting that the sig is to be generated for every packet sent by a
> host, a requirement that would place a substantial burden on a host.
> IPsec rejected solutions of this sort for performance reasons.
If there were to be only one intermediary on-path node going to verify that the packets were generated by the CGA owner, it would be possible to execute a key exchange protocol bound to the CGAs of the sending host and the verifying node, and use symmetric keying material derived from that exchange to afford integrity protection to every packet at a cost comparable to that of IPsec providing integrity protection.

yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-).

 > Conversely, if only an initial packet exchange, involves the signed
> packet from the host, the secruity offered is much lower, making it
> vulnerable to MITM attacks.

As above, an initial packet exchange could be used to derive symmetric keys bound to the CGA's of the parties involved.

and IPsec would be a good idea here too :-).

 
> Also note that SeND requires a trust anchor to be shared between the
> host and its local router. This is a reasonable assumption for that
> local context, but it less viable in a more general source/destination
> context that may extend outside a local space, as many of the offered
> examples do.

The SEND trust anchor is used by hosts to verify a router certificates chain. The router public key being certified is used to sign the router advertisement messages of the router discovery function of ND.

In contrast, hosts uses uncertified public keys that are used to generate CGA's and sign neighbor solicitations and advertisement messages of the address resolution function of ND. 
Thus the SEND requirement of hosts and router sharing a trust anchor is entirely orthogonal to the use and generation of CGA's.

Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?

Steve
--============_-932325169==_ma============-- From julienl@qualcomm.com Sat Jul 24 07:40:09 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554513A6A12; Sat, 24 Jul 2010 07:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.503 X-Spam-Level: X-Spam-Status: No, score=-106.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0t4G1qXnjEc; Sat, 24 Jul 2010 07:40:07 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 122983A6A0F; Sat, 24 Jul 2010 07:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279982424; x=1311518424; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Margaret=20Wasserman=20,=20 Internet=20Area=0D=0A=09,=20"saag@ietf .org"=20,=20"secdir@ietf.org"=0D=0A=09,=20"ipdir@ietf.org"=20,=20" savi@ietf.org"=0D=0A=09,=20"csi@ietf.org" =20|CC:=20PaddyNallur=20,=20Dong=20Zhang=0D=0A=09 |Date:=20Sat,=2024=20Jul=202010=2007:40:20=20-0700 |Subject:=20RE:=20[secdir]=20New=20Mailing=20List:=20=20c gasec|Thread-Topic:=20[secdir]=20New=20Mailing=20List:=20 =20cgasec|Thread-Index:=20Acsp1r1t8JySvlknQ8mPfKRAwng+MwB ZshMw|Message-ID:=20|References:=20<413FFD 9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com>|In-Reply-To:=20 <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=J13ak9WLHY0D7nZRkI4NclnkdlIwFqs/Sf+QLkP6IpY=; b=aNjloy9rRbFTY7o2uzHevJ3GYGmIDrhaEuS14zFj0BxBdJ8tRp3fmGOu cHKYVdTpwgEAAQcQ5ZGysce2Sw1TcgTvLlBrP+rsazruQMKgVb4/IdfMD QtGyLelTozRxmYFD2lTJXBKgvgAfh8PiOl65ILSK0iRQ79m88654ueWrf M=; X-IronPort-AV: E=McAfee;i="5400,1158,6052"; a="48432867" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 24 Jul 2010 07:40:24 -0700 X-IronPort-AV: E=Sophos;i="4.55,252,1278313200"; d="scan'208";a="46595949" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 24 Jul 2010 07:40:24 -0700 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 24 Jul 2010 07:40:26 -0700 Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Sat, 24 Jul 2010 07:40:25 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Sat, 24 Jul 2010 07:40:25 -0700 From: "Laganier, Julien" To: Margaret Wasserman , Internet Area , "saag@ietf.org" , "secdir@ietf.org" , "ipdir@ietf.org" , "savi@ietf.org" , "csi@ietf.org" Date: Sat, 24 Jul 2010 07:40:20 -0700 Thread-Topic: [secdir] New Mailing List: cgasec Thread-Index: Acsp1r1t8JySvlknQ8mPfKRAwng+MwBZshMw Message-ID: References: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> In-Reply-To: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: PaddyNallur , Dong Zhang Subject: Re: [saag] [secdir] New Mailing List: cgasec X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 14:40:09 -0000 Hi Margaret, all, Margaret Wasserman wrote:=20 >=20 > Hi All, >=20 > We've put together a mailing list to discuss the use of > Cryptographically Generated Addresses (CGAs) for security purposes > across the internet. The list address is cgasec@ietf.org. To > subscribe, go to: https://www.ietf.org/mailman/listinfo/cgasec. >=20 > We have published a draft in this area that can be found here: >=20 > https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ >=20 > [...] >=20 > Please send any feedback on the above document to the cgasec@ietf.org > mailing list. Please avoid cross-pointing your feedback to the full > to: list on this message, unless you believe that it is pertinent to > the hundreds or low thousands of people included on this message. > Thank you. >=20 > We will be holding an old-fashioned Bar BOF in Maastricht (in a bar, > no presentations), probably on Thursday night for folks who are > interested in working our proposal, or related work in this technical > area. Further details about the bar BOF will be announced early next > week, after I get to Maastricht and can scope out a location. >=20 > There has also been some earlier work in this area by Julien Lagnier, > but I do not have a current reference. Julien it is not my intention > to omit your work from this discussion, so please feel free to send a > pointer. FWIW - here's a pointer: http://tools.ietf.org/html/draft-laganier-ike-ipv6-cga Abstract This document describes IKEv2 peer authentication via IPv6 Cryptographically Generated Addresses (CGA). This technique have been proposed to solve several security issues in the absence of any centralized trusted security infrastructure and without any pre- arrangements, to provide IPsec self-evident authentication mode between IPv6 nodes or security gateways. (IPsec is misspelled IPSec on the online dratf, I've corrected in the copy/= paste above :) --julien From hannes.tschofenig@nsn.com Mon Jul 12 09:32:21 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 27C6A3A6BBA for ; Mon, 12 Jul 2010 09:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_INVITATION=-2] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YYcdTIzbHjY for ; Mon, 12 Jul 2010 09:32:17 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 7EF063A6BAA for ; Mon, 12 Jul 2010 09:32:00 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o6CGW5ic019045 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Jul 2010 18:32:05 +0200 Received: from demuexc025.nsn-intra.net (demuexc025.nsn-intra.net [10.159.32.12]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o6CGW27Y025009 for ; Mon, 12 Jul 2010 18:32:05 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc025.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Mon, 12 Jul 2010 18:32:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Jul 2010 19:32:39 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B4502CB8A0B@FIESEXC015.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF Thread-Index: AcsevKYjQSWbt2Q4T2KKNdywuVACVADIwiNQ From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: X-OriginalArrivalTime: 12 Jul 2010 16:32:05.0338 (UTC) FILETIME=[C39BC3A0:01CB21DF] X-Mailman-Approved-At: Sat, 24 Jul 2010 08:02:14 -0700 Subject: [saag] FW: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2010 16:32:21 -0000 FYI >-----Original Message----- >From: hasmat-bounces@ietf.org [mailto:hasmat-bounces@ietf.org]=20 >On Behalf Of ext Peter Saint-Andre >Sent: 08 July, 2010 19:43 >To: hasmat@ietf.org >Subject: [HASMAT] Fwd: Meeting invitation: HASMAT Pre-BoF > >Here is the invite for the HASMAT call next week. > > >-------- Original Message -------- > > >Topic: HASMAT Pre-BoF >Date: Wednesday, July 14, 2010 >Time: 10:00 am, Mountain Daylight Time (Denver, GMT-06:00)=20 >Meeting Number: 491 333 963 Meeting Password: Maastricht > > >------------------------------------------------------- >To join the online meeting (Now from iPhones and other=20 >Smartphones too!) >------------------------------------------------------- >1. Go to >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&PW=3DNZTJmMzAwN2Vi&RT=3DMiM2 >3&PW=3DNZTJmMzAwN2Vi&RT=3DMiM2> > >2. If requested, enter your name and email address. >3. If a password is required, enter the meeting password:=20 >Maastricht 4. Click "Join". > >To view in other time zones or languages, please click the link: >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&PW=3DNZTJmMzAwN2Vi&ORT=3DMiM2 >3&PW=3DNZTJmMzAwN2Vi&ORT=3DMiM2> > > >------------------------------------------------------- >To join the audio conference only >------------------------------------------------------- >To receive a call back, provide your phone number when you=20 >join the meeting, or call the number below and enter the access code. >Call-in toll-free number (US/Canada): 1-866-469-3239 Call-in=20 >toll number (US/Canada): 1-650-429-3300 Toll-free dialing restrictions: >http://www.webex.com/pdf/tollfree_restrictions.pdf > >Access code:491 333 963 > >------------------------------------------------------- >For assistance >------------------------------------------------------- >1. Go to https://welcome.webex.com/welcome/mc >2. On the left navigation bar, click "Support". > >You can contact me at: >peter.saintandre@webex.com > > >To add this meeting to your calendar program (for example=20 >Microsoft Outlook), click this link: >https://welcome.webex.com/welcome/j.php?ED=3D8689638&UID=3D24463123 >&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA7RiflXMUsxxeuzlSryX1K54530qKYRqae= P >SJ66NPZI=3D&RT=3DMiM2 >3&ICS=3DMI&LD=3D1&RD=3D2&ST=3D1&SHA2=3DA7RiflXMUsxxeuzlSryX1K54530qKYRqa= e >PSJ66NPZI=3D&RT=3DMiM2> > > >The playback of UCF (Universal Communications Format) rich=20 >media files requires appropriate players. To view this type of=20 >rich media files in the meeting, please check whether you have=20 >the players installed on your computer by going to=20 >https://welcome.webex.com/welcome/systemdiagnosis.php > > > > >http://www.webex.com >We've got to start meeting like this(TM) > >CCP:+16504293300x491333963# > >IMPORTANT NOTICE: This WebEx service includes a feature that=20 >allows audio and any documents and other materials exchanged=20 >or viewed during the session to be recorded. By joining this=20 >session, you automatically consent to such recordings. If you=20 >do not consent to the recording, do not join the session. >_______________________________________________ >HASMAT mailing list >HASMAT@ietf.org >https://www.ietf.org/mailman/listinfo/hasmat > From julienl@qualcomm.com Wed Jul 21 10:35:54 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B23A03A68D6; Wed, 21 Jul 2010 10:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5HnR0O+JAyf; Wed, 21 Jul 2010 10:35:45 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id A5AAA3A68ED; Wed, 21 Jul 2010 10:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1279733754; x=1311269754; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Stephen=20Kent=20,=20Sam=20Hartman =20|CC:=20Margaret=20Wasserman=20< mrw@painless-security.com>,=20PaddyNallur=0D=0A=09,=20"saag@ietf.org"=20, =20Dong=20Zhang=0D=0A=09,=20"sec dir@ietf.org"=20|Date:=20Wed,=2021=20Jul =202010=2010:35:46=20-0700|Subject:=20RE:=20[secdir]=20In terest=20in=20draft-dong-savi-cga-header-03.txt=3B=0D=0A =20possibility=20of=20a=20five=20minute=20slot=20at=20saa g?|Thread-Topic:=20[secdir]=20Interest=20in=20draft-dong- savi-cga-header-03.txt=3B=0D=0A=20possibility=20of=20a=20 five=20minute=20slot=20at=20saag?|Thread-Index:=20AcsocKd 4SicpdHDxRZSxcRwNZ8KtsAAh9UJQ|Message-ID:=20|References:=20=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=sNroSeXZZPj87GvocXDIH8NuKhzKFwnWSUAUuWvFGsg=; b=gE9unjDT4f28lp4K6nM5uf8rE88jfuphlXr45XlllB14tw/bfmB6q67c CKLCq8xQNxqng0s89M2Ie6UNkRudSFQr0wrBD2tvylwBAfy/ImB4xAJzF xo1hUXpyJR4XDYf2RirqopYCwM3CU2EwruRmhJskSbZscEJ2JT6+8JaCR M=; X-IronPort-AV: E=McAfee;i="5400,1158,6050"; a="48184217" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine01.qualcomm.com with ESMTP; 21 Jul 2010 10:35:46 -0700 X-IronPort-AV: E=Sophos;i="4.55,238,1278313200"; d="scan'208";a="45262700" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Jul 2010 10:35:46 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 21 Jul 2010 10:35:47 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.694.0; Wed, 21 Jul 2010 10:35:48 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Wed, 21 Jul 2010 10:35:47 -0700 From: "Laganier, Julien" To: Stephen Kent , Sam Hartman Date: Wed, 21 Jul 2010 10:35:46 -0700 Thread-Topic: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? Thread-Index: AcsocKd4SicpdHDxRZSxcRwNZ8KtsAAh9UJQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Sat, 24 Jul 2010 08:02:14 -0700 Cc: Margaret Wasserman , PaddyNallur , "saag@ietf.org" , Dong Zhang , "secdir@ietf.org" Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jul 2010 17:35:55 -0000 Steve, Stephen Kent wrote: >=20 > Sam, >=20 > Based on a quick reading, I am troubled by many aspects of this > proposal. >=20 > CGAs were intended to afford privacy for IPv6 users, while allowing a > first-hop router to verify the binding between the host asserting the > address and the address in question. My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable = at a care-of address (via a MIPv6 Binding Update) and the home address in q= uestion. >From my perspective the key intent behind the use CGA's was the ability to = verify the binding without recourse to an infrastructure, not privacy. I also don't see how the use of CGA's would afford to an IPv6 user any bett= er privacy than another IPv6 address given that it is uniquely bound to a l= ong (1024+ bits) public key. =20 > The proposal to use CGAs in ACLs seems to negate the privacy feature, > because it would (I assume) call for the CGAs to be static (for ease > of ACL management). I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not= have. =20 > The proposal says that "any host along the path" can engage in an > exchange to cause the subject host to verify itself as the "owner" of > the address. this is a very big deviation from the much more limited, > local SeND context. As above, CGA use is not limited to a local context such as SEND. In partic= ular, the use of CGA's for Mobile IPv6 security is in a _global_ context. =20 > The proposal also calls for the sender to generate the signature on > the payload of the packet, ala IPsec in Transport mode. The document > cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange. >=20 > This proposal includes an example (from the wireless context) > suggesting that the sig is to be generated for every packet sent by a > host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons. If there were to be only one intermediary on-path node going to verify that= the packets were generated by the CGA owner, it would be possible to execu= te a key exchange protocol bound to the CGAs of the sending host and the ve= rifying node, and use symmetric keying material derived from that exchange = to afford integrity protection to every packet at a cost comparable to that= of IPsec providing integrity protection. =20 > Conversely, if only an initial packet exchange, involves the signed > packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks. As above, an initial packet exchange could be used to derive symmetric keys= bound to the CGA's of the parties involved. =20 > Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination > context that may extend outside a local space, as many of the offered > examples do. The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router adverti= sement messages of the router discovery function of ND.=20 In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the addr= ess resolution function of ND. =20 Thus the SEND requirement of hosts and router sharing a trust anchor is ent= irely orthogonal to the use and generation of CGA's. --julien From margaretw42@gmail.com Thu Jul 22 05:50:39 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72C63A6835; Thu, 22 Jul 2010 05:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BT43vhY3qtdZ; Thu, 22 Jul 2010 05:50:38 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id DFF053A67B8; Thu, 22 Jul 2010 05:50:37 -0700 (PDT) Received: by qwe5 with SMTP id 5so3229076qwe.31 for ; Thu, 22 Jul 2010 05:50:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=4FJn+5kUVVjkXsZvPqF9SncU6OX6irUvr0Fx5Tw1J48=; b=NS5vHE5xadbj9XGGigQkwILxujitxFul5TDmbOSWZWKD5drJi/ppJlcD8dLJ8/TlXF kMsstSyY5gRdGWXnozauxWG/2Phd6EiFNJAt5NapYkDNy9XE9z1a1a5xaKmDEbZyZoOI Zkc3lQCvse6/ImKKLBgtACEgM1p8El4ECH+zk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=KCFg3KF7DsXgfkw0VxkI7zGxBa0BE/KAmRpo0kk/rZ7VfFZhAbK+zQ1wWQHok/tG3k a8RInJ7T7NxE4JydJiBqB6xrYnUNaQjG6zSn+S1xCoVg0YmjxeYBI1ZIiYtz2V2yIEoZ IgyM0BVq59yhZQ43+fxregc1DiSkp4endkoB0= Received: by 10.224.73.102 with SMTP id p38mr1138388qaj.270.1279803054330; Thu, 22 Jul 2010 05:50:54 -0700 (PDT) Received: from [172.17.172.250] ([65.174.54.2]) by mx.google.com with ESMTPS id h20sm30457839qcm.33.2010.07.22.05.50.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 05:50:43 -0700 (PDT) Message-Id: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> From: Margaret Wasserman To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 08:50:16 -0400 References: X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sat, 24 Jul 2010 08:02:14 -0700 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 12:50:40 -0000 Hi Steve, Thanks for your feedback! On Jul 21, 2010, at 8:45 PM, Stephen Kent wrote: >> >> I agree that if CGAs were to be used in ACLs they would need to be >> static (or long-term), but this does not negate a privacy feature >> that CGA's do not have. > > yes, it does, because the privacy is afforded by the host generating > a sequence of CGAs for parallel or serial use is in conflict with > use of a static CGA as an address space identifier for access > control purposes. There may be an inherent incompatibility between access control and anonymity, but that does not mean that the use of CGAs for access control is mutually exclusive with their use for privacy by the same node. A node could have a CGA (or a set of CGAs) that it uses to access certain resources. Those address(es) could be used in access control lists, etc. However, the same node could still generate CGAs or IPv6 Privacy Addresses for temporary use when anonymity/privacy is desired. I would argue that the use of CGAs for privacy, as you have cited it, is under-specified. There is mention of the concept that hosts could use CGAs for privacy, but there is no explanation of how those addresses would be managed, how long they should live, how application- level programs should request them, etc. IPv6 Privacy Addresses (as defined in RFC 4941) are much better specified for this purpose. >> >> If there were to be only one intermediary on-path node going to >> verify that the packets were generated by the CGA owner, it would >> be possible to execute a key exchange protocol bound to the CGAs of >> the sending host and the verifying node, and use symmetric keying >> material derived from that exchange to afford integrity protection >> to every packet at a cost comparable to that of IPsec providing >> integrity protection. > > yes, one could do what you suggest above, but that would be > duplicating IPsec (ESP-NULL) functionality, which I hope would be > frowned upon :-). There is also a possibility that the use of CGAs and a CGA extension in the early packets of an exchange could be used to set-up an IPsec SA for the remainder of the flow. In cases where a flow will consist of more than a few packets, this would probably be a better approach than signing all of the packets in an exchange. >> > Conversely, if only an initial packet exchange, involves the signed >> > packet from the host, the secruity offered is much lower, making it >> > vulnerable to MITM attacks. >> >> As above, an initial packet exchange could be used to derive >> symmetric keys bound to the CGA's of the parties involved. > > and IPsec would be a good idea here too :-). I agree. :-) > Mostly, but not quite. if a host is challenged to provide a signed > sequence of packets by a purported intermediary, how does the host > know that the challenge is legitimate, and not just a DoS attack? As we discuss in the security considerations section, this is an open issue with the specification. There are some possibilities for how to deal with this issue -- perhaps we could require that the requester generate it's own CGA, sign the request and include an CGA extension header on the request? Or perhaps it would be better for the requester to do some other costly operation to make this attack as expensive for the attacker as it would be for the target? There may be other possibilities for how to address this issue... it is one of the things that we should work out in the IETF before publishing this document. Margaret From margaretw42@gmail.com Thu Jul 22 12:42:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54A93A67AC; Thu, 22 Jul 2010 12:42:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEl4faDQpKiw; Thu, 22 Jul 2010 12:42:56 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id C08153A686C; Thu, 22 Jul 2010 12:42:56 -0700 (PDT) Received: by pzk6 with SMTP id 6so3954184pzk.31 for ; Thu, 22 Jul 2010 12:43:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date:cc :x-mailer; bh=fQJszsOkhA5nzdLnpAm/ZAJoJudQLPtlgjEp+j7msDc=; b=d8qCx3awc9OYztSpptfe45fCNR9/4Hs84rmQnIzoOCneb2r6aS1vbRIMGE1lrFoFoG Sa95BZLa1oyrCDBrBXq/l5udmKHgHXFxxPCswaP+oKxyV9dQe/75wYF6KcryH9VP7WiQ zN5YHijZEvNewEbk85l4YEv0AFrEDZSDzPPLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:cc:x-mailer; b=J1m2kB9iiXuE5FGfdCyaSODB79kLmmYYp0XJ6ymKVYgvBZcOx2fX6R0ZXf8p8hZVON oU70W5jfdPQn0/wTbr8/emRGOnElOVwNQwJlJOetxqtqrhqGSI/ju8KMhGxneTon8x8y IlCZ7QLpKN+3mWuk2h1fUh7XbHg8JBwRC5tZM= Received: by 10.114.79.20 with SMTP id c20mr3826959wab.117.1279827794299; Thu, 22 Jul 2010 12:43:14 -0700 (PDT) Received: from [10.2.0.128] (68-248-62-130.ded.ameritech.net [68.248.62.130]) by mx.google.com with ESMTPS id d39sm87807888wam.16.2010.07.22.12.43.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 22 Jul 2010 12:43:12 -0700 (PDT) Message-Id: <413FFD9E-487D-40B2-B4DD-A10F5CD00C85@gmail.com> From: Margaret Wasserman To: Internet Area , saag@ietf.org, secdir@ietf.org, ipdir@ietf.org, savi@ietf.org, csi@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Jul 2010 15:43:09 -0400 X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Sat, 24 Jul 2010 08:02:14 -0700 Cc: PaddyNallur , Dong Zhang Subject: [saag] New Mailing List: cgasec X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 19:42:58 -0000 Hi All, We've put together a mailing list to discuss the use of Cryptographically Generated Addresses (CGAs) for security purposes across the internet. The list address is cgasec@ietf.org. To subscribe, go to: https://www.ietf.org/mailman/listinfo/cgasec. We have published a draft in this area that can be found here: https://datatracker.ietf.org/doc/draft-dong-savi-cga-header/ Abstract: This document specifies an IPv6 extension header called the Cryptographically Generated Address (CGA) Extension Header. The CGA Extension Header holds the CGA parameters associated with the source CGA of an IPv6 packet. This information can be used to validate that a particular packet was sent by the node associated with a specific CGA, enabling secure IPv6 address-based access control mechanisms. We're planning to hold a Bar BOF (the old fashioned kind, in a bar, with no presentations) in Maastricht to discuss the above draft and other possible work in this area. Please send any feedback on the above document to the cgasec@ietf.org mailing list. Please avoid cross-pointing your feedback to the full to: list on this message, unless you believe that it is pertinent to the hundreds or low thousands of people included on this message. Thank you. We will be holding an old-fashioned Bar BOF in Maastricht (in a bar, no presentations), probably on Thursday night for folks who are interested in working our proposal, or related work in this technical area. Further details about the bar BOF will be announced early next week, after I get to Maastricht and can scope out a location. There has also been some earlier work in this area by Julien Lagnier, but I do not have a current reference. Julien it is not my intention to omit your work from this discussion, so please feel free to send a pointer. Margaret From kent@bbn.com Tue Jul 27 01:44:00 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD8473A6BAA; Tue, 27 Jul 2010 01:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEyL6WBxr3Bw; Tue, 27 Jul 2010 01:43:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 7D8433A6BAC; Tue, 27 Jul 2010 01:43:51 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:49750 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Odflj-000Cyl-Jo; Tue, 27 Jul 2010 04:44:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> Date: Tue, 27 Jul 2010 04:43:44 -0400 To: Margaret Wasserman From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-931902245==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 08:44:00 -0000 X-List-Received-Date: Tue, 27 Jul 2010 08:44:00 -0000 --============_-931902245==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Margaret, >... >>> >>>I agree that if CGAs were to be used in ACLs they would need to be >>>static (or long-term), but this does not negate a privacy feature >>>that CGA's do not have. >> >>yes, it does, because the privacy is afforded by the host >>generating a sequence of CGAs for parallel or serial use is in >>conflict with use of a static CGA as an address space identifier >>for access control purposes. > >There may be an inherent incompatibility between access control and >anonymity, but that does not mean that the use of CGAs for access >control is mutually exclusive with their use for privacy by the same >node. I agree, in principle, but in practice I think there may serious problems. Hosts would have to support both modes of operation and offer a decent UI to enable users to choose which type of CGA they want in a given context. I worry that the latter will be hard to do well, and thus users may, in reality, be deprived of the anonymity that CGAs can offer, because hosts don't offer a UI that is manageable. >A node could have a CGA (or a set of CGAs) that it uses to access >certain resources. Those address(es) could be used in access >control lists, etc. However, the same node could still generate >CGAs or IPv6 Privacy Addresses for temporary use when >anonymity/privacy is desired. see my comment above. also, your text here assumes that privacy is the rare case, which prejudices the discussion :-). >I would argue that the use of CGAs for privacy, as you have cited >it, is under-specified. There is mention of the concept that hosts >could use CGAs for privacy, but there is no explanation of how those >addresses would be managed, how long they should live, how >application-level programs should request them, etc. IPv6 Privacy >Addresses (as defined in RFC 4941) are much better specified for >this purpose. I agree that 4941 provides a more concrete discussion of privacy for IPv6 addresses. But the discussion in section 2.4 of that RFC describes the simple notion of changing IIDs over time, and it suggests selecting the IIDs in a pseudo random fashion. CGAs meet these criteria. I think the authors of 4941 erred in dismissing the use of CGAs (in section 3.2.3). The authors of 4991 seem to assume that the public key used with CGAs is fixed, even though 3792 does not require/suggest that. Also, while I agree that the MD5-based randomization process in 4991 is faster than the analogous hash computation for 3972, I don't think the difference is significant with current processors and most, reasonable scenarios. As I noted in my message, RFC 3972 makes a number of references to privacy, so it was clearly a major consideration in the CGA design. I see CGAs as balancing the option of privacy with a need for local address use validation. The local address use validation is a good secruity practice, with minimal, adverse privacy concerns. If we say that CGAs are not to be used when privacy is desired, and if local net managers demand CGAs for local address use validation, then we have deprived users of all address privacy options. I'd not like to see that outcome. >>... > >There is also a possibility that the use of CGAs and a CGA extension >in the early packets of an exchange could be used to set-up an IPsec >SA for the remainder of the flow. In cases where a flow will >consist of more than a few packets, this would probably be a better >approach than signing all of the packets in an exchange. I agree. >... > >>Mostly, but not quite. if a host is challenged to provide a signed >>sequence of packets by a purported intermediary, how does the host >>know that the challenge is legitimate, and not just a DoS attack? > >As we discuss in the security considerations section, this is an >open issue with the specification. There are some possibilities for >how to deal with this issue -- perhaps we could require that the >requester generate it's own CGA, sign the request and include an CGA >extension header on the request? I don' think that is a viable approach for all of these cases cited in the proposal, e.g., it would require a host to be aware of the CGA of any intermediary system that might want to challenge the host. Maybe the scenarios in the proposal need to be scaled back. > Or perhaps it would be better for the requester to do some other >costly operation to make this attack as expensive for the attacker >as it would be for the target? There may be other possibilities for >how to address this issue... it is one of the things that we should >work out in the IETF before publishing this document. If the CGA challenge comes from a destination (not an intermediate system) and the host has a relationship with that destination, there probably are ways to alleviate this concern. But, if we look at scenarios like web server access, the TLS server cert model seems much more reasonable as a way of identifying the destination. Given the rising interest in issuing and publishing certs using DNSSEC, I think that model may be more appropriate for source/destination access control. We have a number of security protocols that know how to use certs, but we have had a hard time overcoming the hurdles associated with the issuance and distribution of certs in a very large scale fashion. DNSSEC provides an ideal basis for certifying the binding between a DNS name and a public key, in a fashion that does not require handing $ over to a trusted third party. Steve --============_-931902245==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-header
Margaret,


...

I agree that if CGAs were to be used in ACLs they would need to be static (or long-term), but this does not negate a privacy feature that CGA's do not have.

yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.

There may be an inherent incompatibility between access control and anonymity, but that does not mean that the use of CGAs for access control is mutually exclusive with their use for privacy by the same node.

I agree, in principle, but in practice I think there may serious problems. Hosts would have to support both modes of operation and offer a decent UI to enable users to choose which type of CGA they want in a given context.  I worry that the latter will be hard to do well, and thus users may, in reality, be deprived of the anonymity that CGAs can offer, because hosts don't offer a UI that is manageable.

A node could have a CGA (or a set of CGAs) that it uses to access certain resources.  Those  address(es) could be used in access control lists, etc.  However, the same node could still generate CGAs or IPv6 Privacy Addresses for temporary use when anonymity/privacy is desired.

see my comment above. also, your text here assumes that privacy is the rare case, which prejudices the discussion :-).

I would argue that the use of CGAs for privacy, as you have cited it, is under-specified.  There is mention of the concept that hosts could use CGAs for privacy, but there is no explanation of how those addresses would be managed, how long they should live, how application-level programs should request them, etc.  IPv6 Privacy Addresses (as defined in RFC 4941) are much better specified for this purpose.

I agree that 4941 provides a more concrete discussion of privacy for IPv6 addresses. But the discussion in section 2.4 of that RFC describes the simple notion of changing IIDs over time, and it suggests selecting the IIDs in a pseudo random fashion.  CGAs meet these criteria. I think the authors of 4941 erred in dismissing the use of CGAs (in section 3.2.3). The authors of 4991 seem to assume that the public key used with CGAs is fixed, even though 3792 does not require/suggest that. Also, while I agree that the MD5-based randomization process in 4991 is faster than the analogous hash computation for 3972, I don't think the difference is significant with current processors and most, reasonable scenarios.

As I noted in my message, RFC 3972 makes a number of references to privacy, so it was clearly a major consideration in the CGA design. I see CGAs as balancing the option of privacy with a need for local address use validation. The local address use validation is a good secruity practice, with minimal, adverse privacy concerns.  If we say that CGAs are not to be used when  privacy is desired, and if local net managers demand CGAs for local address use validation, then we have deprived users of all address privacy options.  I'd not like to see that outcome.

...

There is also a possibility that the use of CGAs and a CGA extension in the early packets of an exchange could be used to set-up an IPsec SA for the remainder of the flow.  In cases where a flow will consist of more than a few packets, this would probably be a better approach than signing all of the packets in an exchange.

I agree.

...

Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?

As we discuss in the security considerations section, this is an open issue with the specification.  There are some possibilities for how to deal with this issue -- perhaps we could require that the requester generate it's own CGA, sign the request and include an CGA extension header on the request?

I don' think that is a viable approach for all of these cases cited in the proposal, e.g.,  it would require a host to be aware of the CGA of any intermediary system that might want to challenge the host. Maybe the scenarios in the proposal need to be scaled back.

 Or perhaps it would be better for the requester to do some other costly operation to make this attack as expensive for the attacker as it would be for the target?  There may be other possibilities for how to address this issue...  it is one of the things that we should work out in the IETF before publishing this document.

If the CGA challenge comes from a destination (not an intermediate system) and the host has a relationship with that destination, there probably are ways to alleviate this concern. But, if we look at scenarios like web server access, the TLS server cert model seems much more reasonable as a way of identifying the destination.

Given the rising interest in issuing and publishing certs using DNSSEC, I think that model may be more appropriate for source/destination access control.  We have a number of security protocols that know how to use certs, but we have had a hard time overcoming the hurdles  associated with the issuance and distribution of certs in a very large scale fashion. DNSSEC provides an ideal basis for certifying the binding between a DNS name and a public key, in a fashion that does not require handing $ over to a trusted third party.

Steve
--============_-931902245==_ma============-- From turners@ieca.com Tue Jul 27 02:54:32 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64E9E3A68E8 for ; Tue, 27 Jul 2010 02:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.069 X-Spam-Level: X-Spam-Status: No, score=-2.069 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3-+iQqHZo2Y for ; Tue, 27 Jul 2010 02:54:31 -0700 (PDT) Received: from smtp112.biz.mail.sp1.yahoo.com (smtp112.biz.mail.sp1.yahoo.com [69.147.92.225]) by core3.amsl.com (Postfix) with SMTP id B38DD3A67FA for ; Tue, 27 Jul 2010 02:54:31 -0700 (PDT) Received: (qmail 83787 invoked from network); 27 Jul 2010 09:54:51 -0000 Received: from dhcp-26f6.meeting.ietf.org (turners@130.129.38.246 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 27 Jul 2010 02:54:50 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: _MP9vdcVM1k41K_UbxqAZ7bwwxoOYVfiNe_qRiy95b_oAw9 kE5d5QBXe857UTQ3VgCwHUoRYigC5Pn.lfBQ9kzRGCB4wlajtrh04tkzXTgk atQ71TmA9sHZa2dKT43BDpReuLw6qQjvNnXcSz97yApx0NRY243wX.UbiDSd 6mUuGV4TvbuMKrQ9daRZ94.2MEMbXPn0t4feZSqEs9N1HfnLJZ6.BJn3eCzq csEJOnkA0eH08TVEgoLNFNu3voPMuace9fnrALq6tIJWSCDiFFoGEs5qdYB7 Eqq_dVpnccph42Mn8np_yfYQ- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C4EACE8.9040901@ieca.com> Date: Tue, 27 Jul 2010 11:54:48 +0200 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org Content-Type: multipart/mixed; boundary="------------080309080105080904080409" Subject: [saag] IETF 78: SYSLOG working group summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:54:32 -0000 This is a multi-part message in MIME format. --------------080309080105080904080409 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit --------------080309080105080904080409 Content-Type: message/rfc822; name="syslog WG update - Re: reminder: need a summary for the saag list.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="syslog WG update - Re: reminder: need a summary for the saag"; filename*1=" list.eml" X-Account-Key: account2 X-Mozilla-Keys: X-Apparently-To: turners@ieca.com via 216.252.120.71; Tue, 27 Jul 2010 02:51:21 -0700 Received-SPF: pass (mta1008.biz.mail.sk1.yahoo.com: domain of clonvick@cisco.com designates 171.68.10.86 as permitted sender) X-YMailISG: jNwe4e8cZAr3sLDoGJdRzDFDoItFgJ06nzqffD4DknbNHGj. hGAFU9jf7HAg3TgmIQuTvtUiCq_hixiLL1N4jT5XvByrk5hBfEjHV8vpW.02 KNoiIQJnMLUgE8LQSC8qXxTcULat.Xs5uVQ7GvxwDhpwcq54JZEcjnf8W5q1 pPKDxVQqKL2eBFrwgIKvbywtNHfvpu27dKRlkd24yjXejMOUH8o23SRrkB4s GJI7gzK3viVQa9EctJuX7a2GxMMVjRjvRraAPGdxfz6LSuGPTjvXpe7.z4A_ dg4ToMOAraJDl1gEaU8vBfv6EiJQvB7J7.KTIkU1vFwBscCqb8bULRg0kvx2 v3wv708pPoCzS0rMnVH4wGgFGA_l3ziMLPdQMryCJCIN3XkhHJWZsr.1USOn Y6KePyUmI3KtJAck0opktOLtU6s9K5Ot15ZZs_bZ1IYb.yGxebEf1u1TGwqh VKRQAqhuD_xOTKShvUXOSDJ0zvTuIGiJu9Lxd1pKJut6oCVYT1WxTx82DkZ0 SIBE3sQC_unYL5e.UIOPFL7lke3w X-Originating-IP: [171.68.10.86] Authentication-Results: mta1008.biz.mail.sk1.yahoo.com from=cisco.com; domainkeys=neutral (no sig); from=cisco.com; dkim=neutral (no sig) Received: from 171.68.10.86 (EHLO sj-iport-4.cisco.com) (171.68.10.86) by mta1008.biz.mail.sk1.yahoo.com with SMTP; Tue, 27 Jul 2010 02:51:21 -0700 Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,267,1278288000"; d="scan'208";a="163406366" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 27 Jul 2010 09:51:20 +0000 Received: from sjc-cde-011.cisco.com (sjc-cde-011.cisco.com [171.69.16.68]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6R9pKq2002299; Tue, 27 Jul 2010 09:51:20 GMT Date: Tue, 27 Jul 2010 02:51:20 -0700 (PDT) From: Chris Lonvick To: "Polk, William T." , Sean Turner cc: ietfdbh@comcast.net, Christopher Lonvick Subject: syslog WG update - Re: reminder: need a summary for the saag list In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi, The syslog WG has completed all charter goals and is looking forward to closure. We are waiting for draft-ietf-syslog-dtls to complete the AUTH48 process so we can answer any last minute questions. Thanks, Chris On Tue, 27 Jul 2010, Polk, William T. wrote: > Folks, > > Just a quick reminder: please submit a summary of wg activities since IETF 77 after your wg meets this week to the saag list. For working groups that meet early this week and groups that are not meeting at Maastricht, please submit before the saag meeting (1PM Thursday). If the report is available on the saag list, Sean and I won't call you to the mike unless there are questions about the report. This helps accelerate the meeting and preserves open mike time! > > Working groups that are meeting late Thursday or Friday (i.e., hokey, ls, msec, and ltans) can hold off on their summary until after they meet. We would like you to encourage you to come to the mike and do some marketing, though... > > Thanks, > > Tim & Sean > --------------080309080105080904080409-- From kent@bbn.com Tue Jul 27 02:55:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 10DFC3A6A9D for ; Tue, 27 Jul 2010 02:55:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEm61r54lwsR for ; Tue, 27 Jul 2010 02:55:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 034643A68E8 for ; Tue, 27 Jul 2010 02:55:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:55714 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdgtP-000DTi-D8 for saag@ietf.org; Tue, 27 Jul 2010 05:56:11 -0400 Mime-Version: 1.0 Message-Id: Date: Tue, 27 Jul 2010 05:56:08 -0400 To: saag@ietf.org From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-931897925==_ma============" Subject: [saag] PKIX WG meeting summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:55:51 -0000 --============_-931897925==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" PKIX WG Meeting Summary There has been significant document progress since Anaheim: - 5 RFCs published since Anaheim: 5816, 5877, 5912, 5913, 5914 - 1 document in the RFC Editor's queue: TAMP (the protocol) - 4 documents in IESG processing: ASN.1 translation, OCSP agility, TAM requirements, certificate image - 2 I-Ds in process in the WG: CMC Updates, 5280 clarifications - 2 non-WG documents under consideration: updating AKI and SKI, Transport protocols for CMP The OCSP agility document requires changes to fix typos in the ASN.1, and a fix of how to specify signature algorithms. So, the document will be revised, undergo a quick WG last call, and be re-forwarded to the IESG, where Tim promises speed processing. The 5280 clarifications document has completed WGLC and is almost ready for forwarding to the IESG. The OCSP update (clarification) entails so many changes that the resulting document is expected to obsolete 2560, even though there is no intent to make changes that are not backward compatible, etc. There was a very brief presentation on how to make it clear to developers that it's OK to use other hash algorithms (not just SHA-1) to compute key identifiers (i.e., SKI & AKI). This may become a WG item. The final presentation was a request to resurrect a dead I-D that defines how to transport CMP, especially over HTTP. The 3GPP folks are using CMP (vs. CMC) for certificate management functions, and want a stable, unambiguous standard. This is likely to become a new WG item. --============_-931897925==_ma============ Content-Type: text/html; charset="us-ascii" PKIX WG meeting summary
PKIX WG Meeting Summary

There has been significant document progress since Anaheim:
-     5 RFCs published since Anaheim: 5816, 5877, 5912, 5913, 5914
-   1 document in the RFC Editor's queue: TAMP (the protocol)
-      4 documents in IESG processing: ASN.1 translation, OCSP agility, TAM requirements, certificate image
-   2 I-Ds in process in the WG: CMC Updates, 5280 clarifications
-  2 non-WG documents under consideration: updating AKI and SKI, Transport protocols for CMP

The OCSP agility document requires changes to fix typos in the ASN.1, and a fix of how to specify signature algorithms. So, the document will be revised, undergo a quick WG last call, and be re-forwarded to the IESG, where Tim promises speed processing.

The 5280 clarifications document has completed WGLC and is almost ready for forwarding to the IESG.

The OCSP update (clarification) entails so many changes that the resulting document  is expected to obsolete 2560, even though there is no intent to make changes that are not backward compatible, etc.

There was a very brief presentation on how to make it clear to developers that it's OK to use other hash algorithms (not just SHA-1) to compute key identifiers (i.e., SKI & AKI). This may become a WG item.

The final presentation was a request to resurrect a dead I-D that defines how to transport CMP, especially over HTTP. The 3GPP folks are using CMP (vs. CMC) for certificate management functions, and want a stable, unambiguous standard.  This is likely to become a new WG item.
--============_-931897925==_ma============-- From j.schoenwaelder@jacobs-university.de Tue Jul 27 05:22:25 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4416F3A6BCB for ; Tue, 27 Jul 2010 05:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_05=-1.11, HELO_EQ_DE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tA4zX+w8t9ko for ; Tue, 27 Jul 2010 05:22:24 -0700 (PDT) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by core3.amsl.com (Postfix) with ESMTP id 8260C3A6B9B for ; Tue, 27 Jul 2010 05:22:23 -0700 (PDT) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21FB0C000D for ; Tue, 27 Jul 2010 14:22:45 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PYz+QkCwsLOR; Tue, 27 Jul 2010 14:22:43 +0200 (CEST) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7DFE2C0002; Tue, 27 Jul 2010 14:22:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A0C8913DD4F3; Tue, 27 Jul 2010 14:22:40 +0200 (CEST) Date: Tue, 27 Jul 2010 14:22:40 +0200 From: Juergen Schoenwaelder To: saag@ietf.org Message-ID: <20100727122240.GA56860@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: [saag] ISMS WG (non-)meeting summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 12:22:25 -0000 The ISMS working group is not meeting at the 78th IETF. We have one document left on the usage of Authentication, Authorization, and Accounting (AAA) services for provisioning SNMP's View-Based Access Control (VACM) user to group mappings on our charter. This document has passed WG last calls and is being submitted to the responsible AD (Sean Turner) once the document editor is able to post the latest revised version (hopefully still this week). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From julienl@qualcomm.com Tue Jul 27 08:22:59 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAEE73A6862; Tue, 27 Jul 2010 08:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFzH7dHiMKPQ; Tue, 27 Jul 2010 08:22:48 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id D816D3A6768; Tue, 27 Jul 2010 08:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1280244187; x=1311780187; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:mime-version; z=From:=20"Laganier,=20Julien"=20 |To:=20Stephen=20Kent=20|CC:=20Sam=20Hartma n=20,=20Margaret=20Wasserman=0D=0A =09,=20PaddyNallur=20,=0D=0A=09"saag@ietf.org"=20,=20Dong=20Zhang=20,=0D=0A=09 "secdir@ietf.org"=20|Date:=20Tue,=2027 =20Jul=202010=2008:23:06=20-0700|Subject:=20RE:=20[secdir ]=20Interest=20in=20draft-dong-savi-cga-header-03.txt=3B =0D=0A=20=20possibility=20of=20a=20five=20minute=20slot =20at=20saag?|Thread-Topic:=20[secdir]=20Interest=20in=20 draft-dong-savi-cga-header-03.txt=3B=0D=0A=20=20possibili ty=20of=20a=20five=20minute=20slot=20at=20saag? |Thread-Index:=20Acspj0CZ+SySXdOnRcaAON+nc4AYiAEDgjcg |Message-ID:=20|References:=20=20=0D =0A=20=0D=0A=20|In-Reply-To:=20|Accept-Language:=20en-US|Content-Language:=20e n-US|X-MS-Has-Attach:|X-MS-TNEF-Correlator: |acceptlanguage:=20en-US|Content-Type:=20multipart/altern ative=3B=0D=0A=09boundary=3D"_000_BF345F63074F8040B58C00A 186FCA57F1F6688540FNALASEXMB04na_"|MIME-Version:=201.0; bh=ZSpJ/zcGcQqQi6Uwh5V0t/WGfW90uPMeNazff1EHNRs=; b=mmqq8rmFJV+S4MWGiqhigrO4GQg3jWQIkD4zZRGUmYbQgwvKYvZgbjAf LrVy/cEvlmlklV3nFXGjGC/IpRwz88K6XxCuDElB/OrVwYCcMEmLmlgj4 NOaOsa8sBNrwIgRMRI3koN67lJSmu06q5eBRiMNR3NaypJdBkFSb9BD6v 4=; X-IronPort-AV: E=McAfee;i="5400,1158,6055"; a="48797070" Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 27 Jul 2010 08:23:07 -0700 X-IronPort-AV: E=Sophos;i="4.55,267,1278313200"; d="scan'208,217";a="47602859" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 27 Jul 2010 08:23:07 -0700 Received: from nasanexhc04.na.qualcomm.com (172.30.48.17) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 27 Jul 2010 08:23:09 -0700 Received: from nalasexhub01.na.qualcomm.com (10.47.130.49) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.0.694.0; Tue, 27 Jul 2010 08:23:09 -0700 Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub01.na.qualcomm.com ([10.47.130.49]) with mapi; Tue, 27 Jul 2010 08:23:08 -0700 From: "Laganier, Julien" To: Stephen Kent Date: Tue, 27 Jul 2010 08:23:06 -0700 Thread-Topic: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? Thread-Index: Acspj0CZ+SySXdOnRcaAON+nc4AYiAEDgjcg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_" MIME-Version: 1.0 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 15:23:00 -0000 --_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Steve, Please see some comments below, marked with [JL]. From: Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, July 22, 2010 2:46 AM To: Laganier, Julien Cc: Sam Hartman; Margaret Wasserman; PaddyNallur; saag@ietf.org; Dong Zhang= ; secdir@ietf.org Subject: RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possib= ility of a five minute slot at saag? At 10:35 AM -0700 7/21/10, Laganier, Julien wrote: Steve, Stephen Kent wrote: > > Sam, > > Based on a quick reading, I am troubled by many aspects of this > proposal. > > CGAs were intended to afford privacy for IPv6 users, while allowing a > first-hop router to verify the binding between the host asserting the > address and the address in question. My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable = at a care-of address (via a MIPv6 Binding Update) and the home address in q= uestion. Section 7.3 of RFC 3792 (the original CGA RFC) says: 7.3. Privacy Considerations CGAs can give the same level of pseudonymity as the IPv6 address privacy extensions defined in RFC 3041 [RFC3041]. An IP host can generate multiple pseudo-random CGAs by executing the CGA generation algorithm of Section 4 multiple times and by using a different random or pseudo-random initial value for the modifier every time. The host should change its address periodically as in [RFC3041]. When privacy protection is needed, the (pseudo)random number generator used in address generation SHOULD be strong enough to produce unpredictable and unlinkable values. Advice on random number generation can be found in [RFC1750]. This text motivates my characterization of the privacy aspects of CGAs, wh= ich depends on the ability of a hos to use different CGAs, either serially = or in parallel. I think of the CGA mechanism as a way to enable use of var= ried address by a host, but to also enable a first hop router, to have conf= idence that an address of this sort (generated in an auto-config fashion) i= s not being hijacked by another local host. [JL] I read the above RFC 3972 text as not negating the privacy feature tha= t can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus= a CGA might or might not have privacy feature, and privacy is thus a featu= re that is orthogonal to CGAs. The central feature of a CGA is that one can= verify that host "owns" the address (own in the sense that it's the one th= at generated in the first place, i.e., it's not hijacked.) >From my perspective the key intent behind the use CGA's was the ability to= verify the binding without recourse to an infrastructure, not privacy. I also don't see how the use of CGA's would afford to an IPv6 user any bett= er privacy than another IPv6 address given that it is uniquely bound to a l= ong (1024+ bits) public key. I think the text above, and the cited text in RFC 3041 explains the rationa= le for privacy assertions re CGAs. [JL] Understood. > The proposal to use CGAs in ACLs seems to negate the privacy feature, > because it would (I assume) call for the CGAs to be static (for ease > of ACL management). I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not= have. yes, it does, because the privacy is afforded by the host generating a sequ= ence of CGAs for parallel or serial use is in conflict with use of a static= CGA as an address space identifier for access control purposes. [JL] I think we agree but differ on how we're expressing it. I'd say that t= he use of static addresses in ACLs is in conflict with the privacy afforded= by being able to periodically regenerate an address, as per 3041. > The proposal says that "any host along the path" can engage in an > exchange to cause the subject host to verify itself as the "owner" of > the address. this is a very big deviation from the much more limited, > local SeND context. As above, CGA use is not limited to a local context such as SEND. In partic= ular, the use of CGA's for Mobile IPv6 security is in a _global_ context. I admit that I was not thinking about CGAs in the mobile IP context; RFC 39= 72 does refer to mobile nodes, but does not say much in that regard. RFC 45= 81, which updated 3972, never mentions mobile nodes. [JL] The use of CGA in the mobile IP context was documented later, in RFC 4= 866 "Enhanced Route Optimization for Mobile IPv6". > The proposal also calls for the sender to generate the signature on > the payload of the packet, ala IPsec in Transport mode. The document > cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange. > > This proposal includes an example (from the wireless context) > suggesting that the sig is to be generated for every packet sent by a > host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons. If there were to be only one intermediary on-path node going to verify that= the packets were generated by the CGA owner, it would be possible to execu= te a key exchange protocol bound to the CGAs of the sending host and the ve= rifying node, and use symmetric keying material derived from that exchange = to afford integrity protection to every packet at a cost comparable to that= of IPsec providing integrity protection. yes, one could do what you suggest above, but that would be duplicating IPs= ec (ESP-NULL) functionality, which I hope would be frowned upon :-). [JL] Well that could be all done based on IPsec, as you note below. > Conversely, if only an initial packet exchange, involves the signed > packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks. As above, an initial packet exchange could be used to derive symmetric keys= bound to the CGA's of the parties involved. and IPsec would be a good idea here too :-). [JL] Agree > Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination > context that may extend outside a local space, as many of the offered > examples do. The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router adverti= sement messages of the router discovery function of ND. In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the addr= ess resolution function of ND. Thus the SEND requirement of hosts and router sharing a trust anchor is ent= irely orthogonal to the use and generation of CGA's. Mostly, but not quite. if a host is challenged to provide a signed sequence= of packets by a purported intermediary, how does the host know that the ch= allenge is legitimate, and not just a DoS attack? [JL] if there's execution of a key establishment protocol based on the publ= ic keys bound to the CGAs, the opportunity for a DoS attack is reduced and = more in line with what's been done in the context of BTNS. [JL] All of that being said, I agree that the requirement to use static CGA= s is a bad thing. That requirement could be removed if the ACLs were based = on the public keys generating the CGAs, rather than the CGAs themselves. Bu= t if that were the case, coupled with the use of a key establishment protoc= ol, then it becomes dubious what is the additional value provided by CGAs a= s IPsec seems to afford the required security service: access control, inte= grity protection. --julien --_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt

Hi Steve,

 

Please see some comments below, marked with [JL].=

 

From: Stephen Kent [mailto:kent@bbn.com]
Sent: Thursday, July 22, 2010 2:46 AM
To: Laganier, Julien
Cc: Sam Hartman; Margaret Wasserman; PaddyNallur; saag@ietf.org; Don= g Zhang; secdir@ietf.org
Subject: RE: [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag?

 

At 10:35 AM -0700 7/21/10, Laganier, Julien wrote:

Steve,

Stephen Kent wrote:
>
> Sam,
>
> Based on a quick reading, I am troubled by many aspects of this
> proposal.
>
> CGAs were intended to afford privacy for IPv6 users, while allowing a<= br> > first-hop router to verify the binding between the host asserting the<= br> > address and the address in question.

My recollection is that a form of CGA were first proposed to secure the bin= ding between a host asserting that a Mobile IPv6 home address is reachable at a care-of address (via a MIPv6 Binding Update) and the home address in questi= on.


Section 7.3 of RFC 3792 (the original CGA RFC) says:

 

7.3.  Privacy Considerations

   CGAs can give the same level of pseudonymity as the IPv6 addre= ss
   privacy extensions defined in RFC 3041 [RFC3041].&nb= sp; An IP host can
   generate multiple pseudo-random CGAs by executing the CGA generation
   algorithm of Section 4= multiple times and by using a different random
   or pseudo-random initial value for the modifier every time.&nb= sp; The host
   should change its address periodically as in [RFC3041].&nb= sp; When privacy
   protection is needed, the (pseudo)random number generator used= in
   address generation SHOULD be strong enough to produce unpredictable
   and unlinkable values.  Advice on random number generatio= n can be

   found in [RFC1750].

This text  motivates my characterization of the p= rivacy aspects of CGAs, which depends on the ability of a hos to use different CGA= s, either serially or in parallel.  I think of the CGA mechanism as a way= to enable use of varried address by a host, but to also enable a first hop rou= ter, to have confidence that an address of this sort (generated in an auto-confi= g fashion) is not being hijacked by another local host.

 =

[JL] I read the above RFC 3972 text as not negating the priv= acy feature that can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus a CGA might or might not have privacy feature, and privacy is th= us a feature that is orthogonal to CGAs. The central feature of a CGA is that on= e can verify that host “owns” the address (own in the sense that = it’s the one that generated in the first place, i.e., it’s not hijacked.)<= o:p>

>From my perspective the key intent behind the use = CGA's was the ability to verify the binding without recourse to an infrastructure= , not privacy.

I also don't see how the use of CGA's would afford to = an IPv6 user any better privacy than another IPv6 address given that it is uniquely bound to a long (1024+ bits) public key.

 

I think the text above, and the cited text in RFC 3041= explains the rationale for privacy assertions re CGAs.

 =

[JL] Understood.

 
> The proposal to use CGAs in ACLs seems to negate the privacy feature,<= br> > because it would (I assume) call for the CGAs to be static (for ease > of ACL management).

I agree that if CGAs were to be used in ACLs they would need to be static (= or long-term), but this does not negate a privacy feature that CGA's do not ha= ve.

 

yes, it does, because the privacy is afforded by the h= ost generating a sequence of CGAs for parallel or serial use is in conflict wit= h use of a static CGA as an address space identifier for access control purpo= ses.

 =

[JL] I think we agree but differ on how we’re expressi= ng it. I’d say that the use of static addresses in ACLs is in conflict with = the privacy afforded by being able to periodically regenerate an address, as pe= r 3041.

 
> The proposal says that "any host along the path" can engage = in an
> exchange to cause the subject host to verify itself as the "owner" of
> the address. this is a very big deviation from the much more limited,<= br> > local SeND context.

As above, CGA use is not limited to a local context such as SEND. In particular, the use of CGA's for Mobile IPv6 security is in a _global_ cont= ext.

 

I admit that I was not thinking about CGAs in the mobi= le IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.

 =

[JL] The use of CGA in the mobile IP context was documented later, in RFC 4866 “Enhanced Route Optimization for Mobile IPv6”= ;.

 > The proposal also calls for the sender to g= enerate the signature on
> the payload of the packet, ala IPsec in Transport mode.  The docu= ment
> cites RFC 3971 (the SeND) spec, which calls for sig generation is a > very different context, i.e., NDP packets in the SeND exchange.
>
> This proposal includes an example (from the wireless context)

> suggesting that the sig is to be generated for ev= ery packet sent by a
> host, a requirement that would place a substantial burden on a host. > IPsec rejected solutions of this sort for performance reasons.

If there were to be only one intermediary on-path node= going to verify that the packets were generated by the CGA owner, it would be possible to execute a key exchange protocol bound to the CGAs of the sendin= g host and the verifying node, and use symmetric keying material derived from that exchange to afford integrity protection to every packet at a cost comparable to that of IPsec providing integrity protection.

 

yes, one could do what you suggest above, but that wou= ld be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned u= pon :-).

 =

[JL] Well that could be all done based on IPsec, as you note= below.

 > Conversely, if only an initial packet excha= nge, involves the signed
> packet from the host, the secruity offered is much lower, making it > vulnerable to MITM attacks.

As above, an initial packet exchange could be used to derive symmetric keys bound to the CGA's of the parties involved.

 

and IPsec would be a good idea here too :-).

 =

[JL] Agree


> Also note that SeND requires a trust anchor to be shared between the > host and its local router. This is a reasonable assumption for that > local context, but it less viable in a more general source/destination=
> context that may extend outside a local space, as many of the offered<= br> > examples do.

The SEND trust anchor is used by hosts to verify a router certificates chai= n. The router public key being certified is used to sign the router advertisement messages of the router discovery function of ND.

In contrast, hosts uses uncertified public keys that are used to generate C= GA's and sign neighbor solicitations and advertisement messages of the address resolution function of ND. 

Thus the SEND requirement of hosts and router sharing = a trust anchor is entirely orthogonal to the use and generation of CGA's.

 

Mostly, but not quite. if a host is challenged to prov= ide a signed sequence of packets by a purported intermediary, how does the host k= now that the challenge is legitimate, and not just a DoS attack?

 

[JL] if there’s execution of a key establishment proto= col based on the public keys bound to the CGAs, the opportunity for a DoS attac= k is reduced and more in line with what’s been done in the context of BTNS= .

 

[JL] All of that being said, I agree that the requirement to= use static CGAs is a bad thing. That requirement could be removed if the ACLs w= ere based on the public keys generating the CGAs, rather than the CGAs themselv= es. But if that were the case, coupled with the use of a key establishment protocol, then it becomes dubious what is the additional value provided by = CGAs as IPsec seems to afford the required security service: access control, integrity protection.

 

--julien

 

 

--_000_BF345F63074F8040B58C00A186FCA57F1F6688540FNALASEXMB04na_-- From shanna@juniper.net Wed Jul 28 01:47:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9901328C102 for ; Wed, 28 Jul 2010 01:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.104 X-Spam-Level: X-Spam-Status: No, score=-6.104 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rk0-M5QbyoTG for ; Wed, 28 Jul 2010 01:47:42 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 384B928C10C for ; Wed, 28 Jul 2010 01:47:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKTE/uwjVU09rVcCbu6+16qJ5w/7qJ6JPL@postini.com; Wed, 28 Jul 2010 01:48:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 28 Jul 2010 01:47:57 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::8002:d3e7:4146:af5f]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Wed, 28 Jul 2010 04:47:56 -0400 From: Stephen Hanna To: "saag@ietf.org" Date: Wed, 28 Jul 2010 04:47:53 -0400 Thread-Topic: NEA summary Thread-Index: AcsuB4YNeR9+YmsaSE+tx/yymEonxQAKYspw Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {ECA4143E-FDDD-41B3-8B15-8C2E270CF588} x-cr-hashedpuzzle: Aso5 A6ie B386 CgCb ClXb DA3D DUhx EmwV FC/v FPHx G6Ng HGZV HOoE H84E IJSl IMG7; 1; cwBhAGEAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {ECA4143E-FDDD-41B3-8B15-8C2E270CF588}; cwBoAGEAbgBuAGEAQABqAHUAbgBpAHAAZQByAC4AbgBlAHQA; Wed, 28 Jul 2010 08:47:53 GMT;TgBFAEEAIABzAHUAbQBtAGEAcgB5AA== acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] NEA summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 08:47:53 -0000 The NEA WG met on Tuesday from 1300 to 1500 CEST. Our meeting focused on the Asokan attack for NEA: understanding it and deciding whether we should address it. After some discussion, we had complete and unanimous agreement in the room that we should address it. A Design Team was appointed to create an Internet Draft describing the attack and giving a proposed solution. This team will complete its work by October so that the NEA WG can resume its work on PT starting at IETF 79 in November. Thanks, Steve From paul.hoffman@vpnc.org Wed Jul 28 04:54:05 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3583A68F2 for ; Wed, 28 Jul 2010 04:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.583 X-Spam-Level: X-Spam-Status: No, score=0.583 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_50=0.001, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j51O0wIpEjuk for ; Wed, 28 Jul 2010 04:54:05 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id F39833A6836 for ; Wed, 28 Jul 2010 04:54:04 -0700 (PDT) Received: from [130.129.98.251] (dhcp-62fb.meeting.ietf.org [130.129.98.251]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o6SBsPie031576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 28 Jul 2010 04:54:27 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 28 Jul 2010 13:54:22 +0200 To: saag@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [saag] IPsecME WG summary for IETF 78 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 11:54:06 -0000 IPsecME met on Monday morning. We had a review of the high-availability requirements document. This was followed by an extended presentation on a proposed protocol that comes from an active design team. There was a good discussion of the proposed protocol, and the WG indicated it probably wanted to adopt the document. The WG had a presentation on rapid crash recovery, again, but there was not significant interest in the document. --Paul Hoffman, Director --VPN Consortium From aland@deployingradius.com Wed Jul 28 05:23:57 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46E113A68F6 for ; Wed, 28 Jul 2010 05:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJFZh+l+b5Cd for ; Wed, 28 Jul 2010 05:23:56 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by core3.amsl.com (Postfix) with ESMTP id 4736328C144 for ; Wed, 28 Jul 2010 05:23:56 -0700 (PDT) Received: from dhcp-60ee.meeting.ietf.org (dhcp-60ee.meeting.ietf.org [130.129.96.238]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0D80B1234339 for ; Wed, 28 Jul 2010 14:24:18 +0200 (CEST) Message-ID: <4C502171.3010702@deployingradius.com> Date: Wed, 28 Jul 2010 14:24:17 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: saag@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] EMU WG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 12:23:57 -0000 We had a good discussion on the channel bindings document. There appears to be a solid foundation for moving forward. We'll look to the list to establish consensus for the proposal which was suggested during the meeting. We had a final wrap-up on the tunnel requirements document. Proto write-up is pending. We had a presentation on securing EAP identity packets. There was some good feedback on the proposal (crypto and practical routing issues). There doesn't appear to be strong interest that there is a problem, and that the proposed solution is the appropriate one. Alan DeKok. From barryleiba@gmail.com Wed Jul 28 05:58:41 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CED943A68BD for ; Wed, 28 Jul 2010 05:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.747 X-Spam-Level: X-Spam-Status: No, score=-2.747 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 704JlNTZ+Yxn for ; Wed, 28 Jul 2010 05:58:41 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DA4FF3A679F for ; Wed, 28 Jul 2010 05:58:40 -0700 (PDT) Received: by iwn38 with SMTP id 38so5112453iwn.31 for ; Wed, 28 Jul 2010 05:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=jA4rh3r2SbGLKVA5Ly77piz+joqQmRTq4ia0Zr5djxc=; b=HWNOQXV6BgJ6JGN5xAuwyA06SflmSme9iT/2N6RCHayIxw88ySXcdB49V18cD708Wy g+GavhX3hY2vos7C6uinoahklxZ7EEpNHIS6mp8RZDnGsyQAObBZA8UQF/OA8neMWQXY eT8OPNBMI3nXdwu2iwT2XqTsZtd35i8sALjMo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=iKsHunqoQyy4XRDC7wA908XdCTSQ3PUj/S98majac7aSotyrEwDVKUlNcgNdTpu48p +uLvy5Y6beoXrkm6SsxNLPzB0TgUL9FiPmCBiCJ4cXrZNeVykzRm0MU19CRpbeTvT20i EN0mQokZOEDIlDiy0UA9cn/L9RHDbbrUeOUDA= MIME-Version: 1.0 Received: by 10.231.35.10 with SMTP id n10mr11801383ibd.161.1280321943336; Wed, 28 Jul 2010 05:59:03 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.37.5 with HTTP; Wed, 28 Jul 2010 05:59:03 -0700 (PDT) Date: Wed, 28 Jul 2010 08:59:03 -0400 X-Google-Sender-Auth: PuNH4QhY6k9dSpTMH3irTFiXukY Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: DKIM Mailing List Subject: [saag] DKIM WG, IETF 78, saag report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 12:58:41 -0000 The DKIM working group met at 1 p.m. on Wednesday, 28 July. The working group has just rechartered, and we discussed the new charter items and assigned tasks. - Advancement of DKIM spec to Draft Standard We clarified what's needed for the interoperability report. Tony and Murray tested their implementations at a DKIM interoperability test in 2007. They will repeat their tests and dig up the 2007 data, and they'll prepare a draft report. Target date: end of August. - Other DKIM data collection Murray is collecting data on deployment, verification failures, etc. JD will get data too, and Jim posted URLs with data. SM agreed to collate and organize. - ADSP data collection Jim posted some brief ADSP data; Murray can provide some counts. This item is lower priority for now, and we need more data sources. - mailing-lists draft New version just pushed out, incorporating recent comments. There are no particular issues still open. Murray will solicit more comments, and if the draft stays stable we'll consider WGLC in September. - TPA label for ADSP (individual draft) Doug Otis presented the current state of this draft, which specifies a mechanism to deal with third-party authentication. It was revised recently, based on comments from DKIM participants. We had some discussion; the draft will continue as individual. - Other business We had a brief discussion of the appropriate home for a domain reputation protocol. The suggestion is to go to the app area, create a non-wg mailing list, and discuss there. We're anticipating *not* meeting in Beijing, as most upcoming work appears not to need face-to-face time. Barry Leiba, DKIM co-chair From margaretw42@gmail.com Tue Jul 27 02:36:18 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02FA3A6A55; Tue, 27 Jul 2010 02:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJzw00mMKnMR; Tue, 27 Jul 2010 02:36:16 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 489283A67E5; Tue, 27 Jul 2010 02:36:15 -0700 (PDT) Received: by ewy22 with SMTP id 22so1301773ewy.31 for ; Tue, 27 Jul 2010 02:36:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=yUUhfgIW/XCUHlV5R0zii8XdsUG/G1wbdhyUUXnDoi4=; b=VuEFvKGXnVCiTWu5TtlPhsEZvQM3X4REFOL6ySpO3dqdq1bJgoONylzJ4wP5uhBsfO 2KyxuL+/pnTma4bBC8LX7D1X3W8dXb1fsNa2OQFYdO4Ni6Pd338rBv2g3UPHHj0fdipx R7PWDnE/JhNZ1/In9YohQ70ZfZ086DhSzh+eQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=CIWwbxq8LOJTsl30DyDKBXulPpSoZklLNZiERAuLucBp6Lgk/91j16D9T9n19HavIY hhKBcswCh2C8E7CVXEMIFtUL57jjhDUubNH4gNxIXotMCIU9zQ7E0jkSnuWPZ4kc2hFe jF4yrSB4F8SO4d5lKxZCHbiyP+0W/7/UKcvps= Received: by 10.213.45.194 with SMTP id g2mr4440373ebf.0.1280223396269; Tue, 27 Jul 2010 02:36:36 -0700 (PDT) Received: from dhcp-716e.meeting.ietf.org (dhcp-716e.meeting.ietf.org [130.129.113.110]) by mx.google.com with ESMTPS id a48sm7248730eei.19.2010.07.27.02.36.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 02:36:35 -0700 (PDT) Message-Id: <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> From: Margaret Wasserman To: Stephen Kent In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 27 Jul 2010 11:36:15 +0200 References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> X-Mailer: Apple Mail (2.936) X-Mailman-Approved-At: Wed, 28 Jul 2010 08:34:20 -0700 Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jul 2010 09:36:18 -0000 Hi Steve, Thanks for your additional feedback! I am finding this discussion very useful. On Jul 27, 2010, at 10:43 AM, Stephen Kent wrote: >> There may be an inherent incompatibility between access control and >> anonymity, but that does not mean that the use of CGAs for access >> control is mutually exclusive with their use for privacy by the >> same node. > > I agree, in principle, but in practice I think there may serious > problems. Hosts would have to support both modes of operation and > offer a decent UI to enable users to choose which type of CGA they > want in a given context. I worry that the latter will be hard to do > well, and thus users may, in reality, be deprived of the anonymity > that CGAs can offer, because hosts don't offer a UI that is > manageable. In the IETF privacy address work (so far) this is not so much a matter of having a UI (accessed by users) as having an API where applications that want temporary/privacy addresses can select that option for a specific application (as a socket option, for example). Applications that don't request privacy addresses don't get them. Generating ones addresses as CGAs doesn't really change this picture... If an application does not specify a privacy socket option, it could use a static CGA, while applications that do request privacy could use CGAs that are generated for a particular session or a given time period. > >> A node could have a CGA (or a set of CGAs) that it uses to access >> certain resources. Those address(es) could be used in access >> control lists, etc. However, the same node could still generate >> CGAs or IPv6 Privacy Addresses for temporary use when anonymity/ >> privacy is desired. > > see my comment above. also, your text here assumes that privacy is > the rare case, which prejudices the discussion :-). Actually, I think that privacy addresses should be the common case for outgoing client/server applications (e.g. web browsers). However, I believe that systems will continue to have static addresses (which may be static CGAs) if they need to run servers that can be reached at a particular address, if they are using referrals that should remain valid over a longer period of time, or if they are using applications where the source IP address is used as part of an access control system or any other mechanism that uses the source IP address to identify the source of the traffic for any reason. > > I agree that 4941 provides a more concrete discussion of privacy for > IPv6 addresses. But the discussion in section 2.4 of that RFC > describes the simple notion of changing IIDs over time, and it > suggests selecting the IIDs in a pseudo random fashion. CGAs meet > these criteria. I think the authors of 4941 erred in dismissing the > use of CGAs (in section 3.2.3). The authors of 4991 seem to assume > that the public key used with CGAs is fixed, even though 3792 does > not require/suggest that. Also, while I agree that the MD5-based > randomization process in 4991 is faster than the analogous hash > computation for 3972, I don't think the difference is significant > with current processors and most, reasonable scenarios. I agree with you that RFC 4991 could use some improvements in this area. If we do decide to charter a separate cgasec WG, I think it would make sense to include an update to this section of RFC 4991 in a charter for that group. Otherwise, it could potentially be done in an existing WG, such as 6man or intarea. > As I noted in my message, RFC 3972 makes a number of references to > privacy, so it was clearly a major consideration in the CGA design. > I see CGAs as balancing the option of privacy with a need for local > address use validation. The local address use validation is a good > secruity practice, with minimal, adverse privacy concerns. If we > say that CGAs are not to be used when privacy is desired, and if > local net managers demand CGAs for local address use validation, > then we have deprived users of all address privacy options. I'd not > like to see that outcome. I have not proposed that we disallow CGAs for privacy purposes, and I agree that we shouldn't do that. I don't believe, however, that using static CGAs for secure access control (where identifying the source is explicitly desired) is incompatible with using other CGAs for privacy (for applications where privacy is desired) on the same node. I think this would work quite well within the existing APIs that we have designed for privacy addresses. >> There is also a possibility that the use of CGAs and a CGA >> extension in the early packets of an exchange could be used to set- >> up an IPsec SA for the remainder of the flow. In cases where a >> flow will consist of more than a few packets, this would probably >> be a better approach than signing all of the packets in an exchange. > > I agree. There is also the possibility (that a few other people have raised with me this week) that we could design an IKEv2 SPI type (I apologize if that isn't quite the right terminology) that contains a CGA and CGA parameters, and that information could be used to set-up an IPsec SA. I am not sure if a transition to IPsec is the best choice for very short flows, though, such as the syslog or SNMP trap/inform use cases in the draft. I would be interested in your opinion about the trade- offs involved. I am not, personally, focusing on the exact details of our specific proposal at this point. I am interested in discussing how/if CGAs are a suitable mechanism to do one or both of the following things: 1) Produce viable security mechanisms that are simpler to configure than existing solutions. In many cases, this may only involve minor extensions or tweaks to existing mechanisms (e.g. the new IKE SPI type described above). 2) Offer a practical alternative to the insecure Access Control Lists (ACLs) that are still in wide use today. Part of being a practical alternative (that will actually get deployed) is that configuring the new solution cannot require considerably more work or expertise than configuring an insecure ACL. Do those seem like reasonable goals to you? Do you think there is some potential that we could accomplish these things using CGAs? >>> Mostly, but not quite. if a host is challenged to provide a signed >>> sequence of packets by a purported intermediary, how does the host >>> know that the challenge is legitimate, and not just a DoS attack? >> >> As we discuss in the security considerations section, this is an >> open issue with the specification. There are some possibilities >> for how to deal with this issue -- perhaps we could require that >> the requester generate it's own CGA, sign the request and include >> an CGA extension header on the request? > > I don' think that is a viable approach for all of these cases cited > in the proposal, e.g., it would require a host to be aware of the > CGA of any intermediary system that might want to challenge the > host. Maybe the scenarios in the proposal need to be scaled back. I'm not sure which use cases would need to be scaled back in this case and why. Could you explain a bit more? > >> Or perhaps it would be better for the requester to do some other >> costly operation to make this attack as expensive for the attacker >> as it would be for the target? There may be other possibilities >> for how to address this issue... it is one of the things that we >> should work out in the IETF before publishing this document. > If the CGA challenge comes from a destination (not an intermediate > system) and the host has a relationship with that destination, there > probably are ways to alleviate this concern. But, if we look at > scenarios like web server access, the TLS server cert model seems > much more reasonable as a way of identifying the destination. I am not creative/imaginative enough to believe that CGA access control will replace TLS! :-) > > Given the rising interest in issuing and publishing certs using > DNSSEC, I think that model may be more appropriate for source/ > destination access control. We have a number of security protocols > that know how to use certs, but we have had a hard time overcoming > the hurdles associated with the issuance and distribution of certs > in a very large scale fashion. DNSSEC provides an ideal basis for > certifying the binding between a DNS name and a public key, in a > fashion that does not require handing $ over to a trusted third party. CGAs have similar properties in this regard. They don't require configuring certificates on end nodes, and they don't require sending anyone any money. I share your preferences in this area. :-) Using DNSSEC to resolve this problem is an interesting idea... Is there a draft, paper or other published document that describes how to do this? Or could you flesh it out a bit? I would be interested in understanding this approach better, so that I could understand the trade-offs between these two approaches. Margaret From blaker@gmail.com Wed Jul 28 09:39:03 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D45733A68B9 for ; Wed, 28 Jul 2010 09:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jggo-LeE9IB for ; Wed, 28 Jul 2010 09:39:02 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id A96F828C0E4 for ; Wed, 28 Jul 2010 09:39:02 -0700 (PDT) Received: by pwj1 with SMTP id 1so1203298pwj.31 for ; Wed, 28 Jul 2010 09:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=hIMWEDqW0SNqvEEf1ySO79GlJXqPmJZnS9Mzp68y+fU=; b=LGUkLy3sgD9pFzv2M7jge0hc2dgYXBcNQ+1e7vQ6e/tgPYAH8UPOzYGgzy0KkdWPuA c1UWne2HNwzv+bH0biND2q8MO6JRa9j+NoL64W+EmoIhjJx4SlgWg/JjR27H+YLQ05Jx 9UFY2mRu6cpn0X292iK6uUK2pBV20dTvks8Nk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=QTEDGbgcaGSEV2KUlKjqhE5P0wVTVHyJ1vPbQPCVs5VJEpkIN68uOI+eWhwpk6etoe t+I4aWdUoWeXjFiWPRs+yI18Z8zLnSsKn0BUgy/3YPaLPYlgO/1CynZx9f+hUs2hCKo3 HX43cGwkdUuM57LHQgpejUYlaepO9ovNvi5EY= MIME-Version: 1.0 Received: by 10.142.207.9 with SMTP id e9mr11977271wfg.111.1280335165482; Wed, 28 Jul 2010 09:39:25 -0700 (PDT) Received: by 10.142.200.7 with HTTP; Wed, 28 Jul 2010 09:39:25 -0700 (PDT) Date: Wed, 28 Jul 2010 12:39:25 -0400 Message-ID: From: Blake Ramsdell To: saag@ietf.org Content-Type: multipart/alternative; boundary=000e0cd32c4ebb673a048c754295 X-Mailman-Approved-At: Wed, 28 Jul 2010 22:05:24 -0700 Subject: [saag] IETF 78 SMIME WG summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jul 2010 16:39:03 -0000 --000e0cd32c4ebb673a048c754295 Content-Type: text/plain; charset=ISO-8859-1 The S/MIME WG has been finishing up two remaining working group drafts: draft-ietf-smime-new-asn1 was published as RFC 5911 draft-ietf-smime-cms-rsa-kem is in state EDIT with the RFC Editor Blake -- Blake Ramsdell | http://blakeramsdell.com --000e0cd32c4ebb673a048c754295 Content-Type: text/html; charset=ISO-8859-1 The S/MIME WG has been finishing up two remaining working group drafts:

draft-ietf-smime-new-asn1 was published as RFC 5911

draft-ietf-smime-cms-rsa-kem is in state EDIT with the RFC Editor

Blake
--
Blake Ramsdell | http://blakeramsdell.com
--000e0cd32c4ebb673a048c754295-- From shawn.emery@oracle.com Wed Jul 28 18:06:41 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9C7628C1BA for ; Wed, 28 Jul 2010 18:06:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.628 X-Spam-Level: X-Spam-Status: No, score=-6.628 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2CLpdAJfTxo for ; Wed, 28 Jul 2010 18:06:40 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id A422F28C0E1 for ; Wed, 28 Jul 2010 18:06:40 -0700 (PDT) Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6T172Uc008025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Jul 2010 01:07:04 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6SJSUuR012082 for ; Thu, 29 Jul 2010 01:07:00 GMT Received: from abhmt006.oracle.com by acsmt355.oracle.com with ESMTP id 466194631280365596; Wed, 28 Jul 2010 18:06:36 -0700 MIME-Version: 1.0 Message-ID: Date: Wed, 28 Jul 2010 18:06:35 -0700 (PDT) From: Shawn Emery To: X-Mailer: Zimbra on Oracle Beehive Content-Type: multipart/alternative; boundary="__128036559580374785abhmt006" X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090206.4C50D436.0091:SCFMA4539814,ss=1,fgs=0 X-Mailman-Approved-At: Wed, 28 Jul 2010 22:05:24 -0700 Subject: [saag] kitten Working Group Summary - IETF 78 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 01:06:41 -0000 --__128036559580374785abhmt006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The kitten WG met Monday, 7/26/10, during the first morning session for=20 two hours.=20 Co-chairs: Tom Yu and Shawn Emery=20 The goals of the meeting were to review the state of the active WG items,= =20 one individual submission, discuss naming extensions lessons learned,=20 and recent recharter work.=20 gssapi-extensions-iana=20 ----------------------------=20 IANA had replied that they want the draft to pick one of the registry=20 types left as a choice in the current version of the draft:=20 single GSS-API name-space registry=20 registry per programming language=20 There are multiple members that prefer to have a registry per programming= =20 language.=20 gssapi-naming-exts=20 ------------------------=20 Sam Hartman had presented lessons learned from implementing naming=20 extensions. It was determined that the current draft is underspecified and= =20 that the mechanism implementation section be separated in another draft.=20 Sam has volunteered to work with the current authors on the draft.=20 draft-lha-gssapi-delegate-policy (non-WG item)=20 ----------------------------------------------------------=20 Now RFC 5896!=20 Recharter Discussion=20 --------------------------=20 The merger of the kitten and SASL WGs is complete.=20 It has been a couple of years since draft-ietf-kitten-digest-to-historic ha= s=20 made WG LC. Another one will be made shortly.=20 We discussed requested new work items that are of particular interest as ou= tlined=20 in:=20 draft-yu-kitten-api-wishlist=20 Requested editors/authors for any subsequent drafts. None had volunteered.= =20 We discussed changes made in the newly adopted drafts:=20 draft-lear-ietf-sasl-openid=20 draft-wierenga-ietf-sasl-saml=20 Will take consensus on the list on whether to adopt the following SSO=20 SASL mechanisms:=20 draft-cantor-ietf-sasl-saml-ec=20 draft-mills-kitten-sasl-oauth=20 It was determined that a problem statement should be sent to the TLS WG=20 list to cover draft-williams-tls-app-sasl-opt. If deemed appropriate then t= he=20 draft could be adopted by the TLS working group. Regardless, a WG LC=20 would be made in kitten as well.=20 Shawn kitten co-chair=20 --=20 --__128036559580374785abhmt006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Content-Disposition: inline

The kitten WG met Monday, 7/26/10, during the first morning session for
two hours.

Co-chairs: Tom Yu and Shawn Emery

The goals of the meeting were to review the state of the active WG items,
one individual submission, discuss naming extensions lessons learned,
and recent recharter work.

gssapi-extensions-iana
----------------------------
IANA had replied that they want the draft to pick one of the registry
types left as a choice in the current version of the draft:

single GSS-API name-space registry
registry per programming language

There are multiple members that prefer to have a registry per programming
language.

gssapi-naming-exts
------------------------
Sam Hartman had presented lessons learned from implementing naming
extensions.  It was determined that the current draft is underspecified and
that the mechanism implementation section be separated in another draft.
Sam has volunteered to work with the current authors on the draft.

draft-lha-gssapi-delegate-policy (non-WG item)
----------------------------------------------------------
Now RFC 5896!

Recharter Discussion
--------------------------
The merger of the kitten and SASL WGs is complete.

It has been a couple of years since draft-ietf-kitten-digest-to-historic has
made WG LC.  Another one will be made shortly.

We discussed requested new work items that are of particular interest as outlined
in:

draft-yu-kitten-api-wishlist

Requested editors/authors for any subsequent drafts. None had volunteered.

We discussed changes made in the newly adopted drafts:

draft-lear-ietf-sasl-openid
draft-wierenga-ietf-sasl-saml

Will take consensus on the list on whether to adopt the following SSO
SASL mechanisms:

draft-cantor-ietf-sasl-saml-ec
draft-mills-kitten-sasl-oauth

It was determined that a problem statement should be sent to the TLS WG
list to cover draft-williams-tls-app-sasl-opt.  If deemed appropriate then the
draft could be adopted by the TLS working group.  Regardless, a WG LC
would be made in kitten as well.

Shawn kitten co-chair
--
--__128036559580374785abhmt006-- From william.polk@nist.gov Wed Jul 28 22:41:33 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58A203A67B5 for ; Wed, 28 Jul 2010 22:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.627 X-Spam-Level: X-Spam-Status: No, score=-6.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RefoMnxKLXYx for ; Wed, 28 Jul 2010 22:41:32 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id 228673A63EC for ; Wed, 28 Jul 2010 22:41:31 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (WSXGHUB2.xchange.nist.gov [129.6.18.19]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o6T5fj0j026625 for ; Thu, 29 Jul 2010 01:41:45 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 29 Jul 2010 01:41:29 -0400 From: "Polk, William T." To: "saag@ietf.org" Date: Thu, 29 Jul 2010 01:39:00 -0400 Thread-Topic: keyprov summary for IETF 78 Thread-Index: AQHLLuCxBKDuBMiwMkWdc+FlKec8eg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Subject: [saag] keyprov summary for IETF 78 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 05:41:33 -0000 keyprov did not meet at IETF78, but the chairs provided the following summary: ________________________________________ From: Phillip Hallam-Baker [hallam@gmail.com] Sent: Wednesday, July 28, 2010 1:28 PM To: Polk, William T. Subject: Re: Any chance of a quick summary for saag for your working groups? Keyprov * draft-ietf-keyprov-dskpp: Dealing with IESG DISCUSS positions. 2nd IETF LC passed to address DOWNREF. * draft-ietf-keyprov-pskc: Dealing with IESG DISCUSS positions. 2nd IETF LC passed to address DOWNREF. * draft-ietf-keyprov-symmetrickeyformat: Dealing with IESG DISCUSS positions. PSKC discuss list should be done next week. Am looking at DSKPP to see what is still waiting. -- Website: http://hallambaker.com/ From joelja@bogus.com Wed Jul 28 23:45:06 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 871D23A67E7 for ; Wed, 28 Jul 2010 23:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.439 X-Spam-Level: X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JyA30ZmZ4Py for ; Wed, 28 Jul 2010 23:45:04 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 736143A67B5 for ; Wed, 28 Jul 2010 23:45:03 -0700 (PDT) Received: from dhcp-76fa.meeting.ietf.org (dhcp-76fa.meeting.ietf.org [130.129.118.250]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o6T6jN3D057304 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 29 Jul 2010 06:45:25 GMT (envelope-from joelja@bogus.com) Message-ID: <4C512382.8070609@bogus.com> Date: Thu, 29 Jul 2010 08:45:22 +0200 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Lightning/1.0b2 Thunderbird/3.1 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 29 Jul 2010 06:45:26 +0000 (UTC) Subject: [saag] Reviewers requested draft-ietf-opsec-igp-crypto-requirements-00 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 06:45:06 -0000 Folks, draft-ietf-opsec-igp-crypto-requirements-00.txt http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00 we could use some input from the participants of the security area to lend an extra set of eyeballs to this document. I The crypto-requirements document was accepted as a working group document and last called in the opsec WG. Our AD has requested additional review so the authors and the document shepherd are soliciting feedback accordingly. for a history and treatment of the document I have included the document shepherd review. Thanks joel ------------------ Document shepherd writeup for: draft-ietf-opsec-igp-crypto-requirements-00.txt http://tools.ietf.org/html/draft-ietf-opsec-igp-crypto-requirements-00.txt Prepared by: Joel Jaeggli 6/21/2010 1.a The Document Shepherd is Joel Jaeggli, Opsec WG co-chair. The Document Shepherd has reviewed Draft 00 of draft-ietf-opsec-igp-crypto-requirements and concluded that the document is prepared for IESG review and publication as an informational document. 1.b The document was widely socialized within the routing area working groups where protocol maintenance is being performed prior to being brought to the opsec working group. With opsec working group input the focus has changed somewhat for altering the cryptographic protocal usage of igp protocols to enumerating what the likely requirements should be and the basis for those recommendations. 1.c Insofar as the the doucument shepherd is concerned, further review of future changes in state of cryptogrphic protection for IGP and EGP protocols should be performed in working groups tasked with the protocol maintenance activities or in working groups chartered to solve the cyrpto-problem, such as the karp working group. This document represents the consensus view of the authors and the working group on what the requirements for such protocols should be. 1.d One concern of the shepherd is that the working title while accurate at the inception of the document somewhat overstates the fairly modest goals of the document in it's present form. The long form title is altogether more representative of the goals of the document. Cryptographic Authentication Algorithm Implementation Best Practices for Routing Protocols 1.e Working group consensus has been solidly behind this draft following revision is it's current form. Since presentation of the Updated draft in January the document has been accepted as a working group document and subsequently lasted called. Serious objections were not raised in either case. Prior to the revision, the draft have been presented in the working group meeting, discussed on the list, and had received contributions from working-group participants, however concern with the scope and the goal of changing protocol specifications in an ops area working group had precluded acceptance. 1.f No appeals or discontent are noted in the working group regarding the current draft at this time. 1.g IDnits notes the existence of several dated references many of which are required for historical treatment of the subject matter. Not major nits are noted. 1.h The draft divides references between normative and informative. This document's advancement is not blocked on the advancement of normatively referenced material. 1.i The draft makes no requests of IANA. Authentication methods (example OSPFv2 RFC 2328 Appendix D) are typically reserved through an IANA registry, so documents referencing this document or subsequent work will make IANA requests as a product of recommendations made in this document. 1.j No formal language schema is in use in this document. 1.k Document Announcement Write-up Summary: The routing protocols Open Shortest Path First version 2 (OSPFv2) [RFC2328], Intermediate System to Intermediate System (IS-IS) [ISO] [RFC1195] and Routing Information Protocol (RIP) [RFC2453] currently define Clear Text and MD5 (Message Digest 5) [RFC1321] methods for authenticating protocol packets. Recently effort has been made to add support for the SHA (Secure Hash Algorithm) family of hash functions for the purpose of authenticating routing protocol packets for RIP [RFC4822], IS-IS [RFC5310] and OSPF [RFC5709]. To encourage interoperability between disparate implementations, it is imperative that we specify the expected minimal set of algorithms thereby ensuring that there is at least one algorithm that all implementations will have in common. This document examines the current set of available algorithms with interoperability and effective cryptographic authentication protection being the principle considerations. Cryptographic authentication of these routing protocols requires the availability of the same algorithms in disparate implementations. It is desirable that newly specified algorithms should be implemented and available in routing protocol implementations because they may be promoted to requirements at some future time. Working Group Summary: The document was accepted as a workring group item on the mailing list on 1/24/2010.Working Group last call was performed for two weeks, ending on 5/29/2010. With no objections. Document Quality: The document covers the use of cryptographic protections in five igp protocols while it's is likely that the utility of recommendations made in this document will age or be rendered obsolete at different rates. Recommendations conveyed by the document are both informational in nature and temporally limited. From kent@bbn.com Thu Jul 29 00:53:51 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DC73A69AD; Thu, 29 Jul 2010 00:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEUKR26L4U6F; Thu, 29 Jul 2010 00:53:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 4E0743A699D; Thu, 29 Jul 2010 00:53:50 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39281 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeNwS-0004U9-P3; Thu, 29 Jul 2010 03:54:13 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> References: <438B2D37-5C58-4E1F-9E69-75E80D76C570@gmail.com> <821DAA3A-8F9E-4C16-9894-A7425362E135@gmail.com> Date: Thu, 29 Jul 2010 03:40:35 -0400 To: Margaret Wasserman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:53:52 -0000 At 11:36 AM +0200 7/27/10, Margaret Wasserman wrote: >Hi Steve, >>,,, > >In the IETF privacy address work (so far) this is not so much a >matter of having a UI (accessed by users) as having an API where >applications that want temporary/privacy addresses can select that >option for a specific application (as a socket option, for example). >Applications that don't request privacy addresses don't get them. Thanks; I didn't know what the model was. I do see possible problems with this model. It's somewhat reminiscent of the model we had in mind for how to use the TOS field in IP, back in the late 70's and early 80's. That didn't work because apps generally didn't make API calls to invoke TOS, and didn't offer a UI to enable users to sya TOS they thought they needed, ... >Generating ones addresses as CGAs doesn't really change this >picture... If an application does not specify a privacy socket >option, it could use a static CGA, while applications that do >request privacy could use CGAs that are generated for a particular >session or a given time period. Again, I agree in principle, but I worry that in practice the default will be static CGAs with no real user controls to invoke privacy features. > >>... > >Actually, I think that privacy addresses should be the common case >for outgoing client/server applications (e.g. web browsers). that's an interesting case, which may illustrate why this strikes me as a hard problem. Folks visit a range of web sites, some of which require user auth (for access control), and others that do not. If CGAs were to be used for access control, users might if confusing managing switching between static and dynamic CGAs depending on the sites being visited. >However, I believe that systems will continue to have static >addresses (which may be static CGAs) if they need to run servers >that can be reached at a particular address, if they are using >referrals that should remain valid over a longer period of time, or >if they are using applications where the source IP address is used >as part of an access control system or any other mechanism that uses >the source IP address to identify the source of the traffic for any >reason. I've been focusing on the user side of this issue. Servers need static DNS names, irrespective of whether their addresses are static or dynamic (with dynamic DNS). But, I agree that most servers (not use by phishers ans spammers) don't need addresses that vary for privacy purposes. >... >I agree with you that RFC 4991 could use some improvements in this >area. If we do decide to charter a separate cgasec WG, I think it >would make sense to include an update to this section of RFC 4991 in >a charter for that group. Otherwise, it could potentially be done >in an existing WG, such as 6man or intarea. Sure. >>... > >I have not proposed that we disallow CGAs for privacy purposes, and >I agree that we shouldn't do that. I don't believe, however, that >using static CGAs for secure access control (where identifying the >source is explicitly desired) is incompatible with using other CGAs >for privacy (for applications where privacy is desired) on the same >node. I think this would work quite well within the existing APIs >that we have designed for privacy addresses. My concern is that, in advocating use of CGAs for access control, we will effectively kill CGA use for privacy, for the reasons cited above. I don't mean to suggest that you are trying to preclude use of CGAs for privacy; I just see this as a likely, unintended side-efect. >>... > >There is also the possibility (that a few other people have raised >with me this week) that we could design an IKEv2 SPI type (I >apologize if that isn't quite the right terminology) that contains a >CGA and CGA parameters, and that information could be used to set-up >an IPsec SA. Not the right terminology, but let's not focus on that. I saw that Julien published an I-D that seems to have this flavor, although I have not read it. >I am not sure if a transition to IPsec is the best choice for very >short flows, though, such as the syslog or SNMP trap/inform use >cases in the draft. I would be interested in your opinion about the >trade-offs involved. Maybe. But one can establish an SA and reuse it over time, to amortize the SA establishment overhead. So, it depends. >I am not, personally, focusing on the exact details of our specific >proposal at this point. I am interested in discussing how/if CGAs >are a suitable mechanism to do one or both of the following things: > >1) Produce viable security mechanisms that are simpler to configure >than existing solutions. In many cases, this may only involve minor >extensions or tweaks to existing mechanisms (e.g. the new IKE SPI >type described above). > >2) Offer a practical alternative to the insecure Access Control >Lists (ACLs) that are still in wide use today. Part of being a >practical alternative (that will actually get deployed) is that >configuring the new solution cannot require considerably more work >or expertise than configuring an insecure ACL. > >Do those seem like reasonable goals to you? Do you think there is >some potential that we could accomplish these things using CGAs? I agree that address-based ACLs are insecure, and it would be nice to have better alternatives. Whether CGAs are a good choice for this depends on the the context in which the ACL is being used, since the context determines what alternatives are viable. For IPsec, we'll have to sees the detail of the proposal. We have seen a lot of interest in using the DNS, now that DNESEC is being more widely deployed, as a way to ease the configuration burden for secruity protocols like TLS and IPsec. So CGAs are not the only game in town, in this context. >>... > >I'm not sure which use cases would need to be scaled back in this >case and why. Could you explain a bit more? Sorry if I was not clear. I think that having an intermediate node challenge a host may be problematic. The host might not have a way to know the ID of an intermediate node, which creates the sort of DoS concern I cited. In contrast, a host can be expected to know the ID of the destination that it is attempting to reach, making these two cases potentially very different. >... >I am not creative/imaginative enough to believe that CGA access >control will replace TLS! :-) agreed. >>... > >CGAs have similar properties in this regard. They don't require >configuring certificates on end nodes, and they don't require >sending anyone any money. I share your preferences in this area. :-) good. >Using DNSSEC to resolve this problem is an interesting idea... Is >there a draft, paper or other published document that describes how >to do this? Or could you flesh it out a bit? I would be interested >in understanding this approach better, so that I could understand >the trade-offs between these two approaches. There was a bar BoF this week. We'll see what comes from that. Steve From kent@bbn.com Thu Jul 29 00:53:53 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95DB23A69C2; Thu, 29 Jul 2010 00:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijIKILZk3yrf; Thu, 29 Jul 2010 00:53:52 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 536C13A69AD; Thu, 29 Jul 2010 00:53:52 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:39281 helo=[130.129.114.216]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeNwU-0004U9-8S; Thu, 29 Jul 2010 03:54:14 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 29 Jul 2010 03:53:34 -0400 To: "Laganier, Julien" From: Stephen Kent Content-Type: multipart/alternative; boundary="============_-931732443==_ma============" Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 07:53:53 -0000 --============_-931732443==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >... > >[JL] I read the above RFC 3972 text as not negating the privacy >feature that can be afforded by periodically regenerating an IPv6 as >in RFC 3041. Thus a CGA might or might not have privacy feature, and >privacy is thus a feature that is orthogonal to CGAs. The central >feature of a CGA is that one can verify that host "owns" the address >(own in the sense that it's the one that generated in the first >place, i.e., it's not hijacked.) I agree that the primary motivation for CGAs arose in the SeND context, and that privacy is an independent feature. But, the context in which CGAs were intended to provide an ability to establish a binding to an IPv6 address was local. When one moves beyond this local context, and one advocates having more distant nodes challenge a host, this creates privacy questions. >... > >yes, it does, because the privacy is afforded by the host generating >a sequence of CGAs for parallel or serial use is in conflict with >use of a static CGA as an address space identifier for access >control purposes. > >[JL] I think we agree but differ on how we're expressing it. I'd say >that the use of static addresses in ACLs is in conflict with the >privacy afforded by being able to periodically regenerate an >address, as per 3041. Agreed. >I admit that I was not thinking about CGAs in the mobile IP context; >RFC 3972 does refer to mobile nodes, but does not say much in that >regard. RFC 4581, which updated 3972, never mentions mobile nodes. > >[JL] The use of CGA in the mobile IP context was documented later, >in RFC 4866 "Enhanced Route Optimization for Mobile IPv6". OK. >.... > >yes, one could do what you suggest above, but that would be >duplicating IPsec (ESP-NULL) functionality, which I hope would be >frowned upon :-). > >[JL] Well that could be all done based on IPsec, as you note below. Glad to see that we agree on this point. But, note that IKE specifically passes credentials (e.g., certs) only after establishing an encrypted channel. This was done to protect the user's asserted ID. Thus, if one uses a CGA as an ID (i.e., and input to an access control decision) with IPsec, one is undermining that privacy (traffic analysis countermeasure) feature of IPsec. >... > > >Mostly, but not quite. if a host is challenged to provide a signed >sequence of packets by a purported intermediary, how does the host >know that the challenge is legitimate, and not just a DoS attack? > >[JL] if there's execution of a key establishment protocol based on >the public keys bound to the CGAs, the opportunity for a DoS attack >is reduced and more in line with what's been done in the context of >BTNS. I'll have to think about that. >[JL] All of that being said, I agree that the requirement to use >static CGAs is a bad thing. That requirement could be removed if the >ACLs were based on the public keys generating the CGAs, rather than >the CGAs themselves. But if that were the case, coupled with the use >of a key establishment protocol, then it becomes dubious what is the >additional value provided by CGAs as IPsec seems to afford the >required security service: access control, integrity protection. I think I agree with your observation, which seems to undercut the "CGAs as inputs to ACLs" argument :-). Steve --============_-931732443==_ma============ Content-Type: text/html; charset="us-ascii" Re: [saag] [secdir] Interest in draft-dong-savi-cga-header
...
 
[JL] I read the above RFC 3972 text as not negating the privacy feature that can be afforded by periodically regenerating an IPv6 as in RFC 3041. Thus a CGA might or might not have privacy feature, and privacy is thus a feature that is orthogonal to CGAs. The central feature of a CGA is that one can verify that host "owns" the address (own in the sense that it's the one that generated in the first place, i.e., it's not hijacked.)

I agree that the primary motivation for CGAs arose in the SeND context, and that privacy is an independent feature. But, the context in which CGAs were intended to provide an ability to establish a binding to an IPv6 address was local. When one moves beyond this local context, and one advocates having more distant nodes challenge a host, this creates privacy questions.
 
...

 
yes, it does, because the privacy is afforded by the host generating a sequence of CGAs for parallel or serial use is in conflict with use of a static CGA as an address space identifier for access control purposes.
 
[JL] I think we agree but differ on how we're expressing it. I'd say that the use of static addresses in ACLs is in conflict with the privacy afforded by being able to periodically regenerate an address, as per 3041.

Agreed.

I admit that I was not thinking about CGAs in the mobile IP context; RFC 3972 does refer to mobile nodes, but does not say much in that regard. RFC 4581, which updated 3972, never mentions mobile nodes.
 
[JL] The use of CGA in the mobile IP context was documented later, in RFC 4866 "Enhanced Route Optimization for Mobile IPv6".

OK.
....
 
yes, one could do what you suggest above, but that would be duplicating IPsec (ESP-NULL) functionality, which I hope would be frowned upon :-).
 
[JL] Well that could be all done based on IPsec, as you note below.

Glad to see that we agree on this point. But, note that IKE specifically passes credentials (e.g., certs) only after establishing an encrypted channel. This was done to protect the user's asserted ID. Thus, if one uses a CGA as an ID (i.e., and input to an access control decision) with IPsec, one is undermining that privacy (traffic analysis countermeasure) feature of IPsec.

...

 
Mostly, but not quite. if a host is challenged to provide a signed sequence of packets by a purported intermediary, how does the host know that the challenge is legitimate, and not just a DoS attack?
 
[JL] if there's execution of a key establishment protocol based on the public keys bound to the CGAs, the opportunity for a DoS attack is reduced and more in line with what's been done in the context of BTNS.

I'll have to think about that.

[JL] All of that being said, I agree that the requirement to use static CGAs is a bad thing. That requirement could be removed if the ACLs were based on the public keys generating the CGAs, rather than the CGAs themselves. But if that were the case, coupled with the use of a key establishment protocol, then it becomes dubious what is the additional value provided by CGAs as IPsec seems to afford the required security service: access control, integrity protection.
 
I think I agree with your observation, which seems to undercut the "CGAs as inputs to ACLs" argument :-).

Steve
--============_-931732443==_ma============-- From hartmans@mit.edu Thu Jul 29 01:13:56 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B716F3A6A33; Thu, 29 Jul 2010 01:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9wMlxfI8cygA; Thu, 29 Jul 2010 01:13:51 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id 90C413A6990; Thu, 29 Jul 2010 01:13:51 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-23f1.meeting.ietf.org [130.129.35.241]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DFDA620393; Thu, 29 Jul 2010 04:14:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F0FC44133; Thu, 29 Jul 2010 04:14:13 -0400 (EDT) From: Sam Hartman To: Stephen Kent References: Date: Thu, 29 Jul 2010 04:14:13 -0400 In-Reply-To: (Stephen Kent's message of "Thu\, 29 Jul 2010 03\:53\:34 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:13:56 -0000 >>>>> "Stephen" == Stephen Kent writes: Stephen> I agree that the primary motivation for CGAs arose in the Stephen> SeND context, and that privacy is an independent Stephen> feature. But, the context in which CGAs were intended to Stephen> provide an ability to establish a binding to an IPv6 Stephen> address was local. When one moves beyond this local Stephen> context, and one advocates having more distant nodes Stephen> challenge a host, this creates privacy questions. I think we've been looking at CGAs that have non-local scope for a while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other protocols. It's my understanding that shim6 supports both HBAs and CGAs for non-local contexts. I also believe the MIP6 context for CGA use is non-local. From rbarnes@bbn.com Thu Jul 29 01:28:20 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5893E28C1C5; Thu, 29 Jul 2010 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.426 X-Spam-Level: X-Spam-Status: No, score=-2.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pi6eI-9GfBFS; Thu, 29 Jul 2010 01:28:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5C1D93A63C9; Thu, 29 Jul 2010 01:28:17 -0700 (PDT) Received: from [128.89.253.91] (port=49262 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OeOTj-0004iB-Le; Thu, 29 Jul 2010 04:28:35 -0400 Message-Id: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> From: "Richard L. Barnes" To: Sam Hartman In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 29 Jul 2010 10:28:34 +0200 References: X-Mailer: Apple Mail (2.936) Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 08:28:20 -0000 The thing I'm struggling with here is what value a CGA provides over a bare public key. The use of a CGA as a source address doesn't prove anything except that the entity that generated it had access to a given public key, which is nothing special. If you're going to get any security benefit, you either need 1. Out-of-band knowledge that SEND was applied in the relevant subnet, or 2. Some interaction that proves ownership of the private key In the second case, you might as well just use existing protocols for proving ownership of a key (IPsec, TLS); the first case is just a special case of the second, where the entity applying access control has a special relationship with the layer-2 network (kind of fragile). Either way, what you end up doing is validating that the entity holds a given private key, at which point the source address has nothing to do with the security of communications. tl;dr: CGAs don't have any security benefit without another protocol. What's the use case? --Richard On Jul 29, 2010, at 10:14 AM, Sam Hartman wrote: >>>>>> "Stephen" == Stephen Kent writes: > > Stephen> I agree that the primary motivation for CGAs arose in the > Stephen> SeND context, and that privacy is an independent > Stephen> feature. But, the context in which CGAs were intended to > Stephen> provide an ability to establish a binding to an IPv6 > Stephen> address was local. When one moves beyond this local > Stephen> context, and one advocates having more distant nodes > Stephen> challenge a host, this creates privacy questions. > > I think we've been looking at CGAs that have non-local scope for a > while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with > other > protocols. It's my understanding that shim6 supports both HBAs and > CGAs > for non-local contexts. I also believe the MIP6 context for CGA use > is > non-local. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From zhangdong_rh@huaweisymantec.com Thu Jul 29 03:32:50 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A326428C121 for ; Thu, 29 Jul 2010 03:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.705 X-Spam-Level: ** X-Spam-Status: No, score=2.705 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_57=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QbcJabkIFbW4 for ; Thu, 29 Jul 2010 03:32:45 -0700 (PDT) Received: from mta2.huaweisymantec.com (unknown [218.17.155.15]) by core3.amsl.com (Postfix) with ESMTP id 0200B28C0E7 for ; Thu, 29 Jul 2010 03:31:48 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-disposition: inline Content-type: text/plain; charset=us-ascii Received: from hstml02-in.huaweisymantec.com ([172.26.3.42]) by hstga02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L6B002U5ELA1F20@hstga02-in.huaweisymantec.com> for saag@ietf.org; Thu, 29 Jul 2010 18:31:59 +0800 (CST) Received: from huaweisymantec.com ([127.0.0.1]) by hstml02-in.huaweisymantec.com (Sun Java(tm) System Messaging Server 6.3-8.03 (built Apr 24 2009; 32bit)) with ESMTP id <0L6B000J7ELA5I20@hstml02-in.huaweisymantec.com> for saag@ietf.org; Thu, 29 Jul 2010 18:31:58 +0800 (CST) Received: from [130.129.117.201] by hstml02-in.huaweisymantec.com (mshttpd) ; Thu, 29 Jul 2010 18:31:58 +0800 From: ZhangDong To: saag@ietf.org Message-id: Date: Thu, 29 Jul 2010 18:31:58 +0800 X-Mailer: Sun Java(tm) System Messenger Express 6.3-8.03 (built Apr 24 2009; 32bit) Content-language: zh-CN X-Accept-Language: zh-CN Priority: normal Subject: [saag] An IPR declaration related to ietf-dong-savi-cga-header X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 10:32:50 -0000 Hi folks, This is an IPR declaration information for you. The IPR may be related to this draft. ------------------------------------------------ Patent Holder: Huawei Symantec Person Reporting IPR: Dong Zhang Huawei Symantec 3rd Floor,Section D Keshi Building, No.28, Xinxi Rd. Shangdi HaiDian district Beijing China Phone: +86-10-62721287 EMail: zhangdong_rh@huaweisymantec.com Relates To: draft-dong-savi-cga-header Status: Patent application pending Licensing Terms: TBD ------------------------------------------------- Tx. Dong Zhang From Hannes.Tschofenig@gmx.net Thu Jul 29 04:14:07 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 535923A69D7 for ; Thu, 29 Jul 2010 04:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33VIFI3yNf1h for ; Thu, 29 Jul 2010 04:14:06 -0700 (PDT) Received: from mail.gmx.net (mailout-de.gmx.net [213.165.64.23]) by core3.amsl.com (Postfix) with SMTP id BF9703A69ED for ; Thu, 29 Jul 2010 04:14:05 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2010 11:14:28 -0000 Received: from dhcp-85c8.meeting.ietf.org (EHLO [130.129.133.200]) [130.129.133.200] by mail.gmx.net (mp049) with SMTP; 29 Jul 2010 13:14:28 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX183y4BSg4o3g1PknIm3UlNtExnP/vuPIJNOSx6k+r p7jXuQgCtGmFEc Message-ID: <4C5162C5.8030905@gmx.net> Date: Thu, 29 Jul 2010 13:15:17 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: oauth@ietf.org References: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> Content-Type: multipart/alternative; boundary="------------090109030100030003090903" X-Y-GMX-Trusted: 0 Cc: saag@ietf.org, hasmat@ietf.org Subject: Re: [saag] [OAUTH-WG] OAuth Tutorial on Friday, 9am X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 11:14:07 -0000 This is a multi-part message in MIME format. --------------090109030100030003090903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The meeting room is 2.14 Amazon On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote: > > Hi all, > > As mentioned in the meeting agenda Blaine and myself thought it would > be useful to schedule a tutorial about OAuth during the IETF week. > > The morning slot (9am till max 11:30am) on Friday seems to be good. > > I will organize a meeting room. Details will be provided later. > > Ciao > Hannes & Blaine > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > --------------090109030100030003090903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit The meeting room is 2.14 Amazon

On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
OAuth Tutorial on Friday, 9am

Hi all,

As mentioned in the meeting agenda Blaine and myself thought it would be useful to schedule a tutorial about OAuth during the IETF week.

The morning slot (9am till max 11:30am) on Friday seems to be good.

I will organize a meeting room. Details will be provided later.

Ciao
Hannes & Blaine 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

--------------090109030100030003090903-- From leifj@mnt.se Thu Jul 29 04:28:11 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3B6E28C14F for ; Thu, 29 Jul 2010 04:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySRo+4KnNpzT for ; Thu, 29 Jul 2010 04:28:10 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by core3.amsl.com (Postfix) with ESMTP id 82CB028C14D for ; Thu, 29 Jul 2010 04:28:10 -0700 (PDT) Received: from [130.129.147.252] (dhcp-93fc.meeting.ietf.org [130.129.147.252]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id o6TBSTuP026356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Jul 2010 13:28:32 +0200 (CEST) Message-ID: <4C5165DD.3080400@mnt.se> Date: Thu, 29 Jul 2010 13:28:29 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9pre) Gecko/20100217 Lightning/1.0b1 Shredder/3.0.3pre MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] fedauth bof summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 11:28:11 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The fedauth BoF was held on Tuesday morning. We had a very packed schedule and an equally packed room. The goal of the BoF was WG formation. There was consensus around doing work in the IETF and consensus on the relevance of the problems. At the BoF and during post-game on the list a number of people have suggested alternatives to GSS-API as an application interface and the Charter will reflect that such proposals will be in scope for the WG. Work is progressing on a charter and WG name selection. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxRZd0ACgkQ8Jx8FtbMZnf/bgCeMWjHtMxdTVABM1Sg+Gt6CRFH BCAAnRkl59Of3B7IhopQRL8DH7Di3jxF =T/5I -----END PGP SIGNATURE----- From gregory.ietf@gmail.com Thu Jul 29 04:49:35 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 907B728C142; Thu, 29 Jul 2010 04:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.842 X-Spam-Level: X-Spam-Status: No, score=-101.842 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hqd1YdYsXj-2; Thu, 29 Jul 2010 04:49:34 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id C3E3728C12A; Thu, 29 Jul 2010 04:49:33 -0700 (PDT) Received: by ewy22 with SMTP id 22so85407ewy.31 for ; Thu, 29 Jul 2010 04:49:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type; bh=96EEQ34QofTKHHb68GLxJWD286Pt5v2VEO1T8t+9xQ8=; b=LaR61OuAq301x2ZNjogzv9grFeEiM/suvn4YdRI/85tKGkPxubeY0i8VAVun0ty7CE ZHsPrUP+ybHWxLUWlggxc0UQunaOspTMlqo8wRCL6BpBLc8gL2PY/nZfKzrUyDvMEhzP 7dZfnm/iJ/DLFlfxcP2kh/SxzzU8/iKVGRKtk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; b=KfZEP6HiRo418sXX1TZymxLb3Gctuve5SCh4NYQQcFJypoE1i9qsH/uI1uS0Ze6PJS VtzBAX81AWLVVwKlg8eMxDOKy6NsYZnc9WCx2LbXBjI6xcF7IKKm1Attwt+M38JjpM1L jmb2n9q0VM1ua+BlElnBS5BFs0W5NS8XwJMj0= Received: by 10.14.29.70 with SMTP id h46mr3195285eea.94.1280404189995; Thu, 29 Jul 2010 04:49:49 -0700 (PDT) Received: from dhcp-26d2.meeting.ietf.org (dhcp-26d2.meeting.ietf.org [130.129.38.210]) by mx.google.com with ESMTPS id v8sm1124675eeh.14.2010.07.29.04.49.48 (version=SSLv3 cipher=RC4-MD5); Thu, 29 Jul 2010 04:49:48 -0700 (PDT) Message-ID: <4C516ADB.6010501@gmail.com> Date: Thu, 29 Jul 2010 04:49:47 -0700 From: Gregory Lebovitz User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <3D3C75174CB95F42AD6BCC56E5555B45028698A0@FIESEXC015.nsn-intra.net> <4C5162C5.8030905@gmx.net> In-Reply-To: <4C5162C5.8030905@gmx.net> Content-Type: multipart/alternative; boundary="------------020208060804020405020404" Cc: hasmat@ietf.org, oauth@ietf.org, saag@ietf.org Subject: Re: [saag] [OAUTH-WG] OAuth Tutorial on Friday, 9am X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 11:49:35 -0000 This is a multi-part message in MIME format. --------------020208060804020405020404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hannes, Will the session be recorded, i.e. audio archive and notes/minutes created? I think this would be VERY useful. Gregory. On 7/29/10 4:15 AM, Hannes Tschofenig wrote: > The meeting room is 2.14 Amazon > > On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >> >> Hi all, >> >> As mentioned in the meeting agenda Blaine and myself thought it would >> be useful to schedule a tutorial about OAuth during the IETF week. >> >> The morning slot (9am till max 11:30am) on Friday seems to be good. >> >> I will organize a meeting room. Details will be provided later. >> >> Ciao >> Hannes & Blaine >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag -- ~~~~~~~~~~~~~~ IETF related Email from Gregory Lebovitz Juniper Networks --------------020208060804020405020404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hannes,
Will the session be recorded, i.e. audio archive and notes/minutes created? I think this would be VERY useful.

Gregory.

On 7/29/10 4:15 AM, Hannes Tschofenig wrote:
The meeting room is 2.14 Amazon

On 23.07.2010 11:23, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
OAuth Tutorial on Friday, 9am

Hi all,

As mentioned in the meeting agenda Blaine and myself thought it would be useful to schedule a tutorial about OAuth during the IETF week.

The morning slot (9am till max 11:30am) on Friday seems to be good.

I will organize a meeting room. Details will be provided later.

Ciao
Hannes & Blaine 


_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
  


_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


-- 
~~~~~~~~~~~~~~
IETF related Email from
Gregory Lebovitz
Juniper Networks
--------------020208060804020405020404-- From rgm-sec@htt-consult.com Thu Jul 29 05:04:10 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C112A3A69EB; Thu, 29 Jul 2010 05:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEnrMh02xS5p; Thu, 29 Jul 2010 05:04:09 -0700 (PDT) Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 7E04E3A69A2; Thu, 29 Jul 2010 05:04:09 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 7FB4D68B25; Thu, 29 Jul 2010 11:55:22 +0000 (UTC) Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSaOg4VCZEas; Thu, 29 Jul 2010 07:55:12 -0400 (EDT) Received: from nc2400.htt-consult.com (dhcp-60fb.meeting.ietf.org [130.129.96.251]) (Authenticated sender: rgm-sec@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 4BCBE68B24; Thu, 29 Jul 2010 07:55:11 -0400 (EDT) Message-ID: <4C516E42.9080103@htt-consult.com> Date: Thu, 29 Jul 2010 14:04:18 +0200 From: Robert Moskowitz User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4 MIME-Version: 1.0 To: "Richard L. Barnes" References: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> In-Reply-To: <20C6D044-08B8-4956-910A-D22C70819933@bbn.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Dong Zhang , "secdir@ietf.org" , PaddyNallur , "saag@ietf.org" , Margaret Wasserman , Sam Hartman Subject: Re: [saag] [secdir] Interest in draft-dong-savi-cga-header-03.txt; possibility of a five minute slot at saag? X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Jul 2010 12:04:10 -0000 On 07/29/2010 10:28 AM, Richard L. Barnes wrote: > The thing I'm struggling with here is what value a CGA provides over a > bare public key. My understanding MAY be incomplete, but... It looks like CGA generation binds the prefix to the key, thus there is a trust that the prefix has not been altered. I don't do that in HIT generation. Don't know if I should change HIT generation or not. I would need to look at the IPR around CGAs. > The use of a CGA as a source address doesn't prove anything except > that the entity that generated it had access to a given public key, > which is nothing special. If you're going to get any security benefit, > you either need > > 1. Out-of-band knowledge that SEND was applied in the relevant subnet, or > 2. Some interaction that proves ownership of the private key > > In the second case, you might as well just use existing protocols for > proving ownership of a key (IPsec, TLS); the first case is just a > special case of the second, where the entity applying access control > has a special relationship with the layer-2 network (kind of fragile). > > Either way, what you end up doing is validating that the entity holds > a given private key, at which point the source address has nothing to > do with the security of communications. > > tl;dr: CGAs don't have any security benefit without another protocol. > What's the use case? > > --Richard > > > > > On Jul 29, 2010, at 10:14 AM, Sam Hartman wrote: > >>>>>>> "Stephen" == Stephen Kent writes: >> >> Stephen> I agree that the primary motivation for CGAs arose in the >> Stephen> SeND context, and that privacy is an independent >> Stephen> feature. But, the context in which CGAs were intended to >> Stephen> provide an ability to establish a binding to an IPv6 >> Stephen> address was local. When one moves beyond this local >> Stephen> context, and one advocates having more distant nodes >> Stephen> challenge a host, this creates privacy questions. >> >> I think we've been looking at CGAs that have non-local scope for a >> while. Section 7.4 of RFC 3972 seems to anticipate CGAs used with other >> protocols. It's my understanding that shim6 supports both HBAs and CGAs >> for non-local contexts. I also believe the MIP6 context for CGA use is >> non-local. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From stefw@gnome.org Sat Jul 31 23:35:23 2010 Return-Path: X-Original-To: saag@core3.amsl.com Delivered-To: saag@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 920323A6818 for ; Sat, 31 Jul 2010 23:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.206 X-Spam-Level: X-Spam-Status: No, score=-0.206 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_40=-0.185, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIxJwuj9PMSV for ; Sat, 31 Jul 2010 23:35:20 -0700 (PDT) Received: from memberwebs.com (memberwebs.com [94.75.203.95]) by core3.amsl.com (Postfix) with ESMTP id AC76D3A67D9 for ; Sat, 31 Jul 2010 23:35:20 -0700 (PDT) Received: from [192.168.1.9] (a82-92-233-51.adsl.xs4all.nl [82.92.233.51]) by memberwebs.com (Postfix) with ESMTP id 0AAD683E4C5; Sun, 1 Aug 2010 06:35:27 +0000 (UTC) Message-ID: <4C5515AD.9020603@gnome.org> Date: Sun, 01 Aug 2010 08:35:25 +0200 From: Stef Walter User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5 MIME-Version: 1.0 To: Jan.Pechanec@Sun.COM, Darren.Moffat@Oracle.COM, saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [saag] I-D on PKCS#11 URI Scheme for naming objects X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2010 06:35:23 -0000 I work on gnome-keyring which is based around PKCS#11. We're working on an effort to use PKCS#11 as a common key and certificate storage standard for the GNOME Desktop. I'm interested in the PKCS#11 URI [1] RFC that you proposed. However, several questions come up about encoding. The standard states that semi-colons and backslashes should be escaped with back slashes. That fixes the problem of allowing semi-colons to be specified in object=xxx labels. However if there are spaces, tabs, or other special characters in the PKCS#11 URI should these be percent encoded? This is not made clear in the spec, but perhaps it's an assumption because of the reference to other URI RFCs. That said, one implementation I found in OpenSolaris libcryptoutil does not handle percent encoding or even the backslash style escaping [2]. I question the need for backslash style escaping of semi-colon suggested in the PKCS#11 URI proposal. In my opinion PKCS#11 URIs should just use percent encoding for semi-colons, similar to how you would percent encode a '?' character or space in a http: URL. Secondly, would it perhaps make sense to use percent encoding for the id= attribute? PKCS#11 URIs as proposed are introducing a colon style encoding. I noticed it's not defined whether there may be one hex character between colons or not. Percent encoding is a well defined encoding which removes such ambiguities. Looking forward to your comments. Cheers, Stef [1] http://tools.ietf.org/html/draft-pechanec-pkcs11uri-01 [2] http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libcryptoutil/common/pkcs11_uri.c#126