From jiangsheng@huawei.com Wed Dec 28 01:48:12 2011 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0EF721F84A2 for ; Wed, 28 Dec 2011 01:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.439 X-Spam-Level: X-Spam-Status: No, score=-6.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxjzNYbtOfe3 for ; Wed, 28 Dec 2011 01:48:12 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6865F21F849E for ; Wed, 28 Dec 2011 01:48:11 -0800 (PST) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWW006TAR8APL@szxga04-in.huawei.com> for saag@ietf.org; Wed, 28 Dec 2011 17:48:10 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LWW00GMLR8297@szxga04-in.huawei.com> for saag@ietf.org; Wed, 28 Dec 2011 17:48:10 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AGB62561; Wed, 28 Dec 2011 17:48:09 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 28 Dec 2011 17:48:06 +0800 Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.239]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0323.003; Wed, 28 Dec 2011 17:48:05 +0800 Date: Wed, 28 Dec 2011 09:48:04 +0000 From: Sheng Jiang In-reply-to: <999913AB42CC9341B05A99BBF358718DECDD1E@FIESEXC035.nsn-intra.net> X-Originating-IP: [10.108.4.58] To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "saag@ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B92185890C6@SZXEML506-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: en-GB, zh-CN, en-US Thread-topic: [saag] Review Request for Secure DHCPv6 draft Thread-index: Acy+x2gGN3HO4h0SQnaoLYayaAyNrwGcz/IAAAKz4fA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <5D36713D8A4E7348A7E10DF7437A4B9218583D0F@SZXEML506-MBX.china.huawei.com> <999913AB42CC9341B05A99BBF358718DECDD1E@FIESEXC035.nsn-intra.net> X-Mailman-Approved-At: Sun, 01 Jan 2012 11:48:22 -0800 Cc: dhc Chairs Subject: Re: [saag] Review Request for Secure DHCPv6 draft X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 09:48:13 -0000 Hi, Hannes, The draft was only expired last week. I will keep it active for sure. But if you can give some comments now, I can integrate them into 04 version immediately. http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-03 I will go through the reference last again. Sheng > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Wednesday, December 28, 2011 4:31 PM > To: Sheng Jiang; saag@ietf.org > Cc: dhc Chairs > Subject: RE: [saag] Review Request for Secure DHCPv6 draft > > Hi Sheng, > > I am not sure which document you are talking about. > http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-03 is expired > and http://datatracker.ietf.org/doc/draft-ietf-dhc-cga-config-dhcpv6 > itself seems to depend on other specifications but the references don't > make sense - many of the references that are listed under the normative > section should rather be informative and vice versa. > > ciao > Hannes > > > -----Original Message----- > > From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf > Of > > ext Sheng Jiang > > Sent: Tuesday, December 20, 2011 5:28 AM > > To: saag@ietf.org > > Cc: dhc Chairs > > Subject: [saag] Review Request for Secure DHCPv6 draft > > > > Hi, security experts, > > > > The Secure DHCPv6 draft is nearly reaching DHC WGLC stage. Since it > is > > heavily secure relevant, we would like to get your review comments > > before WGLC. Could you please spare some time to read and comment? > > > > Many thanks and best regards, > > > > Sheng > > _______________________________________________ > > saag mailing list > > saag@ietf.org > > https://www.ietf.org/mailman/listinfo/saag From smb@cs.columbia.edu Wed Jan 4 13:41:59 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE8F1F0C3C; Wed, 4 Jan 2012 13:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFAmWLdU3icB; Wed, 4 Jan 2012 13:41:59 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 17D261F0C3B; Wed, 4 Jan 2012 13:41:59 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04Lfuvi028926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 16:41:56 -0500 (EST) From: Steven Bellovin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 4 Jan 2012 16:41:55 -0500 Message-Id: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> To: cfrg@irtf.org, saag@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Subject: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 21:41:59 -0000 I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: Abstract Many systems (e.g., cryptographic protocols relying on symmetric cryptography) require that plaintext passwords be stored. Given how often people reuse passwords on different systems, this poses a very serious risk if a single machine is compromised. We propose a scheme to derive passwords limited to a single machine from a typed password, and explain how a protocol definition can specify this scheme. --Steve Bellovin, https://www.cs.columbia.edu/~smb From touch@isi.edu Wed Jan 4 14:21:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BCD811E80EE; Wed, 4 Jan 2012 14:21:40 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72MVXJM3to8w; Wed, 4 Jan 2012 14:21:39 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 40DFF11E80ED; Wed, 4 Jan 2012 14:21:39 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q04ML1Uo029814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jan 2012 14:21:01 -0800 (PST) Message-ID: <4F04D0CD.9010807@isi.edu> Date: Wed, 04 Jan 2012 14:21:01 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Bellovin References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> In-Reply-To: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:21:40 -0000 Hi, Steve, This doc doesn't appear to address the case where a host has multiple DNS names, which could make it difficult to incorporate the hostname into the transform. I.e., I could contact a mail server at an IP address that represents any of dozens of DNS names - how does the server know which one I used so it can match without exhaustively trying all its equivalent names? Joe On 1/4/2012 1:41 PM, Steven Bellovin wrote: > I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: > > Abstract > > Many systems (e.g., cryptographic protocols relying on symmetric > cryptography) require that plaintext passwords be stored. Given how > often people reuse passwords on different systems, this poses a very > serious risk if a single machine is compromised. We propose a scheme > to derive passwords limited to a single machine from a typed > password, and explain how a protocol definition can specify this > scheme. > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From smb@cs.columbia.edu Wed Jan 4 14:56:12 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E163E11E80B6; Wed, 4 Jan 2012 14:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woq8L7Cyj8ss; Wed, 4 Jan 2012 14:56:12 -0800 (PST) Received: from tarap.cc.columbia.edu (tarap.cc.columbia.edu [128.59.29.7]) by ietfa.amsl.com (Postfix) with ESMTP id 962CF11E80C5; Wed, 4 Jan 2012 14:56:11 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by tarap.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04Mu9sE012435 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 17:56:10 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4F04D0CD.9010807@isi.edu> Date: Wed, 4 Jan 2012 17:56:08 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.7 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 22:56:13 -0000 Good point; let me think about it for -01. An obvious solution is to = send the hostname with the effective password. On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: > Hi, Steve, >=20 > This doc doesn't appear to address the case where a host has multiple = DNS names, which could make it difficult to incorporate the hostname = into the transform. I.e., I could contact a mail server at an IP address = that represents any of dozens of DNS names - how does the server know = which one I used so it can match without exhaustively trying all its = equivalent names? >=20 > Joe >=20 > On 1/4/2012 1:41 PM, Steven Bellovin wrote: >> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>=20 >> Abstract >>=20 >> Many systems (e.g., cryptographic protocols relying on symmetric >> cryptography) require that plaintext passwords be stored. Given = how >> often people reuse passwords on different systems, this poses a = very >> serious risk if a single machine is compromised. We propose a = scheme >> to derive passwords limited to a single machine from a typed >> password, and explain how a protocol definition can specify this >> scheme. >>=20 >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From touch@isi.edu Wed Jan 4 15:03:41 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A5721F8751; Wed, 4 Jan 2012 15:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.599 X-Spam-Level: X-Spam-Status: No, score=-104.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6kF529bHRVL; Wed, 4 Jan 2012 15:03:40 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id A65F221F8732; Wed, 4 Jan 2012 15:03:40 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q04N2vnZ013964 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jan 2012 15:02:57 -0800 (PST) Message-ID: <4F04DAA1.5050604@isi.edu> Date: Wed, 04 Jan 2012 15:02:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Bellovin References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> In-Reply-To: <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:03:41 -0000 On 1/4/2012 2:56 PM, Steven Bellovin wrote: > Good point; let me think about it for -01. An obvious solution is to send > the hostname with the effective password. Yes, I considered that, but then you're sending cleartext that was part of the hash; I thought that was frowned upon... Joe > > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: > >> Hi, Steve, >> >> This doc doesn't appear to address the case where a host has multiple DNS names, which could make it difficult to incorporate the hostname into the transform. I.e., I could contact a mail server at an IP address that represents any of dozens of DNS names - how does the server know which one I used so it can match without exhaustively trying all its equivalent names? >> >> Joe >> >> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>> >>> Abstract >>> >>> Many systems (e.g., cryptographic protocols relying on symmetric >>> cryptography) require that plaintext passwords be stored. Given how >>> often people reuse passwords on different systems, this poses a very >>> serious risk if a single machine is compromised. We propose a scheme >>> to derive passwords limited to a single machine from a typed >>> password, and explain how a protocol definition can specify this >>> scheme. >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > From smb@cs.columbia.edu Wed Jan 4 15:36:38 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A764211E8135; Wed, 4 Jan 2012 15:36:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CWQwAD6rYXz; Wed, 4 Jan 2012 15:36:38 -0800 (PST) Received: from rambutan.cc.columbia.edu (rambutan.cc.columbia.edu [128.59.29.5]) by ietfa.amsl.com (Postfix) with ESMTP id B322611E8134; Wed, 4 Jan 2012 15:36:37 -0800 (PST) Received: from [192.168.2.166] (74-92-112-54-Philadelphia.hfc.comcastbusiness.net [74.92.112.54]) (user=smb2132 mech=PLAIN bits=0) by rambutan.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id q04NaY1C018521 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 4 Jan 2012 18:36:35 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Steven Bellovin In-Reply-To: <4F04DAA1.5050604@isi.edu> Date: Wed, 4 Jan 2012 18:36:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> <4F04DAA1.5050604@isi.edu> To: Joe Touch X-Mailer: Apple Mail (2.1251.1) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.5 Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 23:36:38 -0000 Not with HMAC -- we do it all the time with, say, ESP-NULL. On Jan 4, 2012, at 6:02 57PM, Joe Touch wrote: >=20 >=20 > On 1/4/2012 2:56 PM, Steven Bellovin wrote: >> Good point; let me think about it for -01. An obvious solution is to = send >> the hostname with the effective password. >=20 > Yes, I considered that, but then you're sending cleartext that was = part of the hash; I thought that was frowned upon... >=20 > Joe >=20 >>=20 >> On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: >>=20 >>> Hi, Steve, >>>=20 >>> This doc doesn't appear to address the case where a host has = multiple DNS names, which could make it difficult to incorporate the = hostname into the transform. I.e., I could contact a mail server at an = IP address that represents any of dozens of DNS names - how does the = server know which one I used so it can match without exhaustively trying = all its equivalent names? >>>=20 >>> Joe >>>=20 >>> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>>>=20 >>>> Abstract >>>>=20 >>>> Many systems (e.g., cryptographic protocols relying on symmetric >>>> cryptography) require that plaintext passwords be stored. Given = how >>>> often people reuse passwords on different systems, this poses a = very >>>> serious risk if a single machine is compromised. We propose a = scheme >>>> to derive passwords limited to a single machine from a typed >>>> password, and explain how a protocol definition can specify this >>>> scheme. >>>>=20 >>>>=20 >>>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> saag mailing list >>>> saag@ietf.org >>>> https://www.ietf.org/mailman/listinfo/saag >>>=20 >>=20 >>=20 >> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>=20 >>=20 >>=20 >>=20 >>=20 >=20 --Steve Bellovin, https://www.cs.columbia.edu/~smb From yaronf.ietf@gmail.com Wed Jan 4 23:13:01 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09401F0C38 for ; Wed, 4 Jan 2012 23:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMq6Ra0jf6o4 for ; Wed, 4 Jan 2012 23:13:01 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id D24C521F85C6 for ; Wed, 4 Jan 2012 23:13:00 -0800 (PST) Received: by eekc14 with SMTP id c14so143167eek.31 for ; Wed, 04 Jan 2012 23:13:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=UeGoE+W6fBSmDbX/8Fi0B14nahJhTXFb4sg1a/xFG6I=; b=QUA3DeYcrXggw7Riaku3H781aRrsgm1Fsb+dvQ+ybt5X7ZrXdqt3FtamVZxHH/fOoT aVfjrcT+vNeK1//bnzUPhyUDMgv41hlBqmYspkZZcmrlCYgcA4KhbReAnOcnioGt3H2X WC644fYNME6FUULSTfgnCSifGaX5TGojN3W1k= Received: by 10.213.8.145 with SMTP id h17mr279192ebh.62.1325747579975; Wed, 04 Jan 2012 23:12:59 -0800 (PST) Received: from [10.0.0.6] ([109.67.155.85]) by mx.google.com with ESMTPS id a60sm230100356eeb.4.2012.01.04.23.12.58 (version=SSLv3 cipher=OTHER); Wed, 04 Jan 2012 23:12:59 -0800 (PST) Message-ID: <4F054D78.1080008@gmail.com> Date: Thu, 05 Jan 2012 09:12:56 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Steven Bellovin References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> <4F04DAA1.5050604@isi.edu> <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> In-Reply-To: <33E0B548-D141-48CA-86DC-F7E4EB1DEDD2@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 07:13:02 -0000 Hi Steve, thanks for the new draft. A few comments: * The argument against using a random salt is somewhat unconvincing: "it would have to be known to the user as well as the server, and users typically have multiple devices on which they enter passwords." Since we assume computing power on the client side, there's no reason why we cannot have the server send the salt to the user instead of having it stored client-side. I do agree though that the benefits of a random salt added to this scheme are minimal. * Arbitrary non-ASCII passwords must be supported. I suggest to remove the under-specified bullet about "canonicalizing the entered password" and adopt text similar to (from RFC 6124): This protocol supports internationalized, non-ASCII passwords. The input password string SHOULD be processed according to the rules of the [RFC4013] profile of [RFC3454]. A password SHOULD be considered a "stored string" per [RFC3454], and unassigned code points are therefore prohibited. The output is the binary representation of the processed UTF-8 [RFC3629] character string. Prohibited output and unassigned code points encountered in SASLprep preprocessing SHOULD cause a preprocessing failure and the output SHOULD NOT be used. * The text implicitly assumes that we are "sending the effective password over the wire." This is obviously not the case if strong password-based methods of the EKE family are used. * "If effective passwords are used only for the usual password verification and not for cryptographic purposes, they should be treated with the care used for ordinary password, i.e., salted, hashed, etc. " I can see the value of hashing here, but not of salting. Thanks, Yaron > >> >>> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>>>> >>>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>>>> >>>> >>>>> >>>> Abstract >>>>> >>>> >>>>> >>>> Many systems (e.g., cryptographic protocols relying on symmetric >>>>> >>>> cryptography) require that plaintext passwords be stored. Given how >>>>> >>>> often people reuse passwords on different systems, this poses a very >>>>> >>>> serious risk if a single machine is compromised. We propose a scheme >>>>> >>>> to derive passwords limited to a single machine from a typed >>>>> >>>> password, and explain how a protocol definition can specify this >>>>> >>>> scheme. >>>>> >>>> >>>>> >>>> >>>>> >>>> --Steve Bellovin,https://www.cs.columbia.edu/~smb >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> _______________________________________________ >>>>> >>>> saag mailing list >>>>> >>>> saag@ietf.org >>>>> >>>> https://www.ietf.org/mailman/listinfo/saag >>>> >>> >>> >> >>> >> >>> >> --Steve Bellovin,https://www.cs.columbia.edu/~smb >>> >> >>> >> >>> >> >>> >> >>> >> >> > > --Steve Bellovin,https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From prvs=2351dd59fc=uri@ll.mit.edu Thu Jan 5 08:28:40 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD6E21F8767; Thu, 5 Jan 2012 08:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.45 X-Spam-Level: X-Spam-Status: No, score=-4.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2cdrCpCCoDt; Thu, 5 Jan 2012 08:28:39 -0800 (PST) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id C306421F86D1; Thu, 5 Jan 2012 08:28:38 -0800 (PST) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id q05GSKc2015009; Thu, 5 Jan 2012 11:28:20 -0500 From: "Blumenthal, Uri - 0668 - MITLL" To: Steven Bellovin Date: Thu, 5 Jan 2012 11:28:12 -0500 Thread-Topic: [Cfrg] [saag] New draft: Hashed Password Exchange Thread-Index: AczLxwjthKWn6Sa0TTSjnfq/FJnchw== Message-ID: In-Reply-To: <4F054D78.1080008@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.12.0.110505 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3408607697_86656470" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.5.7110, 1.0.211, 0.0.0000 definitions=2012-01-05_05:2012-01-05, 2012-01-05, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1201050160 Cc: "cfrg@irtf.org" , "saag@ietf.org" Subject: Re: [saag] [Cfrg] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:28:40 -0000 --B_3408607697_86656470 Content-type: multipart/alternative; boundary="B_3408607692_86683219" --B_3408607692_86683219 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Steve, How would you compare your proposed localizing-by-URI approach with localizing-by-host (or by "SNMP engine") approach proposed in RFC 3414 http://datatracker.ietf.org/doc/rfc3414/ ? Some questions to consider. You propose "localization" by service - i.e., by hostname + port. How many passwords per user would a server store? How critical is your requirement that "no two [effective] `passwords for different services [on the same host] should be the same for the same user"? A benefit of not localizing based on the whole service would be the ability for a multi-named server =AD based on some rules that are out of scope for this email =AD choose the "dominant" name and localize users' passwords to it, thus storing one password per user on this server; avoiding the potential ambiguity that Joe Touch pointed out. Is HMAC an overkill in this case, considering that inverting a decent hash didn't work even for the long-deprecated MD4 (we seem to worry here about non-invertibility/one-way-ness, not collision resistance)? Or did you choos= e it because it's the best keyed hash construct we have? Note that the brute-force attacks would be the same for both plain hash and HMAC (with HMAC offering one more hash run per iteration). Regarding salt =AD couldn't it be used on the server only? Treating the "localized password" as the pre-salted password in the original Unix scheme= , then salting it before comparison? Obviously this is not the method to use in protocols that employ the password derivative as a cryptographic key=8A Oh, and since this proposal seems to be addressing the same problem in a somewhat similar way =AD perhaps it would make sense to include a reference t= o RFC 3414 (section 2.6 Key Localization Algorithm)? :) Tnx! --=20 Regards, Uri uri@ll.mit.edu --B_3408607692_86683219 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
Steve,

How would you compare you= r proposed localizing-by-URI approach with localizing-by-host (or by "SNMP e= ngine") approach proposed in RFC 3414 http://datatracker.ietf.org/doc/rfc3414/ ?=  

Some questions to consider. 

You propose "localization" by service - i.e., by hos= tname + port. How many passwords per user would a server store? How critical= is your requirement that "no two [effective] `passwords for different servi= ces [on the same host] should be the same for the same user"?  A benefi= t of not localizing based on th= e whole service would be the ability for a multi-named server – based = on some rules that are out of scope for this email – choose the "domin= ant" name and localize users' passwords to it, thus storing one password per= user on this server; avoiding the potential ambiguity that Joe Touch pointe= d out.

Is HMAC an overkill in this case, = considering that inverting a decent = hash didn't work even for the long-deprecated MD4 (we seem to worry here abo= ut non-invertibility/one-way-ness, not collision resistance)? Or did you cho= ose it because it's the best keyed hash construct we have?  Note that the brute-force attacks would be= the same for both plain hash and HMAC (with HMAC offering one more hash run= per iteration).

Regarding salt – c= ouldn't it be used on the server only? Treating the "localized password" as = the pre-salted password in the original Unix scheme, then salting it before = comparison? Obviously this is not the method to use in protocols that employ= the password derivative as a cryptographic key…

Oh, and since this proposal seems to be addressing the same pr= oblem in a somewhat similar way – perhaps it would make sense to inclu= de a reference to RFC 3414 (section 2.6 Key Localization Algorithm)? :)

Tnx!
-- 
Regards,
Uri      uri@= ll.mit.edu
--B_3408607692_86683219-- --B_3408607697_86656470 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUAAYJKoZIhvcNAQcCoIIT8TCCE+0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggTLMIIDs6ADAgECAgocykucAAAAABz0MA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTEwNzE0MTYzMTE0WhcNMTIwNzEzMTYzMTE0WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBANv2QbmKZtfoxOVYMXLUdwjqMm8jsN4GK0n18a6R9uyRcEp4 NLdVAFZ6JeImmxZWNEWXmDyCC+ykliyIJwIUER3zT2LJyIbpELsIv1tkIhWcuLfAYZMsH+kT cKk1LpDm0tE4Z5cCrqTJvS8lUSrglJKOyy9mSG4lySkqqIMg5eRw/oZ/RstqIHy+EJgHgJDY pxleRZbl7s9w1VYKbp8kbHarX9zCzOfp6HW/xtovwP07Z7lUBOWlw7AXXehwC1flwWbG9Eq8 5fDeIKIPj+xS9TmUYguPfJBdDOZYOlUfoRspJ0nwujjeoP9rX3NKyq6cmbOEuP/yTEkDwBrS lEUpNCkCAwEAAaOCAZMwggGPMB0GA1UdDgQWBBREe8exSTToHSIt2geg++QNUdKYHDAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQB17CA8es2u0zGsL5JSMclcdzRDtQHW7cH4HgCJ8neeWltNXQ6x/OhYPFCWAz8x84mQ AnbIycHLKDuuBn17b35Ct3zTs6jbJj0T0m8Elnj6ONk9z/uwmB+fWh43rMjlUyWNVmNOm7sG X2EmZHm7EqHyMzNW3f8bqw+pw9sC5BHQvkPgmBNFxI18YNmpeQYg48ZRP0cRHKaNPTm7AECj up9wxnuW8CnDKW6bzaNErKEQt4HOGvcbHqlLkRwZK1CXEXesI9vCB2Nrytdkbovr2BkvzmUr 5QpGJ+YsLHl2WrM0+yHHW3SKRPJyo3cJylni86AbehQ6k0dZha6exy/UBwmLMIIEtzCCA5+g AwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp bmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENB MB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6AzBwVh Zkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2 aTg42kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQ tjA5ZcuWnECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKm gOs7Vy+6e0Dk+cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0 Cqa5crWKoNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYB BQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AubGwubWl0LmVkdTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYL KoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgED AQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZI hvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ/XH8C6DCL+eEGroOzxBcCqTNItms v4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACcoK2TzVtDRZXYxov/SqZRjI3d ufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+XlqtgBiFTVIMIfBJwPajrsi z+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfphWHHtoiTDkBSZ4Ufv GXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJCmagRYGyexfe dVNF0cJWL4J/cLHhgNYwggODMIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kx FjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5 WjBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxU4pF1iyJrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJB OgCwDqrVsAK1lRwy/lkrHzPkobiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2 nUOCO10AMpUsCNdpikPY9ukT8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr 6wj9m2sVGawoaG7AAqhsWvQUM/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz 1I5fR/vCaxiLXIW4oUydBuRKTG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwID AQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0Pt KTAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZI hvcNAQEFBQADggEBAD4bbQVg0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/Ta oNT8Y7Yf0RO+e9NiG9+BDhQH/kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2 eBvoOB4RS/5LAWfNws7W+DWt2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2 492Al87d3VasevUS1pprRBEupChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYW cfYqQ3FGf37YCvuDeues4xm+nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAw ggTOMIIDtqADAgECAgpbJUqmAAAAAA8TMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwHhcNMTEwMzI0MTIyNjExWhcNMTIwMzIzMTIyNjExWjBhMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVv cGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJgc1a1sochMa7t5yY+uE41Zbsv3nHOSCIrCSh4rMUGd7uQLJev7 yg12DVeG5aD0Mh4CfvWY4aPqpLbKmgvtQwRGK7Q4AI8LkmXsrHTPePj8q1xl9D9iLOLJB7NI 6tIWBLoRUpdnpTXpVY48vYh3EawGOoyATcjGIgFDxdQRduCdOfgnhwV5VKLidwTa2u3c1jYr FiCnGwiWRzKFSoNORzEp+Ya9+3IxAoXv1njOCRSsjs0NW1Dk0NRbcQ8GvomFNv0l9wVbKZFP SOxfIdaImNOR6plD0hZXyS1R3AM2rmC+8sHhTe8SjTCH4wTU5GDl3ggMma9Hs9TaH5tQt8AT nj0CAwEAAaOCAZYwggGSMB0GA1UdDgQWBBQQR4g7yYztZ0FyMkiRO+qlMFa91jAOBgNVHQ8B Af8EBAMCBSAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRW MFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIB BDAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBTX15euArO0iAXeKleS4RByMTW91D/0ihJOIbxiqNkYtyBau2nj11c4njjB58a0pGk YEfxa+LK/bWrOIw1NuZ1f00GcorNcfxixxH4JpiMdC55PYH5aN0r3s3HFTd/Irbdr0J4XA2s K7MyhyiOaOY1rTV7idWdyL8KJW+Y38sOVHLwe0JHpF/TUbF1wmtyam1kj5VJvrBEIjbuEKjl +bPzgCx6ZaTajuo16Op5xFK3ABdq+zKXgXmFGR2NT0nNQ7OnqCpGnVyoOvahFZk1Chr/zUvb V6rINQxtvgnCUGLbaKROfVlmes/vtbLALimVsPRVseBE4I/bpyzfI9F8NwRXMYIB5TCCAeEC AQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgocykucAAAAABz0MAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQUHONf+kuCj+TP05cKSB2t5ak0DVgwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwMTA1MTYyODEyWjANBgkqhkiG9w0B AQEFAASCAQCSbUAvTBgUhQGoUNxa02JZ+mQdNxw1yooAbDjB3dZwKBYrGu5sPti4YBZZq9fY mYgFX/UE8mD6PG86kBJZSIyG0s0v+f4q9wCJXr5W0yLgcmkeHEnYJ644knqKW1qlFJfui4j5 RLYDNl4YwYtAgtFdkAvlZeFutL5ihCRIBxWlpM6e6uPRIjkItwxRl1VckE1rcm0NL/8Eaneb r/bq0X4viSGN7xUayU/iNLyO//unITBN/SXLphvx4s1Jiglj9mORl8SSKljfA+Rva2kZAO94 lLsu5Cv02W3aESqpCXf/yEpae/jpxHZy5kbiL2QBwGGfwmZDW5RJ4e+bOUAQiQPv --B_3408607697_86656470-- From dharkins@lounge.org Sat Jan 7 01:03:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7721F856D for ; Sat, 7 Jan 2012 01:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.147 X-Spam-Level: X-Spam-Status: No, score=-5.147 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8S7H98qyj-4o for ; Sat, 7 Jan 2012 01:03:26 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 120D221F856C for ; Sat, 7 Jan 2012 01:03:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 671131022404A; Sat, 7 Jan 2012 01:03:25 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 7 Jan 2012 01:03:25 -0800 (PST) Message-ID: <1c680c52d4a354cdeda0a39e9cc47d32.squirrel@www.trepanning.net> In-Reply-To: <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> Date: Sat, 7 Jan 2012 01:03:25 -0800 (PST) From: "Dan Harkins" To: "Steven Bellovin" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2012 09:03:27 -0000 On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote: > Good point; let me think about it for -01. An obvious solution is to send > the hostname with the effective password. How is that different than using random salt then? If _something_ is going to be sent shouldn't it be a uniformly random bitstring instead of a hostname? A uniformly random bitstring would be more appropriate as a key to HMAC than a highly structured string like a password too. Iterate HMAC(salt, password | service-URI) instead of HMAC(password, service-URI). That said, goal 4 in the draft-- "By iterating a sufficient number of times, dictionary attacks can be made arbitrarily expensive"-- seems a bit misguided. The Amazon cloud service has been used to launch an off-line dictionary attack against the WPA-PSK protocol which uses PBKDF2 (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack checks 24,000,000 candidate passwords per minute at a cost of $0.28. That's more than 1,600,000,000 iterations per second for about 1/2 a cent. So I don't think increased iteration makes dictionary attacks much more expensive. Which begs the question, how is this proposal different than PBKDF2? That the "salt" is a service URI? regards, Dan. > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: > >> Hi, Steve, >> >> This doc doesn't appear to address the case where a host has multiple >> DNS names, which could make it difficult to incorporate the hostname >> into the transform. I.e., I could contact a mail server at an IP address >> that represents any of dozens of DNS names - how does the server know >> which one I used so it can match without exhaustively trying all its >> equivalent names? >> >> Joe >> >> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>> >>> Abstract >>> >>> Many systems (e.g., cryptographic protocols relying on symmetric >>> cryptography) require that plaintext passwords be stored. Given how >>> often people reuse passwords on different systems, this poses a very >>> serious risk if a single machine is compromised. We propose a >>> scheme >>> to derive passwords limited to a single machine from a typed >>> password, and explain how a protocol definition can specify this >>> scheme. >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From fenton@bluepopcorn.net Tue Jan 10 11:16:03 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B757921F8777 for ; Tue, 10 Jan 2012 11:16:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPAFtAknTVfF for ; Tue, 10 Jan 2012 11:16:02 -0800 (PST) Received: from kernel.bluepopcorn.net (ipv6.bluepopcorn.net [IPv6:2001:470:1f05:bfe:21a:70ff:fe11:c889]) by ietfa.amsl.com (Postfix) with ESMTP id F3BF921F876E for ; Tue, 10 Jan 2012 11:16:01 -0800 (PST) Received: from splunge.local (63-201-144-200.propel.com [63.201.144.200]) (authenticated bits=0) by kernel.bluepopcorn.net (8.14.5/8.14.4) with ESMTP id q0AJGMM3016896 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 10 Jan 2012 11:16:24 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bluepopcorn.net; s=buttered; t=1326222984; bh=I4+ax5rGFOI4DrusutY/4L/YycAGYmM3VPWtn2mBcv4=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=mHbnfsviDckedB2dYS+9slkpYDqCrepdfev2VRTCPS7h+li2iq+U9MvzbL9llz0NQ n3jBbdAgAqRSfIDAmtiV7FZ1ainTvqOt+ADfk6xwhHdH7I+Hs+9IEK/8IpUbbt3 Message-ID: <4F0C8E6C.4030507@bluepopcorn.net> Date: Tue, 10 Jan 2012 11:15:56 -0800 From: Jim Fenton User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: saag@ietf.org Content-Type: multipart/alternative; boundary="------------050404090704040302070103" Subject: [saag] 2012 NIST/NSTIC IDtrust Workshop-Mark Your Calendars- March 13-14 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2012 19:16:03 -0000 This is a multi-part message in MIME format. --------------050404090704040302070103 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Quite a few IETF participants have participated in this workshop (formerly the PKI R&D Workshop) over the years, so I thought this might be of interest. Being sensitive to spamming the saag list with conference announcements, I checked with the ADs first, who agreed this is appropriate. ===== 2012 NIST/NSTIC IDtrust Workshop: "Technologies and Standards Enabling the Identity Ecosystem" The 2012 NIST/NSTIC IDtrust Workshop will be held March 13-14, 2012 at NIST in Gaithersburg, Maryland. The workshop will focus on how technologies and standards can help the framework of the identity ecosystem coalesce. The two day workshop will feature plenary presentations and panel discussions by leading identity management and standards experts addressing a broad swath of technology and standards issues that surround identifying and implementing the four NSTIC Guiding Principles in the Identity Ecosystem: * Identity Solutions will be Privacy-Enhancing and Voluntary * Identity Solutions will be Secure and Resilient * Identity Solutions will be Interoperable * Identity Solutions will be Cost-Effective and Easy To Use Additional details will be available at: http://www.nist.gov/itl/csd/ct/nstic_idtrust-2012.cfm --------------050404090704040302070103 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Quite a few IETF participants have participated in this workshop (formerly the PKI R&D Workshop) over the years, so I thought this might be of interest. Being sensitive to spamming the saag list with conference announcements, I checked with the ADs first, who agreed this is appropriate.

=====

2012 NIST/NSTIC IDtrust Workshop:

“Technologies and Standards Enabling the Identity Ecosystem”

The 2012 NIST/NSTIC IDtrust Workshop will be held March 13-14, 2012 at NIST in Gaithersburg, Maryland.  The workshop will focus on how technologies and standards can help the framework of the identity ecosystem coalesce. 

The two day workshop will feature plenary presentations and panel discussions by leading identity management and standards experts addressing a broad swath of technology and standards issues that surround identifying and implementing the four NSTIC Guiding Principles in the Identity Ecosystem:

  • Identity Solutions will be Privacy-Enhancing and Voluntary
  • Identity Solutions will be Secure and Resilient
  • Identity Solutions will be Interoperable
  • Identity Solutions will be Cost-Effective and Easy To Use

Additional details will be available at: 

http://www.nist.gov/itl/csd/ct/nstic_idtrust-2012.cfm

 

 

--------------050404090704040302070103-- From stephen.farrell@cs.tcd.ie Fri Jan 13 10:26:34 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF87121F84E1; Fri, 13 Jan 2012 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hw88tmRiJ4y; Fri, 13 Jan 2012 10:26:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5821F849D; Fri, 13 Jan 2012 10:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 66CB1171CC3; Fri, 13 Jan 2012 18:26:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326479178; bh=3R2RTxtYEZE96C 1vaPyq8mMqTa5543cjo2S9hxXqPb8=; b=2iWKMAG/oVVEKOMcLDwf0qsQ59fyCo UnnPfLOn3Vc2D9jN0f8R60XiRTS0VgYS4fSp/mAoTW3pqiQhZP3f6qiB3vtJLlDO efY5gyGovQ10Py9L4DLbWyTCfpQmOr4f/7ik9V6ZYRwGg2UKqNm/FBjB+4t8SGwv BEaiAlERvAW/mvxP9MK3q0l6QUC6ZbySmcUBDW0qnQXul/NxnnnpYw8StIX985t1 2/8tmSu3tRPyBbwPpCxPokZ7MlhYhZJBsidBpigmyJXE8WB9DAMfKnFQevczDcny o3KFA2jvsl/E1f+7GMFGDj+6UkhgnNtkDOvw5fM9d7mzDjaem7wUzlEg== 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 vhvCUBUgTFFA; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D8F19171CC2; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Message-ID: <4F10774A.4030003@cs.tcd.ie> Date: Fri, 13 Jan 2012 18:26:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" , pkix , "tls@ietf.org" , dane References: <20120113182358.143B621F8579@ietfa.amsl.com> In-Reply-To: <20120113182358.143B621F8579@ietfa.amsl.com> X-Forwarded-Message-Id: <20120113182358.143B621F8579@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:26:34 -0000 FYI please sign up if interested but wait a few days to give folks a chance to sign up before starting in on discussion. Stephen & Sean. -------- Original Message -------- Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. From Jeff.Hodges@KingsMountain.com Fri Jan 13 14:10:51 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0AC21F849C for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.02 X-Spam-Level: X-Spam-Status: No, score=-100.02 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mDwyBg6F7u8L for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 286A921F8492 for ; Fri, 13 Jan 2012 14:10:51 -0800 (PST) Received: (qmail 16918 invoked by uid 0); 13 Jan 2012 22:04:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 13 Jan 2012 22:04:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=K5fLWk9NdcjZ1wMxoZ7a/vmj2xkxoDzn7PpB5ok02iA=; b=Mqm3PJic+5lIyaHAzT1cYeBbxaZcyMPGnFl7i59gmkvQ8FuL/Bx6eKiLG5iMYte7kl5i3+kkeL7M14pyQcH9sibLLKQBIOBFftjyEV8LUdDTQK1tR4Qw7peR0pX24FA3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RlpEJ-00033q-32; Fri, 13 Jan 2012 15:04:11 -0700 Message-ID: <4F10AA5B.8050503@KingsMountain.com> Date: Fri, 13 Jan 2012 14:04:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [saag] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 22:10:51 -0000 > On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell > wrote: >> Archive: http://www.ietf.org/mail-archive/web/therightkey/ > > This link is dead. Typo, or not yet available? works for me! see also: https://www.ietf.org/mailman/listinfo/therightkey HtH, =JeffH From ynir@checkpoint.com Sat Jan 14 01:03:54 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F85BB; Sat, 14 Jan 2012 01:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1689OwFduWb; Sat, 14 Jan 2012 01:03:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76221F85AF; Sat, 14 Jan 2012 01:03:52 -0800 (PST) X-CheckPoint: {4F11425B-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0E93o71011172; Sat, 14 Jan 2012 11:03:51 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 14 Jan 2012 11:03:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 14 Jan 2012 11:03:49 +0200 From: Yoav Nir To: =JeffH Date: Sat, 14 Jan 2012 11:03:50 +0200 Thread-Topic: [dane] Fwd: New Non-WG Mailing List: therightkey Thread-Index: AczSm25ntan/4oQoRnu1dXwzszgw8A== Message-ID: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> References: <4F10AA5B.8050503@KingsMountain.com> In-Reply-To: <4F10AA5B.8050503@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: pkix , "saag@ietf.org" , "tls@ietf.org" , dane Subject: Re: [saag] [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 09:03:54 -0000 On Jan 14, 2012, at 12:04 AM, =3DJeffH wrote: >> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell >> wrote: >>> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >>=20 >> This link is dead. Typo, or not yet available? >=20 > works for me! +1 From stephen.farrell@cs.tcd.ie Thu Jan 19 05:12:26 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5D421F85BE for ; Thu, 19 Jan 2012 05:12:26 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpiWR8lZZ4lv for ; Thu, 19 Jan 2012 05:12:25 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id A08BC21F8592 for ; Thu, 19 Jan 2012 05:12:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 617B415F812; Thu, 19 Jan 2012 13:12:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326978743; bh=vVF1fz4mzliy09 yYdDLZSV1T2H9WtthBoUpj5Y5xD7o=; b=NhyrifJKlk9rHbkbmsc9kFUAELvUUj EF1tazDypEwdYdJE+HKafHGZnYnUfSpqxz4Ub46ofo0TVo0830fm37jqIbhhyVNg 9f6Bx8NIfZyzxz622dGMh+Vs24sSbdXa2Szqx+2FJuF6qy8BQzd87nfwPEr6dWV/ O4OFGqfHhLqMc7TAGWHXbi75u0nfE3mXLrieHUJ8n7DZqTOJExW+CqRuVLh7jER0 Qj1IRymime4H5eCBWXrrzVANQzSqq/EcujioTIcdKPwMYALk23SgPeMdIjIv9L97 s41hVqr44In5cPg8B6g5ub5PUMIhOLbsamkwAYQDXbhMojkVnfNbuHkw== 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 ct+7-dLuhDd1; Thu, 19 Jan 2012 13:12:23 +0000 (GMT) Received: from [10.87.48.9] (unknown [86.46.16.116]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 8E66B15F811; Thu, 19 Jan 2012 13:12:23 +0000 (GMT) Message-ID: <4F1816B7.9070101@cs.tcd.ie> Date: Thu, 19 Jan 2012 13:12:23 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" , Adrian Farrel References: <018201ccd6ab$9628a6e0$c279f4a0$@olddog.co.uk> In-Reply-To: <018201ccd6ab$9628a6e0$c279f4a0$@olddog.co.uk> X-Forwarded-Message-Id: <018201ccd6ab$9628a6e0$c279f4a0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [saag] Fwd: [Roll] FW: Smart Object Security Workshop Announcement X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 13:12:26 -0000 Sort-of ditto:-) S -------- Original Message -------- Subject: [Roll] FW: Smart Object Security Workshop Announcement Date: Thu, 19 Jan 2012 13:09:26 -0000 From: Adrian Farrel Reply-To: adrian@olddog.co.uk To: I am unclear as to why this announcement was not also sent to the ROLL working group, but I have no objection to you knowing about it :-) Cheers, Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Hannes > Tschofenig > Sent: 19 January 2012 10:22 > To: IETF-Discussion list > Subject: Smart Object Security Workshop Announcement > > Hi all, > > we would like to make you aware of a workshop on Smart Object Security on the > 23rd March 2012 in Paris (attached to the IETF meeting). > > We are seeking input from participants to share their thoughts about the ability > to utilize existing and widely deployed security mechanisms for smart objects. > > In particular, we are interested to hear about: > . What techniques for issuing credentials have been deployed? > . What extensions are useful to make existing security protocols more > suitable for smart objects? > . What type of credentials are frequently used? > . What experience has been gained when implementing and deploying > application layer, transport layer, network layer, and link layer security > mechanisms (or a mixture of all of them)? > . How can "clever" implementations make security protocols a better fit > for constrained devices? > . Are there lessons we can learn from existing deployments? > > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ > > If you plan to participate at the workshop please drop us a message (with a short > description of what you are planning to contribute) and we can give you an early > notice regarding your participation. > > Greetings > The Workshop Organizers > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pkampana@cisco.com Tue Jan 24 14:06:06 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 242FA21F848F for ; Tue, 24 Jan 2012 14:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.982 X-Spam-Level: X-Spam-Status: No, score=-7.982 tagged_above=-999 required=5 tests=[AWL=1.417, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMAbsIH8J3kF for ; Tue, 24 Jan 2012 14:06:05 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 09CFA21F8484 for ; Tue, 24 Jan 2012 14:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkampana@cisco.com; l=4377; q=dns/txt; s=iport; t=1327442765; x=1328652365; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=nZtmBwI68mWvrsaCiArbBOAmB438qwPJE8ZvS0fZ6Nk=; b=lofUnCpt6bsVHqTKlmloExkfg/pM3cGThTsh81V2+KWP7bAcvtrGtsAN e40kUsdXF5VC1pNlmWx2JZB44WAyn7Pl3PKLeeJRhLn74vBycAe1u2TBl Z8Dzj023X/gv6bEFJ+C34HUE+5WA6D2kUtifJSPogB79zkkOf1202uGQL w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMApH0+tJXG+/2dsb2JhbABCDgifLY5ygQWBcgEBAQMBAQEBBQoBFQIQNAsFBwEDAgkOAQIEAQEBGA8HGQ4fCQgBAQQBEgsQB4daCJoKAZ4TiQoBGwIBCAkFBhIJg2AcGYMaBIg/hQWZcFU X-IronPort-AV: E=Sophos;i="4.71,564,1320624000"; d="scan'208";a="53574736" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 24 Jan 2012 22:06:04 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q0OM6423031109; Tue, 24 Jan 2012 22:06:04 GMT Received: from xmb-rcd-107.cisco.com ([72.163.62.149]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 16:06:04 -0600 Received: from WINICH1QO6NCS6 ([64.102.221.225]) by xmb-rcd-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 24 Jan 2012 16:06:04 -0600 From: "Panos Kampanakis" To: "'Dan Harkins'" , "'Steven Bellovin'" References: <583849CD-D0AD-4792-8894-04598898BA0F@cs.columbia.edu> <4F04D0CD.9010807@isi.edu> <95A30BC1-F5F8-4937-AE41-08BF92B5BBB5@cs.columbia.edu> <1c680c52d4a354cdeda0a39e9cc47d32.squirrel@www.trepanning.net> In-Reply-To: <1c680c52d4a354cdeda0a39e9cc47d32.squirrel@www.trepanning.net> Date: Tue, 24 Jan 2012 17:05:38 -0500 Organization: Cisco Systems Inc. Message-ID: <004e01ccdae4$4e414200$eac3c600$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AczNGzmJOYMOvOAXRNeXRdV0+uJ2aANxq4lA Content-Language: en-us X-OriginalArrivalTime: 24 Jan 2012 22:06:04.0102 (UTC) FILETIME=[5D623E60:01CCDAE4] Cc: cfrg@irtf.org, saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 22:06:06 -0000 Hi Steven, I agree with Dan's comments. The scheme's string that is hashed has 3 parts none of which are "random" which prevents the necessary Randomness Extraction. For example for ipsec://someuser@gw.example.net, if I knew that that service gw.example.net uses 10 iterations (seems that is known), I could build a rainbow table with usernames and dictionary passwords. Only if the iteration number changed randomly would the scheme generate passwords resilient to rainbow tables. But I don't think it currently adds security to the current scheme. Please correct me if I am wrong. > "The iteration count MUST be specified. The value -- typically in the hundreds of thousands with today's technology" Can you explain why? If the iteration number are constant for a service, what do extra iterations provide? > "SHA-512 [RFC6234] is much slower than MD5, but since the goal is constant time, this matters very little; thus, MD5 would have a higher iteration count than SHA-512 would for the same protocol." It is not clear why the goal is constant time. Regards, Panos -----Original Message----- From: saag-bounces@ietf.org [mailto:saag-bounces@ietf.org] On Behalf Of Dan Harkins Sent: Saturday, January 07, 2012 4:03 AM To: Steven Bellovin Cc: cfrg@irtf.org; saag@ietf.org Subject: Re: [saag] New draft: Hashed Password Exchange On Wed, January 4, 2012 2:56 pm, Steven Bellovin wrote: > Good point; let me think about it for -01. An obvious solution is to send > the hostname with the effective password. How is that different than using random salt then? If _something_ is going to be sent shouldn't it be a uniformly random bitstring instead of a hostname? A uniformly random bitstring would be more appropriate as a key to HMAC than a highly structured string like a password too. Iterate HMAC(salt, password | service-URI) instead of HMAC(password, service-URI). That said, goal 4 in the draft-- "By iterating a sufficient number of times, dictionary attacks can be made arbitrarily expensive"-- seems a bit misguided. The Amazon cloud service has been used to launch an off-line dictionary attack against the WPA-PSK protocol which uses PBKDF2 (HMAC-SHA1) with 4096 iterations to obfuscate a password. This attack checks 24,000,000 candidate passwords per minute at a cost of $0.28. That's more than 1,600,000,000 iterations per second for about 1/2 a cent. So I don't think increased iteration makes dictionary attacks much more expensive. Which begs the question, how is this proposal different than PBKDF2? That the "salt" is a service URI? regards, Dan. > On Jan 4, 2012, at 5:21 01PM, Joe Touch wrote: > >> Hi, Steve, >> >> This doc doesn't appear to address the case where a host has multiple >> DNS names, which could make it difficult to incorporate the hostname >> into the transform. I.e., I could contact a mail server at an IP address >> that represents any of dozens of DNS names - how does the server know >> which one I used so it can match without exhaustively trying all its >> equivalent names? >> >> Joe >> >> On 1/4/2012 1:41 PM, Steven Bellovin wrote: >>> I'd appreciate comments on my new draft, draft-bellovin-hpw-00.txt: >>> >>> Abstract >>> >>> Many systems (e.g., cryptographic protocols relying on symmetric >>> cryptography) require that plaintext passwords be stored. Given how >>> often people reuse passwords on different systems, this poses a very >>> serious risk if a single machine is compromised. We propose a >>> scheme >>> to derive passwords limited to a single machine from a typed >>> password, and explain how a protocol definition can specify this >>> scheme. >>> >>> >>> --Steve Bellovin, https://www.cs.columbia.edu/~smb >>> >>> >>> >>> >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> > > > --Steve Bellovin, https://www.cs.columbia.edu/~smb > > > > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From stephen.farrell@cs.tcd.ie Sun Jan 29 09:33:05 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DEC721F858A for ; Sun, 29 Jan 2012 09:33:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.133 X-Spam-Level: X-Spam-Status: No, score=-102.133 tagged_above=-999 required=5 tests=[AWL=0.466, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQK7PkqH11Qf for ; Sun, 29 Jan 2012 09:33:04 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id ED23F21F8581 for ; Sun, 29 Jan 2012 09:33:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 40D0D171CDB; Sun, 29 Jan 2012 17:33:02 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1327858381; bh=cIwvUI1WsFwmH1 YTqTFUWVVSQcu2GzCZfOwdXeYbO9A=; b=wgLFl5LBWQLBdz8he0Q/dpES1Trf9D Nw0O0NSkgyVizsL20t8+wXHEMHzjp7H1OETN0lMl8ANpmxp00xuCXtnk6n8uyJtk vhBi3M4utdYuhrDNAHC9ppPPkQZzP6AA6fQX+Rw6hdhjOj4HJeBnGMFZLcAteqOL KV7EfHkBy8TenB+6WmbwMRBe2l1pNlDLD214HNegTl51N4zMUfgDJJyIn/0p3Mjd 2z3r+YmQ7OULSU+WvYi0edw670r0tTrwRt74tICqZI00IF/Yz/ct6djAkrhLZxBt vcx6TAWE8ZLZR7uf3bHR+2D68TA7lXEUtdXW6fMAblNIkSTyfojjUsig== 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 2aDu-LOZa0EB; Sun, 29 Jan 2012 17:33:01 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.46.20.127]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id DAF33171CDC; Sun, 29 Jan 2012 17:33:00 +0000 (GMT) Message-ID: <4F2582CC.10705@cs.tcd.ie> Date: Sun, 29 Jan 2012 17:33:00 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" References: <4F2567DA.3060608@gmx.de> <4F256840.4070403@gmx.de> In-Reply-To: <4F256840.4070403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke Subject: Re: [saag] [apps-discuss] Fwd: Informal Last Call for draft-reschke-basicauth-enc-04, was: Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2012 17:33:05 -0000 Forwarding to saag, (has already been sent to http-auth) S On 01/29/2012 03:39 PM, Julian Reschke wrote: > (FYI) > > -------- Original Message -------- > Subject: Informal Last Call for draft-reschke-basicauth-enc-04, was: > Fwd: I-D Action: draft-reschke-basicauth-enc-04.txt > Date: Sun, 29 Jan 2012 16:38:02 +0100 > From: Julian Reschke > To: HTTP Working Group > > Hi there, > > I just submitted a new revision of d draft-reschke-basicauth-enc - see > below (HTML version at > ; > this version also includes new hooks for providing feedback; please try!). > > At this point, I'd like to solicit additional feedback before I proceed; > in particular: should this potentially be an Applications Area WG > deliverable? > > With respect to intended status: in theory, this is a candidate for > Experimental. However, Basic Authentication (as defined in RFC 2617) > doesn't have a registry for extension parameters, so the cleanest > approach appears to say "Updates 2617", which IMHO requires a standards > track document. > > Best regards, Julian > > > -------- Original Message -------- > Subject: I-D Action: draft-reschke-basicauth-enc-04.txt > Date: Sun, 29 Jan 2012 07:28:40 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : An Encoding Parameter for HTTP Basic Authentication > Author(s) : Julian F. Reschke > Filename : draft-reschke-basicauth-enc-04.txt > Pages : 9 > Date : 2012-01-29 > > The "Basic" authentication scheme defined in RFC 2617 does not > properly define how to treat non-ASCII characters. This has lead to > a situation where user agent implementations disagree, and servers > make different assumptions based on the locales they are running in. > There is little interoperability for characters in the ISO-8859-1 > character set, and even less interoperability for any characters > beyond that. > > This document defines a backwards-compatible extension to "Basic", > specifying the server's character encoding expectation, using a new > authentication scheme parameter. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-reschke-basicauth-enc-04.txt > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss From eric_bianchetti@yahoo.com Mon Jan 30 20:48:46 2012 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 219C811E8113 for ; Mon, 30 Jan 2012 20:48:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2sUig-w-rvh for ; Mon, 30 Jan 2012 20:48:45 -0800 (PST) Received: from nm24-vm4.bullet.mail.ne1.yahoo.com (nm24-vm4.bullet.mail.ne1.yahoo.com [98.138.91.184]) by ietfa.amsl.com (Postfix) with SMTP id 1BB6B21F872E for ; Mon, 30 Jan 2012 20:48:45 -0800 (PST) Received: from [98.138.90.53] by nm24.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000 Received: from [98.138.87.8] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000 Received: from [127.0.0.1] by omp1008.mail.ne1.yahoo.com with NNFMP; 31 Jan 2012 04:48:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 131759.69040.bm@omp1008.mail.ne1.yahoo.com Received: (qmail 10259 invoked by uid 60001); 31 Jan 2012 04:48:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1327985321; bh=ZuLu0Qm09UDI4ykop2hLqu0mCL1mn6hLxmTcYxkewqY=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=kviFAeI6zJbB5sk60JCU+6K/fOWcc8kSNaCJfitLAL9D/yZIZT9RI+JqR2YbEmNYfbH/+XZl0oPH/i9hhJERgh8Jhy1ZLn45oIOydZV3Za2kv5e38sXH2fO/bRlPffN+1jJMwCVYMlbaNRUZbhigffT8NALEagIuhMqYtZYRubM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=FJ5iHSCAYqZG8lNfJKRdx2hWhQcdoTNVKSQ5rOq4TPpUFt2Pznmlykv8K5tfroE3BjrcIYnlpOxopfWyQPtiJ6LWnlrYahL5uLWJZtFZdpyZetRqgeU23vvBdUcJunbuZfCjOzovBmGaocnDR7336tv4Vh0Ss/CyE9owNS40Uq8=; X-YMail-OSG: 98IVG48VM1kbkkcOH8xD0nc_0tA5r.uS7xKHllVnWktxEsw aXCaN8aP8RCTK.pZ_sYag4nbmgAtyUhjmT4v1AE_EgfAXXAse2u5aJc69wh4 4X7ySNBh.6THQNG6ZfxaRtRxf.gPhLhnlixf.KDuust.QV_rr0yiJD3rzftG .Wvtx3umrZJbXrq.140y8fKC_ZE0lMozCYLzq2DmJGEzg04886wojQs8w1Mx 0avYiCgm5tyPvcAnIN0yq3V4cLnjTk3KujGWsvKINAzIIoXYC9VVCs09SZVI BLfVsFGkKwiExDYVPzAgJWon5ylGRI1mMlXsViiWDD7cX_TnpFTUpTpK9y3q L1vPKy.tZlPnRCcXFwlBW1GSHRoNGn84LLdL1LJIoFFVw4cEDRkUKB0k28tJ qAP_VQxvSQgz8UJx6ah1hjrKg9dyx49KMdOqSB3C8Wy9gKIvxaDn5LrTLEwZ g09n7x0mcvgG08fN9T5VJaKwCdqA5vzHghBih031UlxZ5OTZhF.srEXY- Received: from [171.99.144.138] by web130202.mail.mud.yahoo.com via HTTP; Mon, 30 Jan 2012 20:48:41 PST X-Mailer: YahooMailWebService/0.8.116.331537 References: <4F10AA5B.8050503@KingsMountain.com> <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> Message-ID: <1327985321.8147.YahooMailNeo@web130202.mail.mud.yahoo.com> Date: Mon, 30 Jan 2012 20:48:41 -0800 (PST) From: eric bianchetti To: Yoav Nir , =JeffH In-Reply-To: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Subject: Re: [saag] [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: eric bianchetti List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2012 04:48:46 -0000 works here ----- Original Message ----- From: Yoav Nir To: =JeffH Cc: pkix ; "saag@ietf.org" ; "tls@ietf.org" ; dane Sent: Saturday, January 14, 2012 4:03 PM Subject: Re: [saag] [dane] Fwd: New Non-WG Mailing List: therightkey On Jan 14, 2012, at 12:04 AM, =JeffH wrote: >> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell >> wrote: >>> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >> >> This link is dead. Typo, or not yet available? > > works for me! +1 _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag