From turners@ieca.com Wed Mar 2 10:25:42 2011 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 B88173A67D3 for ; Wed, 2 Mar 2011 10:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 AVZhRG9LAQO1 for ; Wed, 2 Mar 2011 10:25:40 -0800 (PST) Received: from nm7-vm0.bullet.mail.ac4.yahoo.com (nm7-vm0.bullet.mail.ac4.yahoo.com [98.139.52.228]) by core3.amsl.com (Postfix) with SMTP id 7F2613A6844 for ; Wed, 2 Mar 2011 10:25:39 -0800 (PST) Received: from [98.139.52.188] by nm7.bullet.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 18:26:42 -0000 Received: from [98.139.52.181] by tm1.bullet.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 18:26:42 -0000 Received: from [127.0.0.1] by omp1064.mail.ac4.yahoo.com with NNFMP; 02 Mar 2011 18:26:42 -0000 X-Yahoo-Newman-Id: 663124.27743.bm@omp1064.mail.ac4.yahoo.com Received: (qmail 90440 invoked from network); 2 Mar 2011 18:26:42 -0000 Received: from thunderfish.local (turners@96.231.114.220 with plain) by smtp112.biz.mail.re2.yahoo.com with SMTP; 02 Mar 2011 10:26:42 -0800 PST X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: H4VkueAVM1l1V.NMpSq5U0ybCITIJP4hBhkso9rI8ndpibI cB.AMriVhLfynaCkCKWPytX9bhkG.8SAX92TyOpFQW1pyICewH_LtU1QWFL_ rYRmp1znvlPJJlzyyrXbTJ3FTn8F9ByzXwdj5Zsu54.z1Dgn2iOvfSAKgej5 u6GGikdhi13obwd4GmQFEAxQd7uoszwW8qf.Xog7usIdD8X.gkY3eCpNQiZM TbOXpTzhTWJPW9qKwWFpi3MTuPiOL9oBuOLsWUm03jFmebLdBy.132wXTbPF FAA0zAeA0JGtYdSvXB74s5opCbpcYYF58Ew-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D6E8BE1.4070006@ieca.com> Date: Wed, 02 Mar 2011 13:26:41 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: Phillip Hallam-Baker References: <4D57FA44.7070602@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: saag@ietf.org Subject: Re: [saag] Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS) 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, 02 Mar 2011 18:25:43 -0000 Well this draft is in the RFC editor queue: http://datatracker.ietf.org/doc/draft-turner-sha0-sha1-seccon/ spt On 3/2/11 12:20 PM, Phillip Hallam-Baker wrote: > What is the SAAG view as to what crypto algorithms are appropriate for > use at present? > > The reason I am asking is that this is being discussed in DANE and I > am seeing a lot of argument by analogy. The assumption seems to be > that since the legacy TLS infrastructure uses SHA1 and we cannot > currently change that because there is a huge amount of legacy that > DANE can also use SHA1 as it is 'plenty'. > > My view is that the Security Area Directorate should send a pretty > clear message that use of SHA1 is now deprecated and that: > > 1) Support for SHA1 should not be approved in future protocols without > a very compelling use case > > 2) New protocols should require support for SHA2-256 at the least. > > 3) Existing protocols should plan for a transition from SHA1 to a > stronger hash in a manner that is downwards compatible. > > > I don't think any of these is particularly controversial in the > security area. Although it must be pointed out that at present we do > not have a viable strategy for transitioning from SHA1 to SHA2. > > None of my customers is going to buy a certificate for SHA2 unless the > protocols allow a server to also support legacy browsers without SHA2 > support. Similarly, there is no value to introducing support for SHA2 > in new browsers, the only way to get value is by withdrawing SHA1 > support. > > > There are several approaches that could be used to address this issue > but none that seem to satisfy X.509 purists. > > > On Sun, Feb 13, 2011 at 10:35 AM, Sean Turner wrote: >> -------- Original Message -------- >> Subject: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS) >> Date: Fri, 11 Feb 2011 12:10:20 -0500 >> >> NIST announces the release of Draft Federal Information Processing >> Standard (FIPS) 180-4, Secure Hash Standard (SHS). >> Draft >> FIPS 180-4 is a proposed revision of FIPS 180-3. Draft FIPS 180-4 adds a >> general procedure for creating an initialization hash value and two >> additional secure hash algorithms: SHA-512/224 and SHA-512/256, and >> removes a requirement that padding must be done before hash computation >> begins. SHA-512/224 and SHA-512/256 may be more efficient alternatives >> to SHA-224 and SHA-256, respectively, on platforms that are optimized >> for 64-bit operations. Removing the restriction on the padding operation >> in the secure hash algorithms will potentially create more flexibility >> and efficiency in implementing the secure hash algorithms in many >> computer network applications. The Federal Register Notice (FRN) of this >> publication is located _here >> _. >> Examples of the implementation of the secure hash algorithms SHA-1, >> SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, can be >> found at http://www.nist.gov/CryptoToolkitExamples. >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > > > From paul.hoffman@vpnc.org Wed Mar 2 14:52:01 2011 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 11C2A3A68F6 for ; Wed, 2 Mar 2011 14:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.505 X-Spam-Level: X-Spam-Status: No, score=-101.505 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 X29R2kl2POuE for ; Wed, 2 Mar 2011 14:52:00 -0800 (PST) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 2019A3A68E9 for ; Wed, 2 Mar 2011 14:51:59 -0800 (PST) Received: from MacBook-08.local (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p22JaXxb019264 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 2 Mar 2011 12:36:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Message-ID: <4D6E9C41.5000704@vpnc.org> Date: Wed, 02 Mar 2011 11:36:33 -0800 From: Paul Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: saag@ietf.org References: <4D57FA44.7070602@ieca.com> <4D6E8BE1.4070006@ieca.com> In-Reply-To: <4D6E8BE1.4070006@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS) 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, 02 Mar 2011 22:52:01 -0000 On 3/2/11 12:20 PM, Phillip Hallam-Baker wrote: > The reason I am asking is that this is being discussed in DANE and I > am seeing a lot of argument by analogy. The assumption seems to be > that since the legacy TLS infrastructure uses SHA1 and we cannot > currently change that because there is a huge amount of legacy that > DANE can also use SHA1 as it is 'plenty'. This is a complete mischaracterization of the recent discussion on DANE. People should look at the archives () for the past two days instead of believing Phill's description. In specific, one person (Martin Rex) said that SHA-256, not SHA-1, was "plenty". No one has made any statements that back up Phill's supposed "assumption" other than to note that SHA-1 is still specified in recent RFCs. FWIW, I believe that Martin said that SHA-256 was plenty was responding to Phill's earlier message on the thread that said "We really do need SHA2 in here as a MUST" without specifying which algorithms of SHA2 needed to be mandated. That is, I think Martin was saying that SHA-256 was plenty, and we did not need to mandate SHA-384 or SHA-512. --Paul Hoffman From hallam@gmail.com Wed Mar 2 09:18:59 2011 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 5BB7A3A6810 for ; Wed, 2 Mar 2011 09:18:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.571 X-Spam-Level: X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 yLdG9ItEP0Cr for ; Wed, 2 Mar 2011 09:18:58 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id B6EC03A67E1 for ; Wed, 2 Mar 2011 09:18:57 -0800 (PST) Received: by bwz13 with SMTP id 13so420053bwz.31 for ; Wed, 02 Mar 2011 09:20:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pfmkNa5Y3KESh/IU/Oyx8rcvmH9SX5XA8/Itm5jKUZE=; b=iCA53ed+fMforr2QEK5ZQmCCHEOQHhQFP1GzU1aVPU5XaubIMlD+1nhoVCXz0BLZh/ q4W1KJ6Zbbg0An+mCBZfFmj/WhmYCsXygwZoYlj73V/8KficiCijr7qKiSZsi7taeMvT rV5MnkEi8VUYoS6U08cwt1yoBaSszPyTUrUZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JN5I9VUOOcrdnQYNdRC1T8SIPEin2eTVmMm8uJt7yhVxLlXPg+XTBH3wJfdG5byJ6H dxgDhJxpnOEuPqKr8Y3PwYS0ipqAPVOyvblqymKdZtyRenHIm/4vnrvOYpcAbZDqP/Oj 2OiZoldGQKVJC1AtYHrzCte00MuNcq5ZFF2z8= MIME-Version: 1.0 Received: by 10.204.103.196 with SMTP id l4mr227095bko.209.1299086403104; Wed, 02 Mar 2011 09:20:03 -0800 (PST) Received: by 10.204.14.139 with HTTP; Wed, 2 Mar 2011 09:20:03 -0800 (PST) In-Reply-To: <4D57FA44.7070602@ieca.com> References: <4D57FA44.7070602@ieca.com> Date: Wed, 2 Mar 2011 12:20:03 -0500 Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 04 Mar 2011 11:42:51 -0800 Cc: saag@ietf.org Subject: Re: [saag] Fwd: NIST releases Draft FIPS 180-4, Secure Hash Standard (SHS) 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, 02 Mar 2011 17:18:59 -0000 What is the SAAG view as to what crypto algorithms are appropriate for use at present? The reason I am asking is that this is being discussed in DANE and I am seeing a lot of argument by analogy. The assumption seems to be that since the legacy TLS infrastructure uses SHA1 and we cannot currently change that because there is a huge amount of legacy that DANE can also use SHA1 as it is 'plenty'. My view is that the Security Area Directorate should send a pretty clear message that use of SHA1 is now deprecated and that: 1) Support for SHA1 should not be approved in future protocols without a very compelling use case 2) New protocols should require support for SHA2-256 at the least. 3) Existing protocols should plan for a transition from SHA1 to a stronger hash in a manner that is downwards compatible. I don't think any of these is particularly controversial in the security area. Although it must be pointed out that at present we do not have a viable strategy for transitioning from SHA1 to SHA2. None of my customers is going to buy a certificate for SHA2 unless the protocols allow a server to also support legacy browsers without SHA2 support. Similarly, there is no value to introducing support for SHA2 in new browsers, the only way to get value is by withdrawing SHA1 support. There are several approaches that could be used to address this issue but none that seem to satisfy X.509 purists. On Sun, Feb 13, 2011 at 10:35 AM, Sean Turner wrote: > -------- Original Message -------- > Subject: =A0 =A0 =A0 =A0NIST releases Draft FIPS 180-4, Secure Hash Stand= ard (SHS) > Date: =A0 Fri, 11 Feb 2011 12:10:20 -0500 > > NIST announces the release of Draft Federal Information Processing > Standard (FIPS) 180-4, Secure Hash Standard (SHS). > Draft > FIPS 180-4 is a proposed revision of FIPS 180-3. Draft FIPS 180-4 adds a > general procedure for creating an initialization hash value and two > additional secure hash algorithms: SHA-512/224 and SHA-512/256, and > removes a requirement that padding must be done before hash computation > begins. SHA-512/224 and SHA-512/256 may be more efficient alternatives > to SHA-224 and SHA-256, respectively, on platforms that are optimized > for 64-bit operations. Removing the restriction on the padding operation > in the secure hash algorithms will potentially create more flexibility > and efficiency in implementing the secure hash algorithms in many > computer network applications. The Federal Register Notice (FRN) of this > publication is located _here > _. > Examples of the implementation of the secure hash algorithms SHA-1, > SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256, can be > found at http://www.nist.gov/CryptoToolkitExamples. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --=20 Website: http://hallambaker.com/ From tlr@w3.org Mon Mar 7 05:15:49 2011 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 12B593A6960 for ; Mon, 7 Mar 2011 05:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.669 X-Spam-Level: X-Spam-Status: No, score=-9.669 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8] 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 izTdfDFqDmHI for ; Mon, 7 Mar 2011 05:15:48 -0800 (PST) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 43F243A692C for ; Mon, 7 Mar 2011 05:15:47 -0800 (PST) Received: from [178.254.73.133] (helo=[192.168.2.115]) by jay.w3.org with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1PwaJ2-0002Te-MH; Mon, 07 Mar 2011 08:17:00 -0500 From: Thomas Roessler Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 7 Mar 2011 14:16:57 +0100 Message-Id: <90498B7B-E1F9-4C9E-BADE-1CE5C78366FD@w3.org> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [saag] W3C Candidate Recommendations for XML Signature, Encryption 1.1 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, 07 Mar 2011 13:15:49 -0000 For your information, W3C has announced Candidate Recommendations for = XML Signature and Encryption 1.1 last Friday: http://www.w3.org/News/2011#entry-9027 http://www.w3.org/TR/2011/CR-xmldsig-core1-20110303/ http://www.w3.org/TR/2011/CR-xmlenc-core1-20110303/ If you have any questions, please let me know. Thanks, -- Thomas Roessler, W3C (@roessler) From stephen.farrell@cs.tcd.ie Thu Mar 17 11:05:25 2011 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 842923A6A04; Thu, 17 Mar 2011 11:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 LBwlgCCMlrCK; Thu, 17 Mar 2011 11:05:24 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 8F63B3A6ADA; Thu, 17 Mar 2011 11:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 644DC3E4074; Thu, 17 Mar 2011 18:06:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1300385207; bh=vok3oqaPGcTcP7fG+mkt9NPv d8EeCnNACHFXiSE+dyY=; b=XyOn+3afvsZ4/2FLrDZvcU7tAIoYf1AYbEbjreo4 rBkSDBGBrhtnwNYAY5+Ky6gQPXVNfbzrWa41A61HqLBnm/EEAcpQrFSHj/jTN/4j VH421ffzwkDJx6zIkCvr3WfunXeRvEAr7ECp30PQ3/J+oWMfY+D5SU8vu8u6ghFw NOR1CuvHsghGjjAkm/TkFFlSsn5HaWxmDsHo00ffbVIXkKqwYMtc9I4Wz2gAejdv vDNNQB2VN7m+8VUyVEYyUbFAhf3YWG+6aWrCUnr8OIqwmjDEjzp0PUSks12dG4bC EqnB69Oh7+VDitx+N7Z/g8YMpByxy4ENJRXz7F9qG/B43g== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id D4TEWx5Zq9LA; Thu, 17 Mar 2011 18:06:47 +0000 (GMT) Received: from [10.87.48.6] (unknown [86.41.7.122]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 367B73E4072; Thu, 17 Mar 2011 18:06:47 +0000 (GMT) Message-ID: <4D824DB6.50705@cs.tcd.ie> Date: Thu, 17 Mar 2011 18:06:46 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Working Group Chairs , "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sec-ads@ietf.org Subject: [saag] SEC-AD changes for WGs 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, 17 Mar 2011 18:05:25 -0000 Hi all, Since Tim is stepping down and I'll be taking over we needed to redistribute WG duties. The list below is where we ended up. Sean: dkim, emu, isms, msec, pkix, tls, ltans, ipsecme Stephen: abfab, dane, hokey, kitten, krb, nea I guess this'll be formalised in a couple of weeks. Regards, Stephen. From turners@ieca.com Fri Mar 18 11:22:04 2011 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 BE0373A69CD for ; Fri, 18 Mar 2011 11:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 jHR+8T+jZoxN for ; Fri, 18 Mar 2011 11:22:03 -0700 (PDT) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by core3.amsl.com (Postfix) with SMTP id D49563A69B7 for ; Fri, 18 Mar 2011 11:22:02 -0700 (PDT) Received: from [98.139.52.193] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:23:29 -0000 Received: from [98.139.52.166] by tm6.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:23:29 -0000 Received: from [127.0.0.1] by omp1049.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:23:29 -0000 X-Yahoo-Newman-Id: 201534.66046.bm@omp1049.mail.ac4.yahoo.com Received: (qmail 71867 invoked from network); 18 Mar 2011 18:23:21 -0000 Received: from thunderfish.local (turners@96.231.126.170 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 18 Mar 2011 11:23:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: Q0jYrcAVM1n0Ux8R6mQCA9xP_lsIZjENWk5d_gfIdGlfy4s QTTD3KEmqDf6S2fMIWtav24xZd2DegFNKlRpkCbx7kK_gBdfji4lL8ycMc3_ HjzHkgfH3Hu7o.VZJUF4Nr.NpvjPxL8rYEsgFc1a440KkNB..TFGLsxXuSsh kK5E5YOCL04aM2vdCF39GH8NbXzYT8sJ8u6shsPT1rYc0px1HuxtVU73rHBq hc7EgTmLrTViy5Bm42ZO5Yx0mVTZG_jvhNSKy7HAtOlHMsmvGUbgGhzhP1qC 8HgJbiTMHIRV_.Hg.7jebqoa1uPsw.Zzz X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D83A318.6040505@ieca.com> Date: Fri, 18 Mar 2011 14:23:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Tuesday Lunch Room 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, 18 Mar 2011 18:22:04 -0000 We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00) for our Security Directorate meeting. See you all there, spt From turners@ieca.com Fri Mar 18 11:55:29 2011 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 EB4823A6A08 for ; Fri, 18 Mar 2011 11:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 N3MfGvssqcuS for ; Fri, 18 Mar 2011 11:55:29 -0700 (PDT) Received: from nm21-vm0.bullet.mail.ac4.yahoo.com (nm21-vm0.bullet.mail.ac4.yahoo.com [98.139.53.216]) by core3.amsl.com (Postfix) with SMTP id 345CB3A6999 for ; Fri, 18 Mar 2011 11:55:29 -0700 (PDT) Received: from [98.139.52.192] by nm21.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:56 -0000 Received: from [98.139.52.135] by tm5.bullet.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:56 -0000 Received: from [127.0.0.1] by omp1018.mail.ac4.yahoo.com with NNFMP; 18 Mar 2011 18:56:56 -0000 X-Yahoo-Newman-Id: 34965.65262.bm@omp1018.mail.ac4.yahoo.com Received: (qmail 10030 invoked from network); 18 Mar 2011 18:56:09 -0000 Received: from thunderfish.local (turners@96.231.126.170 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 18 Mar 2011 11:56:09 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: dX8Ump4VM1mbdh22I.MfF8iNpxTAnIycYg1YCg4BtQbHMJj FN4Q9fML6T78.zvSjQaaIP4RFOw5Js4rFd7ZaPXfniE5j3Qsyx4FNUcuMLqG KsNJQyyIpdnVoZ5daENhU8D0g2veD2b4SXGRjhLT8PmGNmMBNr1S5dsmIP66 IibAK8TUiQBwHr0YR0jtFy8nwB021VsiMToi89I1wtyvQauuCZph9n8FyRRU gJC3DxWTnulb8wyCSpaZAWLrDjS7Wp_jeVB8c26QasyUCpRupIZpdQR4awDz ArnV7I0m1PMw3Z3cJByfuE9L9Rkx4NiHdpYuvkgUsPalEEjpK8ZoCc.g- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D83AAC7.4020105@ieca.com> Date: Fri, 18 Mar 2011 14:56:07 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: saag@ietf.org References: <4D83A318.6040505@ieca.com> In-Reply-To: <4D83A318.6040505@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [saag] Tuesday Lunch Room 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, 18 Mar 2011 18:55:30 -0000 So that was means for the security directorate. My bad. spt On 3/18/11 2:23 PM, Sean Turner wrote: > We've been assigned Tyrolka on Tuesday, March 29th (11:30-13:00) > for our Security Directorate meeting. > > See you all there, > > spt > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From turners@ieca.com Mon Mar 28 01:15:45 2011 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 5A8603A68A2 for ; Mon, 28 Mar 2011 01:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, UNPARSEABLE_RELAY=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 Pmknc0PYF2Yq for ; Mon, 28 Mar 2011 01:15:44 -0700 (PDT) Received: from nm10-vm0.bullet.mail.sp2.yahoo.com (nm10-vm0.bullet.mail.sp2.yahoo.com [98.139.91.198]) by core3.amsl.com (Postfix) with SMTP id 985E73A6950 for ; Mon, 28 Mar 2011 01:15:44 -0700 (PDT) Received: from [98.139.91.61] by nm10.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:17:22 -0000 Received: from [98.139.91.30] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:17:22 -0000 Received: from [127.0.0.1] by omp1030.mail.sp2.yahoo.com with NNFMP; 28 Mar 2011 08:17:22 -0000 X-Yahoo-Newman-Id: 244802.52786.bm@omp1030.mail.sp2.yahoo.com Received: (qmail 15564 invoked from network); 28 Mar 2011 08:17:22 -0000 Received: from dhcp-1598.meeting.ietf.org (turners@198.180.150.234 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 28 Mar 2011 01:17:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: VUwVasQVM1mFDbx0gMmzdk0yLQGVuD2xv1FID4txVTbG39r MDzSemsU0CuNtzqxOuVVrZ6KeYLEhokRCBODeIf4cOaelZuDp3solOR.5jkv lnbwcNqZqrVb5PDS5VC_XhnknnMYAXdf.rQMrB0GN2e4m6Ztlb_yGQppe22_ uJwoMUSTnQO.6CgFB0WaCCESS6BKvC712txCycVvczIGC1BoZebRvRzBRf52 kywcTfUT59pMIb2OIGd73I90XSr2.sz6YqPCYIPUQWy6H0HJGFAb6dziJlNp DeYKDjVaE_IR3JvYISj0THYU7hrYBNfFcQyJo2JRzGdRUJt27qWwmcbgyEtM h_AEu.URdq1227FnNYFZr9DEtOPZB.7OzQNBtrydu X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D904358.5060409@ieca.com> Date: Mon, 28 Mar 2011 10:14:16 +0200 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] WOES Bar 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, 28 Mar 2011 08:15:45 -0000 I just wanted to let everybody know about the WOES Bar BOF: * Room: Karlin I * Date: 20:00 on Monday, 28th March 2011 * Relevant documents: - http://www.ietf.org/id/draft-rescorla-jsms-00.txt - http://tools.ietf.org/html/draft-jones-json-web-token-01 List info: - https://www.ietf.org/mailman/listinfo/woes spt From barryleiba@gmail.com Mon Mar 28 05:59:10 2011 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 61E073A6A2C for ; Mon, 28 Mar 2011 05:59:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.097 X-Spam-Level: X-Spam-Status: No, score=-103.097 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 e4maPyCj+QzD for ; Mon, 28 Mar 2011 05:59:09 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 79BC43A6842 for ; Mon, 28 Mar 2011 05:59:09 -0700 (PDT) Received: by iye19 with SMTP id 19so3527757iye.31 for ; Mon, 28 Mar 2011 06:00:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:content-type; bh=6MGd8FlJTZ3mbuPcpjRwOXO7JL8FyEy1g+7XPP9oD2A=; b=j+Lv6GF1JJpomudMeXB5WcEUIosamFORkLrBMNmbN9eIbTXzkPqFHoDuWvHCuonbd+ rfsX9dHkbYal/aQT/16HfKGIWiN0n0uOSg941R4FlvMstXBduYPBOgw4FUhdm4EqLBix 6zCdeexcB/Io2jkWIHMVhNZa4HCpSFT1E78Gs= 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:content-type; b=pjvRUBz5pvUKR3oqP+emMnR/OR6iZqWKuSTHzkLu60no92AJ0wIWjic0lJ4meP0Usz BOXWziWOZTzPk7rXtskEmDZHip0gmXYZtoNFHnlr3+gNsnyba3vln/e+jjacmIyJlkaf g7j81sXbbJ/KpvVqeaG9X4yc2exAHXp3+37/M= MIME-Version: 1.0 Received: by 10.231.128.199 with SMTP id l7mr3905442ibs.150.1301317246885; Mon, 28 Mar 2011 06:00:46 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.19.193 with HTTP; Mon, 28 Mar 2011 06:00:46 -0700 (PDT) Date: Mon, 28 Mar 2011 09:00:46 -0400 X-Google-Sender-Auth: _ym7QpIg-uWq7BiCA3Ge5JrWNIA Message-ID: From: Barry Leiba To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] DKIM meeting summary for IETF 80 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, 28 Mar 2011 12:59:10 -0000 DKIM working group session, IETF 80 (Prague), Monday, 28 March 2011. Murray gave status of the implementation report document (includes interoperability). There are no issues with this document. It will not be last-called, but will only be used to support the 4871bis advancement. As such, it will be recorded on the IESG page with other interoperability reports. We reviewed the changes to 4871bis since the last reviewed version. The editors believe they have all the open issues addressed. Three remaining changes required after discussion. The schedule is set for changes to be made by 10 April, WGLC after an updated version is posted. Murray listed some questions he has as editor of the mailing-lists document. We resolved all but one. Remaining question is whether it should be Informational or BCP. Decision is BCP, while making it clear when we're insufficiently certain about something. The schedule is set for changes to be made by 10 April, WGLC after an updated version is posted. We discussed the future of the working group. Two charter items (3 and 4) not yet done, dealing with ADSP and updates to the Informational deployment/operations documents. Consensus in room and jabber is to close. Will confirm on the mailing list. Tony noted that there are changes to deployment/overview docs because changes in 4871bis. We can handle those before the WG closes, or Stephen (as AD) will sponsor that as an individual submission. -- Barry, DKIM chair From stpeter@stpeter.im Mon Mar 28 15:40:08 2011 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 153413A6A8F; Mon, 28 Mar 2011 15:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, 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 jdEsfE0UHkk9; Mon, 28 Mar 2011 15:40:06 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AFEF33A6970; Mon, 28 Mar 2011 15:40:06 -0700 (PDT) Received: from dhcp-12cb.meeting.ietf.org (64-103-25-233.cisco.com [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D2A824006D; Mon, 28 Mar 2011 16:43:20 -0600 (MDT) Message-ID: <4D910EA5.5070804@stpeter.im> Date: Tue, 29 Mar 2011 00:41:41 +0200 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: IETF discussion list , saag@ietf.org, websec@ietf.org, "ietf-http-wg@w3.org Group" X-Enigmail-Version: 1.1.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050202020503080702040104" Subject: [saag] FW: HTTP authentication side meeting 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, 28 Mar 2011 22:40:08 -0000 This is a cryptographically signed message in MIME format. --------------ms050202020503080702040104 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For those at IETF 80 interested in HTTP and authentication, there will be a side meeting on Wednesday night for more in-depth discussion than will be possible during the SAAG session on Thursday. Logistics are 20:00 in Karlin II/III. Further details below... -------- Original Message -------- Subject: Re: [http-auth] side meeting on Wednesday, March 30 Date: Tue, 29 Mar 2011 02:37:30 +0900 From: Yutaka OIWA To: http-auth@ietf.org Dear all, I'm looking forward to seeing you at 20:00 Wednesday in Karlin II/III. My current plan for the side meeting is to mutually know each other's face by meeting face-to-face, and to share the problem space which is broken now = and which is to be fixed by our future working group (hopefully). The important point here is that the solutions must be not only implementable to the HTTP client/server, but also deployable and usable by Web applications. I believe this is the most problematic point of current largely-unused solutions including TLS client certificate authentication. I will prepare a small presentation which will describe *my* view of what should be done. Your opinions and views are very welcome. Also, I am waiting of inputs for the possible future agenda quoted below.= See you, Yutaka -------- Original Message -------- Subject: Re: [http-auth] HTTP Auth Next BOF at IETF Prague deadline Monday/Possible W3C Workshop? Date: Mon, 31 Jan 2011 20:54:37 +0900 From: Yutaka OIWA To: Harry Halpin CC: http-auth@ietf.org Dear Harry and all, "Harry Halpin" writes: > Another idea would be to hold an informal bar-BOF at Prague if the BOF > can't be put together quickly enough as a bar-BOF would require less wo= rk > and give us more time to bake the tech ideas or charter. I'll leave thi= s > decision in the hands of more experienced IETF folks. In both ways, anyway, we will need a good-direction proposal and agenda. It is hard for me to write a "good" one, but I made a "bad" :-) one as a starting point. Please consider it for improvements and rephrasing. Thanks Harry for providing a very good descriptions which I've used as a staring point. * Things to consider: - agenda not yet written - goal: currently ambiguous (intentionally); to discuss, or to form WG= ? -------- Description: The current authentication methods used in the Web system is prone to various serious vulnerabilities, including password eavesdropping, password stealing, session hijack, and phishing. Because of the lack of a good/secure support for web application authentication in the HTTP layer, people tends to use HTML forms for authentication, which are by nature insecure. This problem should be solved as soon as possible to mitigate the impact of Web authentication-related frauds to the Internet users. However, to solve this problem, the resulting technologies should be carefully designed so that these will be well deployable to the real-world applications. Recently we have several new proposals for securing Web/HTTP authentications, some of which has a proposed drafts. In addition, the work of the HTTPBIS working group is about to finish, and it will require some maintenance works for the HTTP existing authentication mechanism, at least the registrations to IANA. The purpose of the proposed BoF is to pursue creation of IETF working groups on various HTTP authentication issues. The possible topics of the future working group may include the following topics: * Introduction of much more secure authentication mechanisms as extensions to the HTTP. * Introduction of technologies which will enable more sophisticated use of HTTP authentication in application layer. * Research on the secure ways of Web/HTML authentications and required protocol-side support for them * Maintenance of existing HTTP authentication extensions (other than Basic and Digest), either checking its httpbis-conforming or making it historic. * Proposing addition of authentication schemes to the IANA registry as proposed by httpbis. Both BoF and possible future working group expect well coordination with W3C's effort on the related topics. BoF proposed agenda: * Topics to be discussed in the future working group * TBD Logistical informations: BoF Chairs: TBD BOF Proponents: Harry Halpin, Yutaka OIWA, ... (TBD) People expected: 50 Length of session: 90min Conflicts to avoid: Working Groups in the APP and SEC areas WebEX: no Responsible AD: Peter Saint-Andre, Alexey Melnikov (tentative) Goal: to pursue creation of IETF working groups Drafts: http://tools.ietf.org/html/draft-oiwa-http-mutualauth-08; more to be discussed Mailing List: HTTP http-auth mailing list Mailing List Archive: http://www.ietf.org/mail-archive/web/http-auth/ -------- --=20 Yutaka OIWA, Ph.D. Research Scienti= st Research Center for Information Security (RCI= S) National Institute of Advanced Industrial Science and Technology (AIS= T) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46= B5] _______________________________________________ http-auth mailing list http-auth@ietf.org https://www.ietf.org/mailman/listinfo/http-auth --------------ms050202020503080702040104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3 MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/ jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q 7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo 98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR 6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV 0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD 0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri 2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6 wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1 nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2 gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1 My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo 6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3 GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6 2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4 TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0 ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+ 39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c 6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2 0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0 H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0 dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDMy ODIyNDE0MVowIwYJKoZIhvcNAQkEMRYEFNrbJXE8lqhNYZ+XgY1qKEUiZaN5MF8GCSqGSIb3 DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG 9w0BAQEFAASCAQCl/FJrSxy4PIh6wM6NdiayDFhpmOwN2nGN7612Hi3wNGpi+hS+Zg+Rq9A9 uiRSTQDJntNxIxjTL4r24n44f6fYQDvW3OAZ3n/t8Mxv8Te3/R7BhVEn/rB0j5xBxtLZAUXX LvwTYFr4l6X9Uk3VcJfAEAl8/Bl09dhXBjifvcs356HmCD97GTxCq3KHfofiWGN3PNlXvopT s1b7WYQkVeYozVIL+D7z0Px/YvPy+v9zLhgMffiq0WvjJYZtbhjqKjDlS63hkCYNFYHo8LlJ NIDdW/fIQP1pePd/zGCpnkn8YLcm4ougqmi9DmNwujkh0K7p3hoYOdCVYA/AyPaiBT1xAAAA AAAA --------------ms050202020503080702040104-- From yaronf.ietf@gmail.com Tue Mar 29 06:10:14 2011 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 C77663A6811; Tue, 29 Mar 2011 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 3BzZc0j4A7g7; Tue, 29 Mar 2011 06:10:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B19FF3A6784; Tue, 29 Mar 2011 06:10:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so208259fxm.31 for ; Tue, 29 Mar 2011 06:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=VFv4KQU+9KOWfrMIp3y13VLv4voFmQVpQHx+F46WKNg=; b=GUCuI134YaD5wUDyt8ZLXlwU2aXijmSJxJUBEB62cVMCWDgHamrv5HYKHN+bHSV9xR BUMkm3BJkOXGTwy0tB31V0lvRQOmiycrZtAuxNDN/lp9U3WA1XRSJQ1+NGNIM7EPHY8N b0ehiIQu/OK1Sf07fenK2uZD1Rcfyoafj5JcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=RUIGL06d8N2xEHH0YC+X++2uwOdYP6BYquB3okXzGTIoaIWCqcIHSGDwAzICVK/CaX t+PAUDh8B1naBil6BAX/9xN6q4xZ+ntgxhoyeSIQlZACV8MQDe8Cf6y9WoISWVn+5SiC mnPO75Omdo5gzZ/hAETAgXaFMA0Jek1WaUgvQ= Received: by 10.223.159.142 with SMTP id j14mr5861455fax.40.1301404294372; Tue, 29 Mar 2011 06:11:34 -0700 (PDT) Received: from [10.0.0.5] (85-250-59-87.bb.netvision.net.il [85.250.59.87]) by mx.google.com with ESMTPS id n15sm1967418fam.12.2011.03.29.06.11.33 (version=SSLv3 cipher=OTHER); Tue, 29 Mar 2011 06:11:33 -0700 (PDT) Message-ID: <4D91DA83.1030506@gmail.com> Date: Tue, 29 Mar 2011 15:11:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: [saag] IPsecME summary for 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, 29 Mar 2011 13:10:14 -0000 The IPsecME WG is not meeting in Prague this week. We sent our "failure detection" draft to the IESG, and it should be moving to the RFC Editor soon. Our last chartered document, the "high availability protocol" extension, recently left WG Last Call and should be in IETF Last Call in the near future. Regards, Paul and Yaron From tena@huawei.com Tue Mar 29 07:36:03 2011 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 5075D3A67D3 for ; Tue, 29 Mar 2011 07:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.561 X-Spam-Level: X-Spam-Status: No, score=-103.561 tagged_above=-999 required=5 tests=[AWL=-0.962, BAYES_00=-2.599, 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 1VSco-Sf8DIW for ; Tue, 29 Mar 2011 07:36:02 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 054AD3A6824 for ; Tue, 29 Mar 2011 07:36:02 -0700 (PDT) Received: from huawei.com (usaml01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIT003ITPYSGP@usaga01-in.huawei.com> for saag@ietf.org; Tue, 29 Mar 2011 09:37:40 -0500 (CDT) Received: from TingZousc1 ([130.129.19.214]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIT00I0TPYQLN@usaga01-in.huawei.com> for saag@ietf.org; Tue, 29 Mar 2011 09:37:40 -0500 (CDT) Date: Tue, 29 Mar 2011 16:37:03 +0200 From: Tina Tsou To: saag@ietf.org Message-id: <032b01cbee1e$db2fbec0$918f3c40$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: multipart/mixed; boundary="Boundary_(ID_9Gvoc5Yqmif14HANWowHwA)" Content-language: en-us Thread-index: AcvtSj5fCN1Dung0Tz2uaWNeq8bp/QA04q+AAAA5RsA= x-cr-hashedpuzzle: ApHi B2l9 CMpD DpUm DwbB E4st GQhY Gafg Ghps G8aj IsDO IsJr I+fR JnWw Jsro KT3+; 1; cwBhAGEAZwBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {CC416201-AEF0-4BF4-98B0-CFAA6C2062A1}; dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A; Tue, 29 Mar 2011 14:37:01 GMT;RgBXADoAIABbAHMAZQBjAGQAaQByAF0AIABSAGUAbQBpAG4AZABlAHIA x-cr-puzzleid: {CC416201-AEF0-4BF4-98B0-CFAA6C2062A1} Subject: [saag] FW: [secdir] Reminder 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, 29 Mar 2011 14:36:03 -0000 This is a multi-part message in MIME format. --Boundary_(ID_9Gvoc5Yqmif14HANWowHwA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi all, Hokey's summary is attached. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html --Boundary_(ID_9Gvoc5Yqmif14HANWowHwA) Content-type: text/plain; name="Hokey-80 meeting minutes.txt" Content-transfer-encoding: 7BIT Content-disposition: attachment; filename="Hokey-80 meeting minutes.txt" Glen and Tina presiding. NOTE WELL presented. Agenda accepted. Status ====== Glen Zorn. Chair noted that architecture document is moribund. Concerned that authors are acting as a design team rather than being driven by list discussion. Asked to bring issues to the list instead of just discussing internally. LDN discovery being discussed by IESG. 5296bis: IPSecme pressing for changes -- Chair feels this is not appropriate, but if members of HOKEY wished to create drafts on the subject that would be OK. RFC5296bis ========== Qin Wu presenting. Slides. History Changes Simplifying bootstrapping -- no comments on proposed resolution -- to the list -- if no comment thewre, go ahead with proposal MAY vs. SHOULD in sec. 5.3.1.1 -- Tom Taylor noted that SHOULD must be accompanied by text explaining under what circumstances the action would not be taken. Remove distinction between local and home -- Yoav Nir -- Should support cross-domain, IETF view -- Glen as Chair -- doesn't see that one WG would set policy for all -- Klaas, co-Chair of abfab -- agreed -- Glen as individual -- has never understood relevance of home vs. visited for ERP EAP Re-authentication Protocol Extensions for Authenticated Anticipatory Keying (ERP/AAK) ============================================================ Zhen Cao Reviewed changes Proposed that draft is ready for WGLC -- Qin Wu -- supports move forward -- Glen -- will await any further comments on list to mid-April, if none received, go to WGLC --Boundary_(ID_9Gvoc5Yqmif14HANWowHwA)-- From hallam@gmail.com Tue Mar 29 17:37:09 2011 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 0BC523A6AF3 for ; Tue, 29 Mar 2011 17:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.559 X-Spam-Level: X-Spam-Status: No, score=-4.559 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 xVbdNr+YkDYh for ; Tue, 29 Mar 2011 17:37:07 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id D01AE3A6AF2 for ; Tue, 29 Mar 2011 17:37:06 -0700 (PDT) Received: by vws12 with SMTP id 12so723479vws.31 for ; Tue, 29 Mar 2011 17:38:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pcfhQAZD1b4pyAF9Tu/uyNP0Jp4A42YD72t9SjdmGOc=; b=e3pI+HQd69bj3sHbykJqDWMSnB2Orhu/S7fFfB4FJKknuPxxBSTfQ5HatZLAA7SA38 ZricBP5bbPLroZa7pxi6noGEldalmXIn/PQedZCIouoH7+oXe6L/BXF8nSgd330x/C7d tNrghieqdG2IFIBoY52kr237KblhtLnmwTN7k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=o0CwAhbsnq+EG4mYxnFm8OWgMFiIJjoqUZIOMy0z4v2Wp6PE91h7vwqJSrc5XQ0akO P4GeZr0xSw8ndNYAO76zbs4G4/ek2Fv3LljSHyndWcBaprNs5i2XV3ujiyyLBk8vTj4/ iexBZiCn53BkIHnWcwWlqSwGqMt7ZmrI7i0wU= MIME-Version: 1.0 Received: by 10.52.100.39 with SMTP id ev7mr628030vdb.218.1301445524906; Tue, 29 Mar 2011 17:38:44 -0700 (PDT) Received: by 10.52.167.135 with HTTP; Tue, 29 Mar 2011 17:38:44 -0700 (PDT) In-Reply-To: References: Date: Wed, 30 Mar 2011 02:38:44 +0200 Message-ID: From: Phillip Hallam-Baker To: Sean Turner Content-Type: multipart/alternative; boundary=bcaec50163b934e18b049fa8661a Cc: saag@ietf.org Subject: Re: [saag] Why not XML? Was: WOES Bar 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: Wed, 30 Mar 2011 00:37:09 -0000 --bcaec50163b934e18b049fa8661a Content-Type: text/plain; charset=ISO-8859-1 The main question that came up in the justification for the WG was whether we could not do the same thing in XML or ASN.1. Here is an attempt at a rationale: The most important letter in XML is the X. It stands for eXtensible and a mechanism that is designed to encode structured data in an extensible format is necessarily more complex than one that is only designed to support encoding of a list of tag-value pairs. Thus XML and ASN.1 are necessarily more complex than the mechanisms discussed at the BOF. XML and ASN.1 are necessarily more complex than a list of tag-value pairs, but most of the objections come from the fact that they are also more complex in ways that are unnecessary. The mapping from a C# data structure to a XML or a ASN.1 reification can be effected by a purely automated means. But there are many ways of effecting such a mapping. Should values be encoded as tag content or attributes? How should types be used? etc. etc. I have seen people attempt to use XML as if it maps directly onto the type mechanism of C++ or Java and plough on for years before they finally get the fact that what is called a 'type' in XML is actually a type of a type and so they have been talking complete nonsense. The original design goal of XML was not to create a new data format, rather it was an attempt to take out the worst and the most damaging and the obviously insane features of SGML. XML succeeded in this mission without introducing too much additional cruft. But somehow the inane prefixing scheme did get introduced and that is a non-trivial pain in the patootie. XML prefixing is an example of a bad idea that was turned into a worse one. The original intent was not too bad but the consequences were. XML achieves 'extensibility' by allowing one schema to include another with a statement that essentially goes 'include XMLDSIG and prefix their tags by xds'. This would be OK, I guess if the variation that resulted was limited to the schema level, but no, this did not happen. Instead, we require the data structures in the final encoded data to also carry prefixes. Even in the case that no ambiguity arises between the tags. SAML links to XMLDigSig and XML Encryption and the scars where the parts of the Frankensteinian monster are still visible in every SAML assertion. It is not possible in XML schema to say 'include DSIG as if written out verbatim here'. It is not even possible to say 'include DISG and always use this specific prefix'. No the choice of prefix goes to whoever generates the final data. As a result, XML parsers are indeed trivial to write. But only if you don't have to track namespace prefixes at which point the whole thing becomes much, much more than just knocking out a FSM which I can do for XML in about 30 mins and have working in an hour. Managing namespaces properly is non trivial. Similar objections apply to ASN.1. I can knock together an asn.1 encoder/decoder for a given ASN.1 structure quite quickly. Provided that is, that the encoder is not having to deal with included ASN.1 objects, then the problem becomes hard. Lots of corner cases start to show up and the whole thing becomes a massive tooth ache and its time to call time on the whole thing. I have quite a lot of experience in XML and ASN.1 and I can knock together a solution for JSON in far less time than I can spend explaining the intricate gotchas and misery that are to be fond in ASN.1 or XML. If we are working on a rich platform, we can of course use generic packages that will assemble code for us. XML is natural to use on .NET because we can simply write our data structures out in C# and call a method that will throw out an encoder or a decoder for us. A masochist could no doubt do the same for ASN.1. But on the smaller platforms, we don't have that option. In particular, many, many compact S/MIME and TLS 'implementations' do not process ASN.1 at all. Certificates are simply an opaque bag of bits that the implementation does not understand at all. The public key data are pre-extracted for them. Processing of CMS is vestigial. This type of implementation is usually limited to generation of data structures or consumption of data from sources that understand the limitations of the receiver. But they are still quite common. In many cases the people who code them are working on the basis of a suck-it-and-see methodology in which success is declared when the code does not croak. Such implementations can often be coded quite quickly and will work acceptably well for the intended purpose. And are frequently used as an existence proof for 'can do CMS in 4 hours' or the like. But nobody can read the CMS spec thoroughly in 4 hours, let alone implement. --bcaec50163b934e18b049fa8661a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The main question that came up in the justification for t= he WG was whether we could not do the same thing in XML or ASN.1. Here is a= n attempt at a rationale:

The most important letter in XML is the X. It stands for eXt= ensible and a mechanism that is designed to encode structured data in an ex= tensible format is necessarily more complex than one that is only designed = to support encoding of a list of tag-value pairs. Thus XML and ASN.1 are ne= cessarily more complex than the mechanisms discussed at the BOF.

XML and ASN.1 are necessarily more complex than a list = of tag-value pairs, but most of the objections come from the fact that they= are also more complex in ways that are unnecessary.

The mapping from a C# data structure to a XML or a ASN.1 reification c= an be effected by a purely automated means. But there are many ways of effe= cting such a mapping. Should values be encoded as tag content or attributes= ? How should types be used? etc. etc.

I have seen people attempt to use XML as if it maps dir= ectly onto the type mechanism of C++ or Java and plough on for years before= they finally get the fact that what is called a 'type' in XML is a= ctually a type of a type and so they have been talking complete nonsense.

The original design goal of XML was not to create a new= data format, rather it was an attempt to take out the worst and the most d= amaging and the obviously insane features of SGML. XML succeeded in this mi= ssion without introducing too much additional cruft. But somehow the inane = prefixing scheme did get introduced and that is a non-trivial pain in the p= atootie.

XML prefixing is an example of a bad idea that was turn= ed into a worse one. The original intent was not too bad but the consequenc= es were.

XML achieves 'extensibility' by a= llowing one schema to include another with a statement that essentially goe= s 'include XMLDSIG and prefix their tags by xds'.=A0

This would be OK, I guess if the variation that resulte= d was limited to the schema level, but no, this did not happen. Instead, we= require the data structures in the final encoded data to also carry prefix= es. Even in the case that no ambiguity arises between the tags. SAML links = to XMLDigSig and XML Encryption and the scars where the parts of the Franke= nsteinian monster are still visible in every SAML assertion. It is not poss= ible in XML schema to say 'include DSIG as if written out verbatim here= '. It is not even possible to say 'include DISG and always use this= specific prefix'. No the choice of prefix goes to whoever generates th= e final data.

As a result, XML parsers are indeed trivial to write. B= ut only if you don't have to track namespace prefixes at which point th= e whole thing becomes much, much more than just knocking out a FSM which I = can do for XML in about 30 mins and have working in an hour. Managing names= paces properly is non trivial.

Similar objections apply to ASN.1. I can knock together= an asn.1 encoder/decoder for a given ASN.1 structure quite quickly. Provid= ed that is, that the encoder is not having to deal with included ASN.1 obje= cts, then the problem becomes hard. Lots of corner cases start to show up a= nd the whole thing becomes a massive tooth ache and its time to call time o= n the whole thing.

I have quite a lot of experience in XML and ASN.1 and I= can knock together a solution for JSON in far less time than I can spend e= xplaining the intricate gotchas and misery that are to be fond in ASN.1 or = XML.

If we are working on a rich platform, we can of course = use generic packages that will assemble code for us. XML is natural to use = on .NET because we can simply write our data structures out in C# and call = a method that will throw out an encoder or a decoder for us. A masochist co= uld no doubt do the same for ASN.1. But on the smaller platforms, we don= 9;t have that option.

In particular, many, many compact S/MIME and TLS 'i= mplementations' do not process ASN.1 at all. Certificates are simply an= opaque bag of bits that the implementation does not understand at all. The= public key data are pre-extracted for them. Processing of CMS is=A0vestigi= al.=A0

This type of implementation is usually limited to gener= ation of data structures or consumption of data from sources that understan= d the limitations of the receiver. But they are still quite common. In many= cases the people who code them are working on the basis of a suck-it-and-s= ee methodology in which success is declared when the code does not croak.

Such implementations can often be coded quite quickly a= nd will work acceptably well for the intended purpose. And are frequently u= sed as an existence proof for 'can do CMS in 4 hours' or the like. = But nobody can read the CMS spec thoroughly in 4 hours, let alone implement= .
--bcaec50163b934e18b049fa8661a-- From stefan@aaa-sec.com Wed Mar 30 18:26:31 2011 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 45ACF3A6AAE for ; Wed, 30 Mar 2011 18:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 oxZULYyGaHIX for ; Wed, 30 Mar 2011 18:26:30 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id C51B53A692C for ; Wed, 30 Mar 2011 18:26:29 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id E66692E9DF3 for ; Thu, 31 Mar 2011 03:27:29 +0200 (CEST) Received: (qmail 41550 invoked from network); 31 Mar 2011 01:27:19 -0000 Received: from gwa-prague.hotel-opera.cz (HELO [192.168.42.198]) (stefan@fiddler.nu@[78.80.10.158]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Mar 2011 01:27:19 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 31 Mar 2011 03:27:16 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: Channel binding - Applet use case In-Reply-To: <032b01cbee1e$db2fbec0$918f3c40$@com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [saag] Channel binding - Applet use case 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, 31 Mar 2011 01:26:31 -0000 All, As I spoke about at the Secir lunch, here is a channel binding solution for the applet use case that I would like to discuss at saag if possible. http://aaa-sec.com/_temp/CHannel%20binding_Applet_02.pdf As I fear that time will not permit this to take up time at the saag meeting, but I would welcome as much comments as possible. Not only just on the proposal as such, but whether a solution to this use case could have it's place in an RFC. The problem is to protect a user, having contact with a service provider through a browser and an applet from MitM attacks. Part of this use case is that the Applet provider is part of a secure infrastructure, capable of validating signatures of legitimate service providers. The user has an assumed MitM free channel to a service provider. This service provider responds with an html page including an Applet tag with signed parameters. The signed parameters includes a the signed end point channel bindings of the server. The signed applet is loaded from the Applet Provider (AP) and is given the signed parameters from the server. 1) The Applet retrieves the browsers server certificate and compares this with the signed channel bindings from the server without validating the signature (it is assumed that the applet don't have a TA for this verification. The applet opens a second secure channel to the service provider. This might be another host than the one communicating with the browser. The Applet receives a signed challenge from the SP. 2) The applet generates a public/private key pair and uses the pre-stored public key of the AP to encrypt a bunch of signed data to the AP - TLS Session ID of the A-AP session (to prevent replay attacks) - Its own version (to prevent downgrade attacks by handing the user an old applet) - Its public key (to allow an encrypted response - The signed channel bindings and challenge received from the SP - It's own observed channel bindings for its two secure channels This is only sent if the applet agrees with the channel bindings received for the SP-Browser session 3) The AP validates the signatures from the SP hosts and determines that these originates from a valid SP. The AP also verifies the channel binding and session data from the applet. Upon match the AP creates a signed response to the challenge from the Applet-SP session, including the channel bindings observed by the applet and also signs the signed channel bindings from the Browser-SP session. 4) The Applet decrypt the data from AP and verifies its signatures. Upon success it relay the data to the SP. 5) The SP verifies the response against its own observed channel bindings towards the Applet and also verifies that the signed end point bindings obtained from the SP server in the SP-Browser channel is consistent with a legitimate SP web server. The applet can now assume that both the browser-SP channel and the applet-SP channel are consistent with one legitimate SP and MitM free. The applet will also know that it has a MitM free channel to the AP. The user will rely on this being setup properly simply by validating the signature of the signed applet. The user can now use the applet to authenticate to the AP to obtain security services from the AP to assist the user in its engagement with the SP such as payments. A key in this use case is that the user never should need to authenticate to the SP to obtain channel binding of both channels to the SP. /Stefan From shanna@juniper.net Wed Mar 30 23:48:32 2011 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 E731328C257 for ; Wed, 30 Mar 2011 23:48:32 -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 kvzUVYBvjmtI for ; Wed, 30 Mar 2011 23:48:32 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id D955F28C255 for ; Wed, 30 Mar 2011 23:48:31 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKTZQkIk+94V753ciFqqNv3XYwNZigXaS8@postini.com; Wed, 30 Mar 2011 23:50:11 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 30 Mar 2011 23:47:06 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Thu, 31 Mar 2011 02:48:39 -0400 From: Stephen Hanna To: "saag@ietf.org" Date: Thu, 31 Mar 2011 02:48:36 -0400 Thread-Topic: NEA summary for IETF 80 Thread-Index: AcvvAfR00HSnxed5Qpe+49RFRYkDzQAbUkNw 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" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [saag] NEA summary for IETF 80 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, 31 Mar 2011 06:48:33 -0000 nea wg met on Tuesday from 1300 to 1500. We reviewed several proposed PT protocol candidates. The authors of the TLS-based transports have agreed to merge their proposals to create a consensus proposal. There was consensus in the room to accept the outcome of that merger as a WG document. For the EAP-based transport, we still have two competing proposals, one using TLVs and AVPs to carry the NEA exchange and one using an EAP method to carry it. We agreed to document the pros and cons of these two approaches. That should help us decide. Of course, all decisions made at the meeting will be confirmed on the email list. Thanks, Steve Hanna From alexey.melnikov@isode.com Thu Mar 31 00:40:33 2011 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 B04A828C264 for ; Thu, 31 Mar 2011 00:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, 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 TsB-lB+c9yJX for ; Thu, 31 Mar 2011 00:40:32 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 8F67D28C262 for ; Thu, 31 Mar 2011 00:40:32 -0700 (PDT) Received: from [130.129.20.248] (dhcp-14f8.meeting.ietf.org [130.129.20.248]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 31 Mar 2011 08:42:11 +0100 Message-ID: <4D94303A.60601@isode.com> Date: Thu, 31 Mar 2011 09:41:46 +0200 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: "saag@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] PLASMA BOF summary for IETF 80 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, 31 Mar 2011 07:40:33 -0000 PLASMA BOF was held on Tuesday afternoon. Its goal is to move various S/MIME policy enforcement related logic from MUAs to a policy server, which has some nice side effects like allowing non X.509-based authentication (e.g. SAML based) from MUAs to the policy server, as well as message revocation before the message is read and changes to the list of intended recipients once in transit. Despite some original concerns that that work is only of interest to a limited group of people, the BOF was well attended and there was active participation in the dicussion of related use cases. Some interest was expressed to use ABFAB-capable solution together with the policy server. One AD has expressed concerns of why sending secure email can't be done using just websites (without SMTP at all), so that there is no need to use S/MIME. Proponents answered that users still like to use email for many tasks, so building upon/ fixing existing secure email is a desired goal. At the end of the BOF several participants (in addition to the BOF proponents) expressed their desire to work on something in this space. Several people were also interested in use of the proposed architecture for non email cases (e.g. with XMPP or for website access controls). As there was no strong consensus that a working group was to be formed, the proposed charter was not discussed. This will be done on the mailing list at an appropriate time. Paul & Alexey, BOF co-chairs. From bew@cisco.com Thu Mar 31 00:54:09 2011 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 43E1B3A6B1F for ; Thu, 31 Mar 2011 00:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.505 X-Spam-Level: X-Spam-Status: No, score=-110.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 c5PgyvvVSeiB for ; Thu, 31 Mar 2011 00:54:08 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 192833A6B1C for ; Thu, 31 Mar 2011 00:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=916; q=dns/txt; s=iport; t=1301558147; x=1302767747; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=s5450KvmLjm7sB5pVAGusLxVM/hxrqZtTZ5/DUg92VQ=; b=YSWMJTaYnVuIBw39sp3yqg5ib2ERsUsO0k5z6/t8vDS0EHWc5giwKkNi TJ7UBv/1AvrfMNhwaQJoRcbfKBqmSwMNWgVmGuJHQVrEku8RuD8gOWGF7 HdHxw/c4HvW1H+VBbVk2zbos393bHZXI6ihZt2nDI/ZodrHK+EMW7MrC3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au0HAEIylE2rRDoG/2dsb2JhbACYTI0Dd6JfnAeFawSFQYdQ X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="421451102" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 31 Mar 2011 07:55:44 +0000 Received: from sjc-vpn2-49.cisco.com (sjc-vpn2-49.cisco.com [10.21.112.49]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2V7thVr002074 for ; Thu, 31 Mar 2011 07:55:44 GMT From: Brian Weis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 00:55:43 -0700 Message-Id: To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [saag] MSEC summary for IETF 80 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, 31 Mar 2011 07:54:09 -0000 MSEC met on Tuesday late afternoon. We discussed one WG draft, an update = to GDOI. The latest version had substantive changes related to the safe = use of counter modes in a group with multiple senders. It will go = through another short WG last call to review those changes, and then be = progressed. Two individual drafts were discussed. The first changes IANA = rules for MIKEY name spaces, primarily relaxing the rules from some of = the registries to "Specification Required". This relaxation seems = appropriate as updates to the MIKEY all seem to be coming from = specifications published outside of the IETF. The second draft presents = a protocol for adapting GDOI to be an IKEv2 exchange. Consensus of the = WG was that both documents should be published, but are likely to be = progressed as individual drafts so that MSEC can finish its work and = shut down. Brian & Vincent, co-chairs= From hartmans@mit.edu Thu Mar 31 01:23:54 2011 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 846C83A6B2C for ; Thu, 31 Mar 2011 01:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.223 X-Spam-Level: X-Spam-Status: No, score=-103.223 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 4WrztzAc3ejg for ; Thu, 31 Mar 2011 01:23:53 -0700 (PDT) Received: from mail.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by core3.amsl.com (Postfix) with ESMTP id BB1383A6826 for ; Thu, 31 Mar 2011 01:23:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-527c.meeting.ietf.org [130.129.82.124]) (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 1E9292043D for ; Thu, 31 Mar 2011 04:22:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 904264541; Thu, 31 Mar 2011 04:25:30 -0400 (EDT) From: Sam Hartman To: saag@ietf.org Date: Thu, 31 Mar 2011 04:25:30 -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] krb-wg session susmmary 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, 31 Mar 2011 08:23:54 -0000 Summary written by Jeff Hutzelman: The Kerberos WG met on Tuesday afternoon. We reviewed status of current documents, including anonymous, which has just completed a WGLC on a post-last-call change to introduce a means of advertising support for anonymous PKINIT, and referrals, which underwent substantial changes in the most recent revision and really needs more review before it can move forward. We had a discussion of assignment policies for registries to be created by the IANA document, and spent some time discussing the proposed charter update. From jsalowey@cisco.com Thu Mar 31 01:29:40 2011 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 15DF53A6C2A for ; Thu, 31 Mar 2011 01:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ulL8shgvB1tH for ; Thu, 31 Mar 2011 01:29:38 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 61A1F3A6C29 for ; Thu, 31 Mar 2011 01:29:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=773; q=dns/txt; s=iport; t=1301560278; x=1302769878; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=gA4qPXpNrsjJw65H+LG1PRNe4lfUGtUGZD2/ea+YFOM=; b=eCfGnuhy17vc1Ssio9QpTsFZyMevJJ7YjYbZr8tgY6fzcJfrmp+KisWD +ItWjVoZNTf07UTV1z+3XNWZpR4TIGbZMyfUKCLmjrB8zBUKCbdAjBoF2 idBI4DP050ffqpGIJRjmgax2SRdyta07dvWnF6b/B3cU5XU7gyggpEDE5 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwSAOg6lE2tJV2d/2dsb2JhbAAgmCyNA3eiTJwEgn6CbQSFQYdQ X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="228184677" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2011 08:31:17 +0000 Received: from dhcp-452e.meeting.ietf.org (rtp-vpn6-1782.cisco.com [10.82.254.252]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2V8VGil021479 for ; Thu, 31 Mar 2011 08:31:17 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 01:32:53 -0700 Message-Id: <26039500-2508-4599-841C-58D0A07B83C4@cisco.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] EMU Summary for IETF 80 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, 31 Mar 2011 08:29:42 -0000 EMU met on Wednesday afternoon. We discussed a problem in the = definition of the Session ID for EAP-SIM and EAP-AKA fast = re-authentication. A new document may be needed to update the base = documents to fix the issue. We discussed the attribute format for EAP = channel bindings. The approach selected in the meeting will be = verified on the list. The document also needs input on 802.11 related = bindings. We had presentations on two tunnel method candidates; = EAP-TEAM and EAP-FASTv2. The two methods are very similar. A = consensus call in the meeting showed a preference for EAP-FASTv2 which = will be verified on the list. The meeting concluded with a presentation = on an Identity-Based Authenticated Key Exchange called EAP-IBAKE. =20 From jsalowey@cisco.com Thu Mar 31 03:56:32 2011 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 D7CB73A68B1 for ; Thu, 31 Mar 2011 03:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cIQC6Pz+Swwm for ; Thu, 31 Mar 2011 03:56:32 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C6D713A6B2D for ; Thu, 31 Mar 2011 03:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=846; q=dns/txt; s=iport; t=1301569091; x=1302778691; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=UVsnrPggDm1XHokpn34rAAORj0gNtHgN6203ug0l54g=; b=LDDoMxWWL8ayn55wFRAsb8vZsepBpkJa8ig8AjSJDVkQy2zKVjDM8wOl quPTGkzf81BYwbkCFf1TeNQErPy4ZXMkGpV20MN0zHAnO3+v27ME9Aj1q 1+6ShP1vG1zTgrmutoesGRpPncPfbo9Gfj3Nvd7LOHO8njmeOtlUcyU4C 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUGACBdlE2Q/khNgWdsb2JhbACYTI0BFAEBFiYlolCcDoVrBIVBh1A X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="81624462" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 31 Mar 2011 10:58:10 +0000 Received: from dhcp-452e.meeting.ietf.org (ams3-vpn-dhcp5894.cisco.com [10.61.87.5]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2VAwAYK018908 for ; Thu, 31 Mar 2011 10:58:10 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 31 Mar 2011 03:59:48 -0700 Message-Id: <16C537A9-77CD-42F3-B89A-333080931506@cisco.com> To: saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [saag] TLS Summary for IETF 80 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, 31 Mar 2011 10:56:32 -0000 TLS met on Wednesday afternoon. We had an update of open issues with = the DTLS 1.2 document. Most issues are resolved, but a few need be = posted on the list for review. We discussed a charter update for TLS = and a proposed charter will be sent to the list. We had a presentation = on next protocol negotiation. There was interest in the document. We = discussed some AES-CCM cipher suites that have been updated since last = meeting. The was no objection to the documents so the chairs need to = decide if the documents should go through the working group or not. = There was a presentation on using EAP in the TLS handshake that met with = a lot of resistance. We had an update on renegotiation patch deployment = status. We closed with a brief discussion of a extension that supports = multiple OCSP responses.= From ekr@rtfm.com Thu Mar 31 04:03:35 2011 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 96DC53A6B2D for ; Thu, 31 Mar 2011 04:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.948 X-Spam-Level: X-Spam-Status: No, score=-102.948 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 cITJu2k1o1xH for ; Thu, 31 Mar 2011 04:03:35 -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 DFC893A68B1 for ; Thu, 31 Mar 2011 04:03:34 -0700 (PDT) Received: by iwn39 with SMTP id 39so2626083iwn.31 for ; Thu, 31 Mar 2011 04:05:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.149.65 with SMTP id u1mr2776716icv.439.1301569514411; Thu, 31 Mar 2011 04:05:14 -0700 (PDT) Received: by 10.42.217.2 with HTTP; Thu, 31 Mar 2011 04:05:14 -0700 (PDT) Date: Thu, 31 Mar 2011 13:05:14 +0200 Message-ID: From: Eric Rescorla To: saag@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [saag] TLS 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: Thu, 31 Mar 2011 11:03:35 -0000 TLS met on Wednesday afternoon. We had an update of open issues with the DTLS 1.2 document. Most issues are resolved, but a few need be posted on the list for review. We discussed a charter update for TLS and a proposed charter will be sent to the list. We had a presentation on next protocol negotiation. There was interest in the document. We discussed some AES-CCM cipher suites that have been updated since last meeting. The was no objection to the documents so the chairs need to decide if the documents should go through the working group or not. There was a presentation on using EAP in the TLS handshake that met with a lot of resistance. We had an update on renegotiation patch deployment status. We closed with a brief discussion of a extension that supports multiple OCSP responses. From leifj@mnt.se Thu Mar 31 04:14:46 2011 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 309CB3A68B1 for ; Thu, 31 Mar 2011 04:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 48zPwppFJO32 for ; Thu, 31 Mar 2011 04:14:45 -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 2EB4828C11E for ; Thu, 31 Mar 2011 04:14:43 -0700 (PDT) Received: from [130.129.8.61] (dhcp-903d.meeting.ietf.org [130.129.8.61] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id p2VBGJWv027679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2011 13:16:23 +0200 (CEST) Message-ID: <4D946283.6010703@mnt.se> Date: Thu, 31 Mar 2011 13:16:19 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] abfab ietf80 status 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, 31 Mar 2011 11:14:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 abfab met twice this week. The first session was devoted to architecture and use-case documents. The first session got a report from the moonshot project which is one implementation of abfab technology. Work in moonshot is progressing very quickly and has demonstrated abfab for both SSH, LDAP and XMPP. The second session was devoted to review of the core documents and new proposed wg documents. Work in the wg is progressing well. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UYn8ACgkQ8Jx8FtbMZndORACfbwwsH8Dg3kQk2qiw2r1NNLOX M68AmwTQFCznDx1FdERhAlk7bHIGP0u4 =qaut -----END PGP SIGNATURE----- From stefan@aaa-sec.com Thu Mar 31 04:36:06 2011 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 1BA8F3A6906 for ; Thu, 31 Mar 2011 04:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.249 X-Spam-Level: X-Spam-Status: No, score=-103.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 2YfDz6pyGc66 for ; Thu, 31 Mar 2011 04:36:04 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id 82DB13A6875 for ; Thu, 31 Mar 2011 04:36:04 -0700 (PDT) Received: from s29.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 34F2E2B790F for ; Thu, 31 Mar 2011 13:37:46 +0200 (CEST) Received: (qmail 35362 invoked from network); 31 Mar 2011 11:37:41 -0000 Received: from dhcp-11b7.meeting.ietf.org (HELO [130.129.17.183]) (stefan@fiddler.nu@[130.129.17.183]) (envelope-sender ) by s29.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Mar 2011 11:37:41 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 31 Mar 2011 13:37:37 +0100 From: Stefan Santesson To: Message-ID: Thread-Topic: [saag] Channel binding - Applet use case In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [saag] Channel binding - Applet use case 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, 31 Mar 2011 11:36:06 -0000 Had an interesting discussion about this at lunch and it basically drills down to the applet's ability to retrieve the browsers end-point channel bindings (The server certificate used by the browser to connect with the SP). It seems that this is not possible for some browsers, including IE. A major objective for this discussed solution is to make sure that the browser and the applet talk to the same SP entity on a MitM free channel. So this is a serious issue. Any thoughts on ways around this problem or are we essentially screwed? /Stefan On 11-03-31 3:27 AM, "Stefan Santesson" wrote: >All, > >As I spoke about at the Secir lunch, here is a channel binding solution >for the applet use case that I would like to discuss at saag if possible. > >http://aaa-sec.com/_temp/CHannel%20binding_Applet_02.pdf > >As I fear that time will not permit this to take up time at the saag >meeting, but I would welcome as much comments as possible. >Not only just on the proposal as such, but whether a solution to this use >case could have it's place in an RFC. > > >The problem is to protect a user, having contact with a service provider >through a browser and an applet from MitM attacks. >Part of this use case is that the Applet provider is part of a secure >infrastructure, capable of validating signatures of legitimate service >providers. > > >The user has an assumed MitM free channel to a service provider. This >service provider responds with an html page including an Applet tag with >signed parameters. The signed parameters includes a the signed end point >channel bindings of the server. > >The signed applet is loaded from the Applet Provider (AP) and is given the >signed parameters from the server. > >1) The Applet retrieves the browsers server certificate and compares this >with the signed channel bindings from the server without validating the >signature (it is assumed that the applet don't have a TA for this >verification. The applet opens a second secure channel to the service >provider. This might be another host than the one communicating with the >browser. The Applet receives a signed challenge from the SP. > >2) The applet generates a public/private key pair and uses the pre-stored >public key of the AP to encrypt a bunch of signed data to the AP > >- TLS Session ID of the A-AP session (to prevent replay attacks) >- Its own version (to prevent downgrade attacks by handing the user an old >applet) >- Its public key (to allow an encrypted response >- The signed channel bindings and challenge received from the SP >- It's own observed channel bindings for its two secure channels > >This is only sent if the applet agrees with the channel bindings received >for the SP-Browser session > >3) The AP validates the signatures from the SP hosts and determines that >these originates from a valid SP. The AP also verifies the channel binding >and session data from the applet. Upon match the AP creates a signed >response to the challenge from the Applet-SP session, including the >channel bindings observed by the applet and also signs the signed channel >bindings from the Browser-SP session. > >4) The Applet decrypt the data from AP and verifies its signatures. Upon >success it relay the data to the SP. > >5) The SP verifies the response against its own observed channel bindings >towards the Applet and also verifies that the signed end point bindings >obtained from the SP server in the SP-Browser channel is consistent with a >legitimate SP web server. > > >The applet can now assume that both the browser-SP channel and the >applet-SP channel are consistent with one legitimate SP and MitM free. >The applet will also know that it has a MitM free channel to the AP. > >The user will rely on this being setup properly simply by validating the >signature of the signed applet. > >The user can now use the applet to authenticate to the AP to obtain >security services from the AP to assist the user in its engagement with >the SP such as payments. >A key in this use case is that the user never should need to authenticate >to the SP to obtain channel binding of both channels to the SP. > >/Stefan > > > > > > > > > >_______________________________________________ >saag mailing list >saag@ietf.org >https://www.ietf.org/mailman/listinfo/saag From stephen.farrell@cs.tcd.ie Thu Mar 31 04:39:06 2011 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 BD2A53A6B3B for ; Thu, 31 Mar 2011 04:39:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.932 X-Spam-Level: X-Spam-Status: No, score=-106.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 OQt2iFrLnJwz for ; Thu, 31 Mar 2011 04:39:05 -0700 (PDT) Received: from scss.tcd.ie (hermes.cs.tcd.ie [134.226.32.56]) by core3.amsl.com (Postfix) with ESMTP id DCE4E3A6906 for ; Thu, 31 Mar 2011 04:39:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 2BBDB3E407E for ; Thu, 31 Mar 2011 12:40:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:subject:mime-version :user-agent:from:date:message-id:received:received: x-virus-scanned; s=cs; t=1301571642; bh=z3xQApB3t7PK+JN4PLtoDMO+ Zvb+BtNJCw4ybodu/bY=; b=ulG4gbYRXYVlkdySR0rpMeQdG8BM88HvuAinm0gG Vxt8j722ryGOPGAWLcL+Hlteku5rNAx0R/8ZqPiHyMDMgbUVcIZMbbCuPsmektk2 JWD1zx8HTJU8uqJSD5p82UBZ6dH5RNCrnfTMb+g7F6chd6dthY+MDcpp9Rqv39Oa 6pG3XzqahVxO28ZkeDg+8n8VLR2Odzz0vkeXd1O8woDiyFW+H2lb2m4rb5Xclw+W 3fzJ6fyYOEejR3GZI7I+qYdRPBRq+A44AagoMND9MDdSHn9DRzWSIq5v1Fru1XNR 562dcUgM/YgZumzMPvfWJ+NwfHyKSVAA3iM/xd/KIwjitQ== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id wMPULO1EsYWK for ; Thu, 31 Mar 2011 12:40:42 +0100 (IST) Received: from [130.129.39.94] (dhcp-275e.meeting.ietf.org [130.129.39.94]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id CBEE43E406F for ; Thu, 31 Mar 2011 12:40:42 +0100 (IST) Message-ID: <4D946824.4070208@cs.tcd.ie> Date: Thu, 31 Mar 2011 12:40:20 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "saag@ietf.org" X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [saag] transparent new AD 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, 31 Mar 2011 11:39:06 -0000 Hi folks, Like I just said at the mic in saag some people were wondering how a poor academic type could afford to do the AD job. Well, its thanks to an EU FP7 networking research project called SAIL [1] that'll be covering most of my travel and time costs for the next couple of years. (And I should thank the project co-ordinator, Ericsson, for agreeing to let me change plan a bit to do this after the project started.) Any questions about that, feel free to ask off list. Cheers, Stephen. [1] http://sail-project.eu/ From stefan@aaa-sec.com Thu Mar 31 05:37:11 2011 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 05ACA28C160 for ; Thu, 31 Mar 2011 05:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.55 X-Spam-Level: X-Spam-Status: No, score=-102.55 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 FBYZucVyuhHI for ; Thu, 31 Mar 2011 05:37:10 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id DE69E3A6B13 for ; Thu, 31 Mar 2011 05:37:09 -0700 (PDT) Received: from s60.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 13F9F2B6148 for ; Thu, 31 Mar 2011 14:38:52 +0200 (CEST) Received: (qmail 41328 invoked from network); 31 Mar 2011 12:38:47 -0000 Received: from dhcp-11b7.meeting.ietf.org (HELO [130.129.17.183]) (stefan@fiddler.nu@[130.129.17.183]) (envelope-sender ) by s60.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Mar 2011 12:38:47 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 31 Mar 2011 14:38:43 +0100 From: Stefan Santesson To: "saag@ietf.org" Message-ID: Thread-Topic: Link to the TLS draft including description and code for FNV-1a Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3384427127_65210614" Subject: [saag] Link to the TLS draft including description and code for FNV-1a 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, 31 Mar 2011 12:37:11 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3384427127_65210614 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit As discussed at the Saag meeting http://tools.ietf.org/html/draft-ietf-tls-cached-info-08 /Stefan --B_3384427127_65210614 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
As discussed at the Saag mee= ting


/Stefan
--B_3384427127_65210614-- From stefan@aaa-sec.com Thu Mar 31 05:52:19 2011 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 A0E053A6B3F for ; Thu, 31 Mar 2011 05:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.9 X-Spam-Level: X-Spam-Status: No, score=-102.9 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_LOW=-1, 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 ofwgwhRW75r7 for ; Thu, 31 Mar 2011 05:52:18 -0700 (PDT) Received: from s87.loopia.se (s87.loopia.se [194.9.94.114]) by core3.amsl.com (Postfix) with ESMTP id A3FF23A6914 for ; Thu, 31 Mar 2011 05:52:18 -0700 (PDT) Received: from s24.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id A750F64AA for ; Thu, 31 Mar 2011 14:54:01 +0200 (CEST) Received: (qmail 68366 invoked from network); 31 Mar 2011 12:53:56 -0000 Received: from dhcp-11b7.meeting.ietf.org (HELO [130.129.17.183]) (stefan@fiddler.nu@[130.129.17.183]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 31 Mar 2011 12:53:56 -0000 User-Agent: Microsoft-MacOutlook/14.2.0.101115 Date: Thu, 31 Mar 2011 14:53:53 +0100 From: Stefan Santesson To: Stefan Santesson , "saag@ietf.org" Message-ID: Thread-Topic: [saag] Link to the TLS draft including description and code for FNV-1a In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [saag] Link to the TLS draft including description and code for FNV-1a 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, 31 Mar 2011 12:52:19 -0000 OK, I see now that this draft contains the somewhat flawed java code. The XOR operation is only an 8 bit operation and thus it is not suitable to feed the algorithm with a string of characters potentially holding more than 8 bits. The example in the draft works for a pure ASCII string only. The following code is however correct for the general case /** * Java code sample, implementing 64 bit FNV-1a * By Stefan Santesson */ import java.math.BigInteger; public class FNV { static public BigInteger getFNV1aToByte(byte[] inp) { BigInteger m = new BigInteger("2").pow(64); BigInteger fnvPrime = new BigInteger("1099511628211"); BigInteger fnvOffsetBasis = new BigInteger("14695981039346656037"); BigInteger digest = fnvOffsetBasis; for (byte b : inp) { digest = digest.xor(BigInteger.valueOf((int) b & 255)); digest = digest.multiply(fnvPrime).mod(m); } return digest; } } This is a copy of implemented and tested code which produce the test vector results in the draft. /Stefan From: Stefan Santesson Date: Thu, 31 Mar 2011 14:38:43 +0100 To: "saag@ietf.org" Subject: [saag] Link to the TLS draft including description and code for FNV-1a >As discussed at the Saag meeting > >http://tools.ietf.org/html/draft-ietf-tls-cached-info-08 > >/Stefan > > >_______________________________________________ >saag mailing list >saag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag From d3e3e3@gmail.com Thu Mar 31 05:59:59 2011 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 9EA713A6B4B for ; Thu, 31 Mar 2011 05:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.133 X-Spam-Level: X-Spam-Status: No, score=-104.133 tagged_above=-999 required=5 tests=[AWL=-0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 GExdscpvCC70 for ; Thu, 31 Mar 2011 05:59:58 -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 598843A6B13 for ; Thu, 31 Mar 2011 05:59:58 -0700 (PDT) Received: by wwa36 with SMTP id 36so1943273wwa.13 for ; Thu, 31 Mar 2011 06:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=UltleFI3EZ02sLKGy1tHntzuWy24I8CMEBkRVwiw7DQ=; b=QxMetDUHm3xQ1ocTLNB1e1NuRNc1BGOVnERrFcOcK12LCqwmC6rKyt2k8ZJmn5Y4Ot 0f4wUY+kke/OLoU5YzKaWNQT9o1HLnwsx7c7dWDE3EbOWPyHfPZCZIbP/tOvmm4fNKnI jzwcIAy/7R3eQCCBGFW4cAWKJ+FLGkAssI4LU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jmRzi/JcBi4dCQo5XcIm/K6fX57xzV6bD7cfSVjAdNVbQHG47R9PVLUiKRTSTybGaO OJ+2wdf7lh4JpzO0wW8MNaWP7y5uXJ7njfc5GC5xG0UTg3V/LVPXwNTrbDjr3meBSZjA UazfwgEbQg1/z9nGbWLzfoIvm7oZrk+VZkrMA= Received: by 10.227.61.16 with SMTP id r16mr2659086wbh.24.1301576497441; Thu, 31 Mar 2011 06:01:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.197.19 with HTTP; Thu, 31 Mar 2011 06:01:17 -0700 (PDT) In-Reply-To: References: From: Donald Eastlake Date: Thu, 31 Mar 2011 15:01:17 +0200 Message-ID: To: Stefan Santesson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "saag@ietf.org" Subject: Re: [saag] Link to the TLS draft including description and code for FNV-1a 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, 31 Mar 2011 12:59:59 -0000 Thanks for the pointer. Little of the information in http://tools.ietf.org/html/draft-eastlake-fnv-00 is in the TLS draft and it is planned to have a fairly complete suite of FNV code in the next version of the fnv draft covering all currently specified hash sizes of FNV, etc. I see no reason to remove or change the code in the TLS draft. I plan to add an informational reference to the fnv draft pointing at the tls draft. You may wish to add an informational reference the other way. I am hopeful that the fnv draft will go through fairly quickly. Thanks, Donald =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D =A0Donald E. Eastlake 3rd=A0=A0 +1-508-333-2270 (cell) =A0155 Beaver Street =A0Milford, MA 01757 USA =A0d3e3e3@gmail.com On Thu, Mar 31, 2011 at 3:38 PM, Stefan Santesson wrot= e: > As discussed at the Saag meeting > http://tools.ietf.org/html/draft-ietf-tls-cached-info-08 > /Stefan > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > From ondrej.sury@nic.cz Thu Mar 31 09:28:40 2011 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 EB0E23A684E for ; Thu, 31 Mar 2011 09:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, NO_RELAYS=-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 2DCcpq393GHs for ; Thu, 31 Mar 2011 09:28:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by core3.amsl.com (Postfix) with ESMTP id BE0453A6844 for ; Thu, 31 Mar 2011 09:28:39 -0700 (PDT) Received: from [IPv6:2001:df8:0:96:221:6aff:fe5b:b80] (unknown [IPv6:2001:df8:0:96:221:6aff:fe5b:b80]) by mail.nic.cz (Postfix) with ESMTPSA id BC0232A293A for ; Thu, 31 Mar 2011 18:30:18 +0200 (CEST) Message-ID: <4D94AC1A.9000004@nic.cz> Date: Thu, 31 Mar 2011 18:30:18 +0200 From: =?UTF-8?B?T25kxZllaiBTdXLDvQ==?= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Thunderbird/3.1.9 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Subject: [saag] Short summary of dane wg meeting 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, 31 Mar 2011 16:28:41 -0000 Hi, here's the short summary what happened at dane WG (thanks for Matt Lepinsky for the minutes - full minutes will be submitted to the materials manager). The primary outcomes of the meeting were: -- Concensus was reached on the need for a use-cases and/or requirements document -- The chairs will see that a new Internet Draft is created to capture use-cases and/or requirements. This document may be published as an RFC, or may instead be incorporated into the TLSA protocol document -- EKR and PHB have both agreed to send use-case text to the list to help facilitate the creation of this document Additionally: -- PHB agreed to send text to the list regarding a proposal he had for adding an extra bit to TLSA records that would affect client validation. (This came up in the context of EKR's question on restricting vs supplanting existing validation) O. -- Ondřej Surý vedoucí výzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From nico@cryptonector.com Thu Mar 31 10:14:47 2011 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 06A6A3A6A79 for ; Thu, 31 Mar 2011 10:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 q16el0JnPfBn for ; Thu, 31 Mar 2011 10:14:46 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by core3.amsl.com (Postfix) with ESMTP id E1E1B3A6A63 for ; Thu, 31 Mar 2011 10:14:45 -0700 (PDT) Received: from homiemail-a25.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTP id 6E462678092 for ; Thu, 31 Mar 2011 10:16:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to: content-type; q=dns; s=cryptonector.com; b=SD9HVxWKFnzmDPtwIzvGR kwYa+Kv5Hoc0ZBpG3M/uQSeD9F7WqIwCzI6xFyXj4GKtNHQFgqz5NKp0YOoz8DJR HkOuSin2BMXNRVXXNFI2QJuDRIP4XkO8dZnyl994hXjK3iO/kHWGteBbs2aX2lSH WbwmlMcb0qXYgPvB21x+Mg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type; s=cryptonector.com; bh=2L2G73li3s/a+ZkdcrPy5SF q/6w=; b=dgEayzoZ/NaMIHUOP4WP3ogrIWExjUn7NqDEfAKP17joQIP4yINR1DP pOBYknvsu5TvAnXBMyx1aenHbFYy/5ZcPdDLLJ/fW83M+4bVpXUcadB8Y7XhC1GS F1mQn4Hy/w4KZKhPLTcClDUNy9T7oCrE2bVDd84SXluHJmCyMfN4= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a25.g.dreamhost.com (Postfix) with ESMTPSA id F00EF678075 for ; Thu, 31 Mar 2011 10:15:36 -0700 (PDT) Received: by vxg33 with SMTP id 33so2399871vxg.31 for ; Thu, 31 Mar 2011 10:15:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.68.65 with SMTP id u1mr280812vdt.310.1301591735284; Thu, 31 Mar 2011 10:15:35 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 10:15:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 12:15:35 -0500 Message-ID: From: Nico Williams To: Stefan Santesson , saag@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: Re: [saag] Channel binding - Applet use case 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, 31 Mar 2011 17:14:47 -0000 On Thu, Mar 31, 2011 at 7:37 AM, Stefan Santesson wrote: > Had an interesting discussion about this at lunch and it basically drills > down to the applet's ability to retrieve the browsers end-point channel > bindings (The server certificate used by the browser to connect with the > SP). It seems that this is not possible for some browsers, including IE. > > A major objective for this discussed solution is to make sure that the > browser and the applet talk to the same SP entity on a MitM free channel. > So this is a serious issue. > > Any thoughts on ways around this problem or are we essentially screwed? We talked today for a bit. There's two issues: a) is the applet authenticated with the same PKI (trust anchors) as the server? b) how to extract the server's certificate from the browser so as to use it as the channel binding. (b) is possible for some browsers. For example, Firefox: https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL You'd have to do an XMLHttpRequest for a dummy resource just so you could learn the server's certificate, but that's fine, I'm sure. (a) may be trickier -- I don't know if there's a way to configure different TAs for applet signature validation than for TLS, though I sure hope there is! As a last resort you can self-sign the applet signing certificate and tell the user how to manually validate the certificate (ha! right, that'll work, not). Anyways, there's enough here to do a demo. I've wanted to build a similar thing, but I hadn't thought of signed applets -- I always figured I'd need a plugin/add-on for the browser, with all attendant difficulties. But a plugin/add-on has its advantages, such as that authentication of it only needs to be done once, so in the worst case you have an SSH-style leap-of-faith mitigated by the fact that the leap is one-time, which limits the opportunities for MITM attacks. Another advantage of going with a plugin/add-on approach is that you could use native SSPI/GSS-API facilities not normally available in the browser. Quite aside from how you should move forward (solve (a) and (b)), I think there's an issue of what advice we might be able to give to browser implementors, likely via the W3C. Here's my advice to them: 1) Add FF-like XmlHttpRequest interfaces for discovering the server's cert. 2) Add XmlHttpRequest interfaces for setting up an HTTPS channel and learning its tls-unique channel bindings (to be used in the HTTP request about to be sent by the script over that channel). 3) And this is the piece de resistance: add JavaScript objects by which to access GSS-API mechanisms and credentials (through GSS-API or SSPI interfaces). (2) is optional, but nice to have. (1) is absolutely required. (2) is necessary to avoid the signed applet thing, and would add much, much user convenience. (It will also create demand for GSS-API mechanisms that work outside the enterprise and on an Internet scale.) Nico -- From nico@cryptonector.com Thu Mar 31 10:16:02 2011 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 D12493A6B8D for ; Thu, 31 Mar 2011 10:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.884 X-Spam-Level: X-Spam-Status: No, score=-1.884 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 GdNH5i+DObSf for ; Thu, 31 Mar 2011 10:16:02 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by core3.amsl.com (Postfix) with ESMTP id 771473A6B87 for ; Thu, 31 Mar 2011 10:16:01 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 5FA9059405E for ; Thu, 31 Mar 2011 10:17:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=kZ35Mt1x9IGBa+xmUo38/HTcg89yO+kj6kx6yI5pjGdn zMP0rWkyYrfryniNFDgO4JZ0QLZxacmDHAYmVyhVkwH8cetR6pEwBPSmB7mBEh2J WBNvB8E9v3cpxv+uwjGQ4GFxJjlIijbGb68aHWLCxIV6dSUy29GMACmim8kgeaI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:content-type:content-transfer-encoding; s=cryptonector.com; bh=ksF5VAE7UySgdl+HH3AfqweE+FM=; b=Lq/er75mAk3a9A+R7KOc9Mxh68oV OH0rkSOzaispNN+wy1OW2zNHSYJiMsNwUD793WhQ1WkItyPl+pmZocAX32bzliVC pQn3TeA5IicRyUdLMwwaO7WK5nOs/9Hui5+mjpvGfjcQb8BNsoO46DApOsvGBWxb Vk10Vv5Kf6n0jwQ= Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 2B00B594056 for ; Thu, 31 Mar 2011 10:17:41 -0700 (PDT) Received: by vxg33 with SMTP id 33so2401965vxg.31 for ; Thu, 31 Mar 2011 10:17:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.18 with SMTP id bk18mr3878151vdb.270.1301591860564; Thu, 31 Mar 2011 10:17:40 -0700 (PDT) Received: by 10.52.157.100 with HTTP; Thu, 31 Mar 2011 10:17:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Mar 2011 12:17:40 -0500 Message-ID: From: Nico Williams To: Stefan Santesson , saag@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [saag] Channel binding - Applet use case 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, 31 Mar 2011 17:16:03 -0000 On Thu, Mar 31, 2011 at 12:15 PM, Nico Williams wro= te: > Quite aside from how you should move forward (solve (a) and (b)), I > think there's an issue of what advice we might be able to give to > browser implementors, likely via the W3C. =C2=A0Here's my advice to them: Also, I could really use some advice/help with the conveying of the above to the W3C and browser implementors. It might be useful to produce a document with IETF consensus that we could flog at them. Thoughts? Help! Nico --