From ynir@checkpoint.com Sun Jun 2 07:15:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8DF21F8763 for ; Sun, 2 Jun 2013 07:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 lDJg1UTRz6j1 for ; Sun, 2 Jun 2013 07:15:06 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9A53621F86D3 for ; Sun, 2 Jun 2013 07:15:05 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r52EErqO023100; Sun, 2 Jun 2013 17:14:54 +0300 X-CheckPoint: {51AB535D-6-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 2 Jun 2013 17:14:53 +0300 From: Yoav Nir To: Manu Sporny Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXNCUYG81z6it50uOOoWJpR8ZCpkiSyoA Date: Sun, 2 Jun 2013 14:14:52 +0000 Message-ID: <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> <51A6A3C0.60100@digitalbazaar.com> In-Reply-To: <51A6A3C0.60100@digitalbazaar.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.15] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 113140579976660c4ed84ec831aefbc4f0ed430ed6 Content-Type: text/plain; charset="us-ascii" Content-ID: <473B83E5B0BF744D9C115319BC463709@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 14:15:11 -0000 On May 30, 2013, at 3:56 AM, Manu Sporny wrote: > On 05/29/2013 05:15 AM, Yoav Nir wrote: >> On May 29, 2013, at 11:37 AM, Stephen Farrell wrote: >>> Question is: why not just add sha256 and be done with it? >>=20 >> People like algorithm agility. This might even save us from having >> to process "SHA3-256 and its use in HTTP Authentication", "GOST R=20 >> 34.11-94 and its use in HTTP Authentication", and the same for djb2=20 >> and other algorithms. >=20 > I don't think that is a very compelling argument. The specification > should outline the best practice at the time and if there is a need to > update it to shift to another algorithm in the future, an add-on spec > can be drafted purely for that case. >=20 > Dumping a bag of algorithms into a spec is also really annoying from an > implementers standpoint. Making sure your implementation has support and > options for umpteen hashing algorithms is annoying, especially when 90% > of the use cases just use the same algorithms, and the other 9% could > use the same algorithms, but choose not to because they think it buys > them some sort of advantage (when it usually does not). >=20 > Bags of algorithms also confuse developers and make using the API really > annoying in the default case where you just want to use a set of > reasonable defaults. "Should I use SHA-256 or SHA-1? Hmm, let me see > what the remote end is using... crap, they're using MD5." >=20 > The Web Keys specifications as well as the Web Payments specifications > all outline one way of hashing and encrypting/decrypting. There are > backups that are ready to go when the current approaches fail, but the > specs outline the best practice and make that the only normative > implementation requirement. >=20 > -1 to bags of algorithms in specs, we should stop this bad practice. [No_hats] I agree it's bad, but unless we want to create "digest2" that always uses S= HA2-256, (and if we don't, switching to SHA3 would mean "digest3") we are g= oing to have an algorithm field. And if we're going to have an algorithm fi= eld, we have to have a list of values to use there: SHA2-256; SHA3-256. And= if we have a list of values, people are going to write specs to update tha= t list with their favorite algorithm. We could reduce the interop pain by having mandatory-to-implement algorithm= s, but mandatory to implement does not mean mandatory to deploy, and if som= eone from Russia tells you that authentication to websites that carry perso= nal data requires the use of GOST algorithms, can any of us tell them they'= re wrong? I could see having text like "compliant implementations of this specificati= on MUST implement the SHA2-256 algorithm, and SHOULD have it enabled in dep= loyment unless the legal situation mandates a different algorithm". It help= s interop with those who would like to interoperate, while not forcing thos= e with vanity crypto to make their own methods. [/No_hats] [Chair_hat on] So far all the comments have been around this issue of multiple algorithms.= Is this the only problem people have with this draft? If so, then I would= like to accept it, and immediately open an issue in the tracker. Then we c= an continue to discuss it on the list and in Berlin. Any objections? Yoav= From paul.hoffman@vpnc.org Sun Jun 2 07:32:31 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0676D21F8B90 for ; Sun, 2 Jun 2013 07:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.949 X-Spam-Level: X-Spam-Status: No, score=-101.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 AYIbtGKIOsJT for ; Sun, 2 Jun 2013 07:32:30 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 860F521F8C1A for ; Sun, 2 Jun 2013 07:32:30 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-173.dsl.dynamic.sonic.net [50.1.98.173]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r52EWIM0088092 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 2 Jun 2013 07:32:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Paul Hoffman In-Reply-To: <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> Date: Sun, 2 Jun 2013 07:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> <51A6A3C0.60100@digitalbazaar.com> <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> To: Yoav Nir X-Mailer: Apple Mail (2.1503) Cc: http-auth@ietf.org Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 14:32:31 -0000 On Jun 2, 2013, at 7:14 AM, Yoav Nir wrote: > We could reduce the interop pain by having mandatory-to-implement = algorithms, but mandatory to implement does not mean mandatory to = deploy, and if someone from Russia tells you that authentication to = websites that carry personal data requires the use of GOST algorithms, = can any of us tell them they're wrong? Yes. And we could tell the U.S. and { fill in your most or least = favorite country } the same. > I could see having text like "compliant implementations of this = specification MUST implement the SHA2-256 algorithm, and SHOULD have it = enabled in deployment unless the legal situation mandates a different = algorithm". It helps interop with those who would like to interoperate, = while not forcing those with vanity crypto to make their own methods. And I'm with manu on this one: no algorithm agility other than "create a = new spec". --Paul Hoffman From ynir@checkpoint.com Sun Jun 2 08:24:20 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E42421F8540 for ; Sun, 2 Jun 2013 08:24:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Sz0pSo-QlcDl for ; Sun, 2 Jun 2013 08:24:08 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 670EB21F848E for ; Sun, 2 Jun 2013 08:24:07 -0700 (PDT) Received: from DAG-EX10.ad.checkpoint.com ([194.29.34.150]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r52FO1Jv001340; Sun, 2 Jun 2013 18:24:05 +0300 X-CheckPoint: {51AB6391-0-1B221DC2-1FFFF} Received: from IL-EX10.ad.checkpoint.com ([169.254.2.54]) by DAG-EX10.ad.checkpoint.com ([169.254.3.48]) with mapi id 14.02.0342.003; Sun, 2 Jun 2013 18:24:00 +0300 From: Yoav Nir To: Paul Hoffman Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXNCUYG81z6it50uOOoWJpR8ZCpkiSyoAgAAE44CAAA5tgA== Date: Sun, 2 Jun 2013 15:23:59 +0000 Message-ID: References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> <51A6A3C0.60100@digitalbazaar.com> <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean x-cpdlp: 1178774ab1b80aad37ecf22055d4e078720d3c3f32 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 15:24:20 -0000 On Jun 2, 2013, at 5:32 PM, Paul Hoffman wrote: > On Jun 2, 2013, at 7:14 AM, Yoav Nir wrote: >=20 >> We could reduce the interop pain by having mandatory-to-implement algori= thms, but mandatory to implement does not mean mandatory to deploy, and if = someone from Russia tells you that authentication to websites that carry pe= rsonal data requires the use of GOST algorithms, can any of us tell them th= ey're wrong? >=20 > Yes. And we could tell the U.S. and { fill in your most or least favorite= country } the same. >=20 >> I could see having text like "compliant implementations of this specific= ation MUST implement the SHA2-256 algorithm, and SHOULD have it enabled in = deployment unless the legal situation mandates a different algorithm". It h= elps interop with those who would like to interoperate, while not forcing t= hose with vanity crypto to make their own methods. >=20 > And I'm with manu on this one: no algorithm agility other than "create a = new spec". >=20 And are you also OK with discussing this while the draft is a WG draft (rat= her than a candidate)? Yoav From stephen.farrell@cs.tcd.ie Sun Jun 2 08:35:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B3F21F8FB6 for ; Sun, 2 Jun 2013 08:35:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqKaysiQS3m8 for ; Sun, 2 Jun 2013 08:35:04 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B2FEC21F8FAF for ; Sun, 2 Jun 2013 08:35:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5CDAABE5B; Sun, 2 Jun 2013 16:34:38 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5wUNpieFLDF; Sun, 2 Jun 2013 16:34:35 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.23.7]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 58377BE4D; Sun, 2 Jun 2013 16:34:35 +0100 (IST) Message-ID: <51AB6601.5040409@cs.tcd.ie> Date: Sun, 02 Jun 2013 16:34:25 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Paul Hoffman References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> <51A6A3C0.60100@digitalbazaar.com> <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: http-auth@ietf.org Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 15:35:09 -0000 On 06/02/2013 03:32 PM, Paul Hoffman wrote: > On Jun 2, 2013, at 7:14 AM, Yoav Nir wrote: > >> We could reduce the interop pain by having mandatory-to-implement algorithms, but mandatory to implement does not mean mandatory to deploy, and if someone from Russia tells you that authentication to websites that carry personal data requires the use of GOST algorithms, can any of us tell them they're wrong? > > Yes. And we could tell the U.S. and { fill in your most or least favorite country } the same. > >> I could see having text like "compliant implementations of this specification MUST implement the SHA2-256 algorithm, and SHOULD have it enabled in deployment unless the legal situation mandates a different algorithm". It helps interop with those who would like to interoperate, while not forcing those with vanity crypto to make their own methods. > > And I'm with manu on this one: no algorithm agility other than "create a new spec". I don't think Manu said "no alg agility" but rather, "pick one and a backup." I agree with the latter but not the former. And for Yoav: yes, I'm fine if you wanna make this a WG doc now. S. > > --Paul Hoffman > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From rifatyu@avaya.com Sun Jun 2 09:05:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E321E21F907E for ; Sun, 2 Jun 2013 09:05:58 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bdH8Y93o8nOi for ; Sun, 2 Jun 2013 09:05:53 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 65A0921F8FE8 for ; Sun, 2 Jun 2013 09:05:53 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIfAQEBAQMBAQEPCx00CwwEAgEIDQQEAQEBChQJBycLFAkIAgQBDQUIGodyAQugPIwqkGITBI1LE4EHJgsHBoJaYQOdKYpogwuBaj4 X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="13869578" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 02 Jun 2013 12:05:52 -0400 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Jun 2013 12:04:52 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Sun, 2 Jun 2013 12:05:52 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Stephen Farrell , Paul Hoffman Thread-Topic: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update Thread-Index: AQHOXNCUYG81z6it50uOOoWJpR8ZCpkiSyoAgAB6O4CAABFagP//w1FA Date: Sun, 2 Jun 2013 16:05:51 +0000 Message-ID: References: <51A5BE32.1050200@cs.tcd.ie> <701DD8DF-75C8-4C87-8CC0-C293416C6578@checkpoint.com> <51A6A3C0.60100@digitalbazaar.com> <0F5A4C49-E219-4B72-B974-AE2701B00E2A@checkpoint.com> <51AB6601.5040409@cs.tcd.ie> In-Reply-To: <51AB6601.5040409@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest-auth-update X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 16:05:59 -0000 I would be fine with "limited agility", but I do not think that "no agility= " is a good idea. Regards, Rifaat > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On > Behalf Of Stephen Farrell > Sent: Sunday, June 02, 2013 11:34 AM > To: Paul Hoffman > Cc: http-auth@ietf.org > Subject: Re: [http-auth] Call for Adoption: draft-ahrens-httpbis-digest- > auth-update >=20 >=20 >=20 > On 06/02/2013 03:32 PM, Paul Hoffman wrote: > > On Jun 2, 2013, at 7:14 AM, Yoav Nir wrote: > > > >> We could reduce the interop pain by having mandatory-to-implement > algorithms, but mandatory to implement does not mean mandatory to > deploy, and if someone from Russia tells you that authentication to > websites that carry personal data requires the use of GOST algorithms, > can any of us tell them they're wrong? > > > > Yes. And we could tell the U.S. and { fill in your most or least > favorite country } the same. > > > >> I could see having text like "compliant implementations of this > specification MUST implement the SHA2-256 algorithm, and SHOULD have it > enabled in deployment unless the legal situation mandates a different > algorithm". It helps interop with those who would like to interoperate, > while not forcing those with vanity crypto to make their own methods. > > > > And I'm with manu on this one: no algorithm agility other than "create > a new spec". >=20 > I don't think Manu said "no alg agility" but rather, "pick one and a > backup." I agree with the latter but not the former. >=20 > And for Yoav: yes, I'm fine if you wanna make this a WG doc now. >=20 > S. >=20 > > > > --Paul Hoffman > > > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From msporny@digitalbazaar.com Sun Jun 2 11:04:40 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDFED21F8A0B for ; Sun, 2 Jun 2013 11:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 VdGSEYJ-GfMH for ; Sun, 2 Jun 2013 11:04:37 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id BA4F321F85C3 for ; Sun, 2 Jun 2013 11:04:19 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UjCd9-0005ZK-VD; Sun, 02 Jun 2013 14:03:49 -0400 Message-ID: <51AB88FE.6090201@digitalbazaar.com> Date: Sun, 02 Jun 2013 14:03:42 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Web Payments CG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Agenda: Web Payments Telecon - Wednesday, June 5th 2013 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 18:04:40 -0000 This weeks telecon will focus on the HTTP Signatures specification. Specifically, we will start doing a formal security audit and outline the remaining work that needs to be completed on the specification. This will be a 60 minute call. If you would like to add or change anything on the Agenda, please send the request to the mailing list before the telecon or mention the changes at the beginning of the call. The dial-in information as well as minutes and audio logs of previous meetings can be found here: https://payswarm.com/minutes/ ========== Wednesday, June 5th 2013 Time: 1500 UTC / 8am San Francisco / 11am Boston / 4pm London Digital Bazaar Telecon Bridge SIP: payswarm@digitalbazaar.com Phone US: +1.540.961.4469 x6300 irc://freenode.net/#payswarm Duration: 60 minutes Scribes: Manu, Lehn, Longley, others TBD ========== Agenda 1. ISSUE-7: HTTP Signatures Security Review Process * https://github.com/web-payments/payswarm.com/issues/7 2. Passive Attacks * Confidentiality Violations * Password Sniffing * Offline Cryptographic Attacks 3. Active Attacks * Replay Attacks * Message Insertion * Message Deletion * Message Modification * Man-In-The-Middle 4. On-path versus off-path 5. Link-local -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Thu Jun 6 14:32:58 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0511E80FD for ; Thu, 6 Jun 2013 14:32:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.105 X-Spam-Level: ** X-Spam-Status: No, score=2.105 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 QUYD5MdTe6WQ for ; Thu, 6 Jun 2013 14:32:55 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id BC43C11E8107 for ; Thu, 6 Jun 2013 14:32:54 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Ukhnh-0005Q3-Bp; Thu, 06 Jun 2013 17:32:53 -0400 Message-ID: <51B10004.5020004@digitalbazaar.com> Date: Thu, 06 Jun 2013 17:32:52 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: Web Payments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Web Payments Telecon Minutes for 2013-06-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 21:32:58 -0000 cc: IETF HTTP Auth WG (this call dealt with the HTTP Signatures spec) Thanks to Dave for co-scribing the call yesterday. The minutes for this week's Web Payments telecon are now available here: http://payswarm.com/minutes/2013-06-05/ Full text of the discussion follows for archival purposes at the W3C. Audio of the meeting is available as well (link provided below). -------------- Web Payments Community Group Telecon Minutes for 2013-06-05 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0001.html Topics: 1. Introduction to Andrei Opera 2. ISSUE-7: HTTP Signatures Security Review Process 3. Passive Attacks - Confidentiality Violations 4. Passive Attacks - Password Sniffing 5. Passive Attacks - Offline Cryptographic Attacks 6. Active Attacks - Replay 7. Telecon frequency Chair: Manu Sporny Scribe: Manu Sporny Present: Manu Sporny, Andrei Oprea, Mark Cavage, Dave Longley, Amr Fahmy, David I. Lehn, Brent Shambaugh Audio: http://payswarm.com/minutes/2013-06-05/audio.ogg Manu Sporny is scribing. Manu Sporny: Any updates to the agenda? Topic: Introduction to Andrei Opera Manu Sporny: Andrei is one of the GSoC people that submitted a GSoC application (but we didn't get enough slots to select him) [scribe assist by Dave Longley] Manu Sporny: Andrei, could you give us a brief intro? [scribe assist by Dave Longley] Andrei Oprea: I'm a 7th year CS student, interested in working on Web Payments, did a GSoC application. Andrei Oprea: I want to create an application for Web App store. Andrei Oprea: I want to have publishers submit their apps for sale, and an API that allows them to integrate into the web app store. Andrei Oprea: Publishing assets on application, you can integrate it w/ your web app, not restricted to the store. Andrei Oprea: if time permits, I want to extend on this idea, and implement in Firefox OS using mozPay API. Manu Sporny: we are currently also working with a couple of other communities to figure out how to do web payments in an open, decentralized way, we're working with the W3C in the web apps group, etc. and we'll want to introduce you to those people and we're also working with the GNURadio group to find out how to dynamically buy and sell radio spectrum to allow people to buy extra bandwidth in certain areas to watch/download high bandwidth videos, etc. [scribe assist by Dave Longley] Manu Sporny: as far as publishing the code will you be working with github? [scribe assist by Dave Longley] Andrei Oprea: Yes, I want to expand upon payswarm.js library - on github. Manu Sporny: for hosting, would you like us to host your app somewhere so you have a VM somewhere so you can have it live all the time? [scribe assist by Dave Longley] Manu Sporny: if you'd like us to host it for you, let us know, but if you have a better hosting solution, that's fine too [scribe assist by Dave Longley] Manu Sporny: whatever solution you pick we want to ensure it's up and running all the time so we can point people at it and understand the work you're doing, etc. [scribe assist by Dave Longley] Manu Sporny: no need to decide to today [scribe assist by Dave Longley] Manu Sporny: if you have any concerns or issues or questions, we'd love to help, so ask us, this IRC channel is a good way to do that [scribe assist by Dave Longley] Manu Sporny: any other questions on how things will run? [scribe assist by Dave Longley] Topic: ISSUE-7: HTTP Signatures Security Review Process https://github.com/web-payments/payswarm.com/issues/7 Manu Sporny: there's a desire from the IETF for us to do a security review of the HTTP signatures spec, typically it's the WG that does this, but it could take multiple months if we just rely on them, so we'd like to kickstart things and start the analysis to help move things along [scribe assist by Dave Longley] Manu Sporny: i'm expecting that mark cavage can help out with what some of the possible attacks/etc. are against the spec [scribe assist by Dave Longley] Dave Longley: http://en.wikipedia.org/wiki/STRIDE_(security) We're using this document as a starting point: http://tools.ietf.org/html/rfc3552 Mark Cavage: http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx Manu Sporny: we'll be using the STRIDE security model [scribe assist by Dave Longley] Manu Sporny: we'll probably break the analysis into two parts, one for HTTP and one for HTTPS because the models are different [scribe assist by Dave Longley] Manu Sporny: we could avoid doing HTTP by saying this is only good for HTTPS, but i'd like us to do something for both HTTP and HTTPS [scribe assist by Dave Longley] Manu Sporny: mark, thoughts? [scribe assist by Dave Longley] Mark Cavage: yes, HTTP and HTTPS is good. Mark Cavage: HTTPS will be short/sweet - we want to cover both so people understand the tradeoffs. Topic: Passive Attacks - Confidentiality Violations http://tools.ietf.org/html/rfc3552#section-3.2.1 Manu Sporny: we'll start with the RFC and go through it point by point because it models the doc we'll have to write, then we'll go over STRIDE [scribe assist by Dave Longley] Manu Sporny: to start, we'll look at passive attacks, where an attacker reads packets off the network but doesn't write them, 3.2 Passive Attacks [scribe assist by Dave Longley] Manu Sporny: with HTTP you can sniff anything [scribe assist by Dave Longley] Mark Cavage: I don't know if this is specific to the HTTP Authorization header. Mark Cavage: The obvious thing here is that over HTTP, someone can steal the authorization header and replay the attack. Manu Sporny: our solution to a possible replay attack here would be some kind of nonce [scribe assist by Dave Longley] Mark Cavage: Yeah, that's the implementation we have today. Manu Sporny: it would likely be a time-based nonce where the server and client would have to have their clocks reasonably in sync [scribe assist by Dave Longley] Mark Cavage: (time-based nonce) Mark Cavage: besides replay - there are no secret data, but your key information (identity) can be leaked. Mark Cavage: There's a spear-fishing attack here. Dave Longley: You may also be able to collect general information that may be private - you can look at the request, cookies, etc. This also falls under passive attack. Manu Sporny: right, and all of these things are known attacks against HTTP, we're not creating anything new here [scribe assist by Dave Longley] Amr Fahmy: Joining to listen in... [noisy connection, muting] [scribe assist by Dave Longley] Manu Sporny: my concern would be that someone could use the authorization headers and other information to reduce the brute force attack area of the private key being used [scribe assist by Dave Longley] Mark Cavage: This is kinda the "security boogeyman" issue - if you gather enough statistical information, you /might/ be able to break it. Mark Cavage: There may not be enough random entropy in the beginning, so that might be an issue... for HTTP Signatures, it's not quite random - it's the HTTP signature string. maybe random noise in front of signing string. Mark Cavage: In terms of cryptanalysis, not a big piece of data you're signing, the string isn't starting with random entropy. That said, the risk of that is incredibly low. Dave Longley: Biggest concern might be what's safe to send over HTTP or HTTPS. We aren't creating new holes here, but people might think that we're proposing a mechanism to secure data over HTTP, which HTTP Signatures is not. Dave Longley: We might want to say that doing over HTTPS is not good enough for people - for example OAuth2 - people misconfiguring their HTTPS servers all the time. So we might tell people that they want to put random information or nonce-like data in the headers that are signed. It may not be as simple as saying "We'll just use HTTPS". Mark Cavage: I'm agreeing, but we should just say what the properties are. I wouldn't actually change the spec to accomodate this cryptanalysis attack. If someone has a provable/not theoretical exploit of this, we'll jump to the next crypto algorithm. Mark Cavage: There are theoretical attacks, but there are low risks that those theoretical attacks would happen. Dave Longley: Yeah, we really need to not change the spec, just outline the issues. Mark Cavage: Yes, section on nonces is important. Dave Longley: really need to have a clear best practices section [scribe assist by Dave Longley] Manu Sporny: for 3.2.1 Confidentiality Violations, there's nothing really new here for HTTP, all the attacks that exist for HTTP exist here -- plus there may be a statistical attack that one could mount against the http signatures header that lets you do some cryptoanalysis on it to reduce a brute force attack, but we know of none [scribe assist by Dave Longley] Dave Longley: Yeah, that's probably fair - what we're doing w/ signatures is what everybody else does with that. It's the same thing that would happen if signing data and sending it over cleartext. Manu Sporny: for HTTPS the same applies, the danger that exists is the same as OAuth2, misconfigured servers or maybe not having enough random bytes/long enough signature string, etc. [scribe assist by Dave Longley] Manu Sporny: all the attacks are theoretical, it's about breaking digital signatures and/or TLS [scribe assist by Dave Longley] Topic: Passive Attacks - Password Sniffing Manu Sporny: there are no passwords [scribe assist by Dave Longley] http://tools.ietf.org/html/rfc3552#section-3.2.2 Mark Cavage: Yeah, leaking a password is not possible here - no passwords. Group agrees. David I. Lehn: Is there a problem with people not understanding public/private keys? David I. Lehn: What if spear fishers ask for a private key? David I. Lehn: It's an education problem. Dave Longley: yeah, education problem. Mark Cavage: I think this is a problem for HMAC Mark Cavage: the -----BEGIN PRIVATE KEY---- thing works pretty well as a deterrent for people sharing the information with the public. Mark Cavage: to help people understand that they shouldn't be sharing it. Mark Cavage: HMAC keys are shared publicly more often than private keys, based on what I've seen. Dave Longley: Yeah, we can educate at the application level, not the protocol level. Manu Sporny: is HMAC something we want to put into the spec or not? [scribe assist by Dave Longley] Manu Sporny: HMAC may be more likely to be shared accidentally by end users, it's less clear that HMAC keys are private [scribe assist by Dave Longley] Manu Sporny: should we keep HMAC in or take it out? [scribe assist by Dave Longley] Mark Cavage: We might just take it out of the examples... we could insert whatever algorithm you want, the spec is open about that. Mark Cavage: People could still put HMAC in... don't have strong feelings about taking it out/ putting HMAC in. I agree, I don't ever want to use HMAC again, there's concerns about performance, etc. Manu Sporny: there's a debate about listing every kind of crypto algorithm that works with a spec, the downside is that everyone has to implement all of those algorithms but when interoperating you have to ensure both sides support what you want to use, so we might have to give a few algorithms that have to be supported, it can't be as openended as it is right now [scribe assist by Dave Longley] Mark Cavage: if somebody is going to demand HMAC in, we should put one form of it in. Manu Sporny: i think if we are going to put HMAC in we should only put one in as a requirement [scribe assist by Dave Longley] Manu Sporny: if it gets broken, we'll have another spec ready to go [scribe assist by Dave Longley] Manu Sporny: the spec text can say other things can be supported and give some instructions on how to write a spec defining the other algorithm(s) etc [scribe assist by Dave Longley] Dave Longley: I think we should say RSA, SHA1 and SHA256 are supported - that's the minimum... then we can say you can implement whatever you want, give them instructions on how to do it. Manu Sporny: so we could do that and leave out HMAC for now and wait for people to come along and request it to be added [scribe assist by Dave Longley] Mark Cavage: I'm ok with that - MUST support RSA SHA1 / SHA256 - you MAY support other things like HMAC. Dave Longley: Sounds good to me. Group agreement. Manu Sporny: we were on password sniffing and HMAC sort of falls into that category (sort of) ... secret key being analogous to password, if you use RSA there are no passwords [scribe assist by Dave Longley] Mark Cavage: Let's just not mention HMAC, thus password sniffing is not possible. Topic: Passive Attacks - Offline Cryptographic Attacks http://tools.ietf.org/html/rfc3552#section-3.2.3 Manu Sporny: easier to attack over HTTP vs. HTTPS, primary attack vector may be not enough randomness to the signature string or we create some kind of mechanism that allows statistical analysis to reduce brute force attack space [scribe assist by Dave Longley] Manu Sporny: if you break HTTPS the attack is the same as HTTP [scribe assist by Dave Longley] Manu Sporny: otherwise as safe as HTTPS (TLS) [scribe assist by Dave Longley] Manu Sporny: we can just point people at the offline attacks for RSA and SHA1/SHA256 [scribe assist by Dave Longley] Topic: Active Attacks - Replay http://tools.ietf.org/html/rfc3552#section-3.3.1 Manu Sporny: so the replay attacks we're concerned about (there are two classes), the first is replay over HTTP which is fairly trivial and replay over HTTPS where you send a message over HTTPS to a proxy and the proxy replays it to someone else [scribe assist by Dave Longley] Dave Longley: Does the spec currently say you have to sign the host header. Mark Cavage: The spec should say you MUST sign request line, host header, and content MD5. Dave Longley: There are HTTP proxy issues - rewriting of headers. Mark Cavage: We should come back to that one - that's a different issue - http proxies. Mark Cavage: HTTP should be MUST for request line, host header, should we have nonces? Dave Longley: We should say how to do this w/ chunked transfer encoding - you may not want to use content-md5, may want to do this in a trailer. Dave Longley: It would allow you to send content bodies where you don't know the length. Mark Cavage: The problem with trailers, is that the implementation sucks. Ruby doesn't deal w/ them, etc. Mark Cavage: It's a miracle when you find a stack that does - I'm of two minds. I agree w/ what the RFC says, but based on reality, half the stuff out there doesn't work with it. Manu Sporny: this requirement comes from a previous product in our company that was built on a streaming architecture [scribe assist by Dave Longley] Manu Sporny: you could do digital signatures on the streams (as long as the implementatino does it correctly and there are plenty that aren't) and it was a fairly nice way to make things work [scribe assist by Dave Longley] Manu Sporny: we don't have to make it a requirement to support trailers but implementations are not required to implement it [scribe assist by Dave Longley] Manu Sporny: that would reflect reality but allow support [scribe assist by Dave Longley] Mark Cavage: So what you're saying is if you want to do this, digitally sign the header, then do continue. Mark Cavage: Then attach signatures on the trailer. Dave Longley: If you want to do chunked-transfer encoding, you can do a second signature on the body. I want to make sure we don't lock people out of using the spec if they want to use it in a certain way. Mark Cavage: Not disagreeing, I buy it. I think saying "put the authorization header at the end" doesn't help. It might open up a Denial of Service attack. We could say "if you want to sign the body and use streaming uploads, you do it in two steps". Dave Longley: If there are people that have these sorts of interfaces, where they try to simplify things and don't want to implement buffering on one end, they have to do buffering anyway to do content-md5. Dave Longley: I'd like to prevent solutions that require either end to buffer the entire streaming content. Mark Cavage: These aren't mutually exclusive. Manu Sporny: let's just make a general issue for how to do chunked transfer encoding w/signatures [scribe assist by Dave Longley] Manu Sporny: so... for replay attacks we'll need to figure out what to do about nonces [scribe assist by Dave Longley] Manu Sporny: some people feel that implementations become far more difficult when you require nonces (which is true) we want to ensure that these implementations are easy so they don't have to remember nonces forever, etc. [scribe assist by Dave Longley] Manu Sporny: so that's one reason for discussing time-based nonces [scribe assist by Dave Longley] Manu Sporny: we'll have to argue against others who simply say nonces will never work and are never implemented properly, etc. [scribe assist by Dave Longley] Manu Sporny: do we want to try and tackle the nonce problem? [scribe assist by Dave Longley] Manu Sporny: it sounds like (from the discussion at the beginning of the call) we want to try and tackle the problem because we'd like this spec to work over HTTP [scribe assist by Dave Longley] Manu Sporny: so we'll probably be looking at time-based nonces [scribe assist by Dave Longley] Mark Cavage: Are nonces MUST or MAY? Manu Sporny: it seems like the HTTP signature spec will be blamed if we don't make a it a MUST [scribe assist by Dave Longley] Manu Sporny: do you feel the same way, mark? [scribe assist by Dave Longley] Mark Cavage: The security purist in me totally agrees with you, but I don't think many people get it right. We're setting ourselves up to fail because of nonces. Mark Cavage: I don't have an answer, I'm torn. Manu Sporny: we could look at history (since it's been bad) and just do the opposite [scribe assist by Dave Longley] Manu Sporny: or it could just be that nonces really just need to be required and it has to be implemented properly [scribe assist by Dave Longley] Mark Cavage: There are 2-3 implementations of SSL, there may be many more clients that implement this. Mark Cavage: There are a lot of implementation concerns here - same hellhole, how do you run this thing at scale. Mark Cavage: If they're optional, nobody is going to do it. If they are not, we're going to get criticized for getting it wrong. Brent Shambaugh: ... listening in, no comment for now Manu Sporny: so we're still split on what should be done for nonces, we agree that we should specify something but we dont' know if it should be MUST or MAY [scribe assist by Dave Longley] Mark Cavage: Yes, we should have a section on nonces, and decide MUST vs. MAY later on. Topic: Telecon frequency Manu Sporny: ok, looks like we have enough work now to have telecons once a week, so we'll meet against next week to continue this discussion. [scribe assist by Dave Longley] -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun Jun 9 18:13:14 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8285121F8749 for ; Sun, 9 Jun 2013 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.805 X-Spam-Level: X-Spam-Status: No, score=0.805 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 kIdO1X9hVsVM for ; Sun, 9 Jun 2013 18:13:11 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id D647021F86F5 for ; Sun, 9 Jun 2013 18:13:10 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UlqfU-0000Df-BN; Sun, 09 Jun 2013 21:13:09 -0400 Message-ID: <51B5281B.6090403@digitalbazaar.com> Date: Sun, 09 Jun 2013 21:12:59 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Web Payments CG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Agenda: Web Payments Telecon - Wednesday, June 12th 2013 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 01:13:14 -0000 This weeks telecon will continue to focus on the security analysis of the HTTP Signatures specification. We're most likely not going to get through the entire Agenda, but I'm including the rest of the security analysis so that people can see where we're headed. This will be a 60 minute call. If you would like to add or change anything on the Agenda, please send the request to the mailing list before the telecon or mention the changes at the beginning of the call. The dial-in information as well as minutes and audio logs of previous meetings can be found here: https://payswarm.com/minutes/ ========== Wednesday, June 12th 2013 Time: 1500 UTC / 8am San Francisco / 11am Boston / 4pm London Digital Bazaar Telecon Bridge SIP: payswarm@digitalbazaar.com Phone US: +1.540.961.4469 x6300 irc://freenode.net/#payswarm Duration: 60 minutes Scribes: Lehn, Longley, Manu, others TBD ========== Agenda 1. Active Attacks - Message Insertion * http://tools.ietf.org/html/rfc3552#section-3.3.2 2. Active Attacks - Message Deletion * http://tools.ietf.org/html/rfc3552#section-3.3.3 3. Active Attacks - Message Modification * http://tools.ietf.org/html/rfc3552#section-3.3.4 4. Active Attacks - Man-In-The-Middle * http://tools.ietf.org/html/rfc3552#section-3.3.5 5. On-path Attacks * http://tools.ietf.org/html/rfc3552#section-3.5 6. Off-path Attacks * http://tools.ietf.org/html/rfc3552#section-3.5 7. Active Attacks - Link-local * http://tools.ietf.org/html/rfc3552#section-3.6 -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From internet-drafts@ietf.org Mon Jun 10 12:19:45 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B193921F9A93; Mon, 10 Jun 2013 12:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 RrbTyvVnIJPf; Mon, 10 Jun 2013 12:19:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ACA421F9A82; Mon, 10 Jun 2013 12:19:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51 Message-ID: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> Date: Mon, 10 Jun 2013 12:19:45 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:19:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Update Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-update-00.txt Pages : 10 Date : 2013-06-10 Abstract: This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for more digest algorithms to the HTTP Digest Access Authentication scheme. This document also specifies an extension to HTTP Digest Authentication mechanism to allow the server to indicate its character encoding support. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifatyu@avaya.com Mon Jun 10 16:15:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C72AD21F99DC for ; Mon, 10 Jun 2013 16:15:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 8+aeAojhGftl for ; Mon, 10 Jun 2013 16:14:55 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 53AB321F99CF for ; Mon, 10 Jun 2013 16:14:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArIGAAxdtlHGmAcF/2dsb2JhbABZgmghMEm+SoEDFm0HgiMBAQEBAwEBAQ8oNAYRBAIBCA0EBAEBCxQJBycLFAkIAgQKCQgah2sBC51NnAcXjwc4BoJ5YQOYaYUZiwCDD4In X-IronPort-AV: E=Sophos;i="4.87,841,1363147200"; d="scan'208";a="15510296" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 10 Jun 2013 19:14:53 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Jun 2013 19:13:24 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Mon, 10 Jun 2013 19:14:53 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "http-auth@ietf.org" Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt Thread-Index: AQHOZg+mRklQnseiHE+F+J8r8yh/2JkvkaNQ Date: Mon, 10 Jun 2013 23:14:52 +0000 Message-ID: References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> In-Reply-To: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:15:00 -0000 Compared to the original draft, besides some editorial changes, I added an = internationalization section that has the same text I sent to the mailing l= ist on March 18. I did not make any changes to the algorithm agility at this stage, as we ne= ed to conclude the discussion that has already started on the mailing list = around this issue. We would appreciate any further feedback on this document, especially aroun= d the i18n section. Regards, Rifaat > -----Original Message----- > From: http-auth-bounces@ietf.org [mailto:http-auth-bounces@ietf.org] On > Behalf Of internet-drafts@ietf.org > Sent: Monday, June 10, 2013 3:20 PM > To: i-d-announce@ietf.org > Cc: http-auth@ietf.org > Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update- > 00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Hypertext Transfer Protocol > Authentication Working Group of the IETF. >=20 > Title : HTTP Digest Update > Author(s) : Rifaat Shekh-Yusef > David Ahrens > Filename : draft-ietf-httpauth-digest-update-00.txt > Pages : 10 > Date : 2013-06-10 >=20 > Abstract: > This documents specifies extensions to the HTTP Digest Authentication > mechanism to add support for more digest algorithms to the HTTP > Digest Access Authentication scheme. >=20 > This document also specifies an extension to HTTP Digest > Authentication mechanism to allow the server to indicate its > character encoding support. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-00 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth From ynir@checkpoint.com Mon Jun 10 22:18:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D182321F9ACA for ; Mon, 10 Jun 2013 22:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 TYjhYJIlBmpg for ; Mon, 10 Jun 2013 22:18:25 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 7121921F9AC8 for ; Mon, 10 Jun 2013 22:18:25 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5B5INRH024036 for ; Tue, 11 Jun 2013 08:18:23 +0300 X-CheckPoint: {51B6B31F-11-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 08:18:23 +0300 From: Yoav Nir To: "http-auth@ietf.org" Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt Thread-Index: AQHOZg+QTqfZdgz3A0eGG5S9FeZcUJkvYjUAgABlkYA= Date: Tue, 11 Jun 2013 05:18:22 +0000 Message-ID: References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.197] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11e4b54a53796727240662f87d430f8908dd95be24 Content-Type: text/plain; charset="us-ascii" Content-ID: <779B0F5B15397F44A021832AC09A35FB@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 05:18:30 -0000 Thank you Rifaat and David for agreeing to edit this document for the worki= ng group. I have opened our very first issue ( http://trac.tools.ietf.org/wg/httpauth= /trac/ticket/1 ) on the tracker for the algorithm agility issue. Yoav On Jun 11, 2013, at 2:14 AM, "Shekh-Yusef, Rifaat (Rifaat)" wrote: > Compared to the original draft, besides some editorial changes, I added a= n internationalization section that has the same text I sent to the mailing= list on March 18. > I did not make any changes to the algorithm agility at this stage, as we = need to conclude the discussion that has already started on the mailing lis= t around this issue. >=20 > We would appreciate any further feedback on this document, especially aro= und the i18n section. >=20 > Regards, > Rifaat >=20 From julian.reschke@gmx.de Tue Jun 11 02:51:10 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B051F21F96A9 for ; Tue, 11 Jun 2013 02:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 aioQ7Tsa8lyG for ; Tue, 11 Jun 2013 02:51:03 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4E53721F8EAD for ; Tue, 11 Jun 2013 02:50:43 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LkUyL-1UEwDE17lL-00cOsf for ; Tue, 11 Jun 2013 11:50:31 +0200 Received: (qmail invoked by alias); 11 Jun 2013 09:50:31 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp020) with SMTP; 11 Jun 2013 11:50:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+KyhhpMomK4oTaCs8bwPsJ6nKROOT33nFdAP9u5h YW63lr873wbxED Message-ID: <51B6F2DF.5090906@gmx.de> Date: Tue, 11 Jun 2013 11:50:23 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:51:10 -0000 On 2013-06-11 01:14, Shekh-Yusef, Rifaat (Rifaat) wrote: > Compared to the original draft, besides some editorial changes, I added an internationalization section that has the same text I sent to the mailing list on March 18. > ... Well. I don't think we have sufficient experience with fixing the I18N right away. This is why I have proposed to try this in a separate draft for now, and that's why we have draft-ietf-httpauth-basicauth-enc-00. Similar arguments apply to Digest, and thus I'd recommend to leave the I18N issue alone until we are confident that the proposed fix indeed is going to work. What's needed right now are test cases, experimentation, and bug fixes in browsers -- not a spec that we don't know is going to work in practice. Best regards, Julian From rifatyu@avaya.com Tue Jun 11 06:26:03 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C95C921F8EB3 for ; Tue, 11 Jun 2013 06:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 bZNITF6B2pFt for ; Tue, 11 Jun 2013 06:25:49 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 104D521F8DE4 for ; Tue, 11 Jun 2013 06:25:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFACokt1GHCzI1/2dsb2JhbABZgmghMEm+S30WdIIjAQEBAQMSKDQLDAQCAQgNBAQBAQEKFAkHMhQJCAIEDgUIGodZAw8BngGcQ4xUgi0xBwaCeWEDngKLAIMPgic X-IronPort-AV: E=Sophos;i="4.87,845,1363147200"; d="scan'208";a="12651135" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Jun 2013 09:25:47 -0400 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jun 2013 09:20:59 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 09:25:45 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Julian Reschke Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt Thread-Index: AQHOZg+mRklQnseiHE+F+J8r8yh/2JkvkaNQgAD3eoD///g3MA== Date: Tue, 11 Jun 2013 13:25:44 +0000 Message-ID: References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> In-Reply-To: <51B6F2DF.5090906@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:26:03 -0000 Thanks Julian, I would be ok with creating a separate experimental document to specificall= y deal with the i18n for Digest. Any other opinions on this issue? Regards, Rifaat > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, June 11, 2013 5:50 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: http-auth@ietf.org > Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update- > 00.txt >=20 > On 2013-06-11 01:14, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Compared to the original draft, besides some editorial changes, I > added an internationalization section that has the same text I sent to > the mailing list on March 18. > > ... >=20 > Well. >=20 > I don't think we have sufficient experience with fixing the I18N right > away. This is why I have proposed to try this in a separate draft for > now, and that's why we have draft-ietf-httpauth-basicauth-enc-00. >=20 > Similar arguments apply to Digest, and thus I'd recommend to leave the > I18N issue alone until we are confident that the proposed fix indeed is > going to work. >=20 > What's needed right now are test cases, experimentation, and bug fixes > in browsers -- not a spec that we don't know is going to work in > practice. >=20 > Best regards, Julian From julian.reschke@gmx.de Tue Jun 11 06:39:43 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31321F9981 for ; Tue, 11 Jun 2013 06:39:43 -0700 (PDT) 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, 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 JKSn-b+sUfK3 for ; Tue, 11 Jun 2013 06:39:37 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61F21F997E for ; Tue, 11 Jun 2013 06:39:37 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MXTLc-1UpCtt3sZy-00WZuS for ; Tue, 11 Jun 2013 15:39:35 +0200 Received: (qmail invoked by alias); 11 Jun 2013 13:39:35 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.105]) [217.91.35.233] by mail.gmx.net (mp027) with SMTP; 11 Jun 2013 15:39:35 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18N0U9Sor4NQf7peJAOmJCmSPJV45tYxnxZ2a/qdC KvFJ5NeMkeJbBp Message-ID: <51B72894.2060705@gmx.de> Date: Tue, 11 Jun 2013 15:39:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 13:39:43 -0000 On 2013-06-11 15:25, Shekh-Yusef, Rifaat (Rifaat) wrote: > Thanks Julian, > > I would be ok with creating a separate experimental document to specifically deal with the i18n for Digest. > > Any other opinions on this issue? > > Regards, > Rifaat Whatever the answer is, it would be good if it was the same for Basic and Digest :-) Best regards, Julian From paul.hoffman@vpnc.org Tue Jun 11 07:09:30 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6905D21F9921 for ; Tue, 11 Jun 2013 07:09:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 V-GQVxa7eZbU for ; Tue, 11 Jun 2013 07:09:29 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id DC70F21F991F for ; Tue, 11 Jun 2013 07:09:29 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5BE9JM1083445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Jun 2013 07:09:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51B72894.2060705@gmx.de> Date: Tue, 11 Jun 2013 07:09:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07167D62-B78A-4196-8282-AC406A46DD86@vpnc.org> References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> <51B72894.2060705@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1508) Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 14:09:30 -0000 On Jun 11, 2013, at 6:39 AM, Julian Reschke = wrote: > Whatever the answer is, it would be good if it was the same for Basic = and Digest :-) +1, and +1 to having it as a separate draft so that implementers see the = emphasis on it being experimental. Like Julian, I am skeptical that = we're going to get this right quickly. --Paul Hoffman= From rifatyu@avaya.com Tue Jun 11 11:39:41 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECD721F9412 for ; Tue, 11 Jun 2013 11:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 0h-FKVBSAPjQ for ; Tue, 11 Jun 2013 11:39:35 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8B54C21F9476 for ; Tue, 11 Jun 2013 11:39:34 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAG5tt1GHCzI1/2dsb2JhbABZgmghMEm+ToEBFnSCIwEBAQEDEig/DAQCAQgNBAQBAQEKFAkHMhQJCAIEDgUIGodZAw8BnimcEoxUgSeBBjEHBoJ5YQOeAosAgw+BaT4 X-IronPort-AV: E=Sophos;i="4.87,846,1363147200"; d="scan'208";a="15656977" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Jun 2013 14:39:33 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jun 2013 14:34:35 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 14:39:23 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Julian Reschke Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt Thread-Index: AQHOZg+mRklQnseiHE+F+J8r8yh/2JkvkaNQgAD3eoD///g3MIAAR88AgAAO73A= Date: Tue, 11 Jun 2013 18:39:21 +0000 Message-ID: References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> <51B72894.2060705@gmx.de> In-Reply-To: <51B72894.2060705@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:39:41 -0000 Well, Basic does not have the ability to negotiate a proper encoding, while= Digest does not have that limitation. Why would you limit Digest because of the Basic limitation? Regards, Rifaat > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, June 11, 2013 9:40 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: http-auth@ietf.org > Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update- > 00.txt >=20 > On 2013-06-11 15:25, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Thanks Julian, > > > > I would be ok with creating a separate experimental document to > specifically deal with the i18n for Digest. > > > > Any other opinions on this issue? > > > > Regards, > > Rifaat >=20 > Whatever the answer is, it would be good if it was the same for Basic > and Digest :-) >=20 > Best regards, Julian From julian.reschke@gmx.de Tue Jun 11 11:46:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3811021F994A for ; Tue, 11 Jun 2013 11:46:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pC9CnJgBxfb4 for ; Tue, 11 Jun 2013 11:46:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2772421F9997 for ; Tue, 11 Jun 2013 11:46:48 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.19]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LsMuE-1UOJwc3Gyu-0120NS for ; Tue, 11 Jun 2013 20:46:46 +0200 Received: (qmail invoked by alias); 11 Jun 2013 18:46:46 -0000 Received: from p54BB30E0.dip0.t-ipconnect.de (EHLO [192.168.178.36]) [84.187.48.224] by mail.gmx.net (mp019) with SMTP; 11 Jun 2013 20:46:46 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+i/cIW7emiHXhiRVtpEyYM4qgvo6d2407GOa1Owx 5Iqn6Yud8jfK5E Message-ID: <51B77093.60606@gmx.de> Date: Tue, 11 Jun 2013 20:46:43 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> <51B72894.2060705@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:46:54 -0000 On 2013-06-11 20:39, Shekh-Yusef, Rifaat (Rifaat) wrote: > Well, Basic does not have the ability to negotiate a proper encoding, while Digest does not have that limitation. > Why would you limit Digest because of the Basic limitation? > ... Well, Basic *could* negotiate (in that the server could state what it wants). The key issue here is to find something that is as simple and possible *and* deployable in practice. Maybe the requirements for Digest are different, because (IMHO) it's not as widely used as Basic? Best regards, Julian From rifatyu@avaya.com Tue Jun 11 11:53:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A5821F9928 for ; Tue, 11 Jun 2013 11:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.932 X-Spam-Level: X-Spam-Status: No, score=-2.932 tagged_above=-999 required=5 tests=[AWL=-0.333, 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 eJ9WWCA-9H8g for ; Tue, 11 Jun 2013 11:53:02 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id C86F521F991F for ; Tue, 11 Jun 2013 11:53:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAP1wt1GHCzI1/2dsb2JhbABZgmghMEm+ToEBFnSCIwEBAQEDEig/DAQCAQgNBAQBAQEKFAkHMhQJCAIEDgUIGodZAw8BniScEYxUgSeBBjEHBoJ5YQOeAosAgw+BaT4 X-IronPort-AV: E=Sophos;i="4.87,846,1363147200"; d="scan'208";a="15658712" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 11 Jun 2013 14:53:02 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Jun 2013 14:48:14 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Tue, 11 Jun 2013 14:53:01 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Julian Reschke Thread-Topic: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt Thread-Index: AQHOZg+mRklQnseiHE+F+J8r8yh/2JkvkaNQgAD3eoD///g3MIAAR88AgAAO73CAAEblgP//veCw Date: Tue, 11 Jun 2013 18:53:00 +0000 Message-ID: References: <20130610191945.15346.48785.idtracker@ietfa.amsl.com> <51B6F2DF.5090906@gmx.de> <51B72894.2060705@gmx.de> <51B77093.60606@gmx.de> In-Reply-To: <51B77093.60606@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 18:53:09 -0000 I will document both approaches in a new draft, and then open it for discus= sion. Regards, Rifaat > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Tuesday, June 11, 2013 2:47 PM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: http-auth@ietf.org > Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-digest-update- > 00.txt >=20 > On 2013-06-11 20:39, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Well, Basic does not have the ability to negotiate a proper encoding, > while Digest does not have that limitation. > > Why would you limit Digest because of the Basic limitation? > > ... >=20 > Well, Basic *could* negotiate (in that the server could state what it > wants). >=20 > The key issue here is to find something that is as simple and possible > *and* deployable in practice. Maybe the requirements for Digest are > different, because (IMHO) it's not as widely used as Basic? >=20 > Best regards, Julian >=20 From msporny@digitalbazaar.com Tue Jun 11 19:44:16 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E2CA21F99DB for ; Tue, 11 Jun 2013 19:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.155 X-Spam-Level: X-Spam-Status: No, score=0.155 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 xjMZP7v4m8fG for ; Tue, 11 Jun 2013 19:44:12 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id ADCCB21F99C1 for ; Tue, 11 Jun 2013 19:44:12 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Umb2f-00040l-CW; Tue, 11 Jun 2013 22:44:10 -0400 Message-ID: <51B7E073.2090004@digitalbazaar.com> Date: Tue, 11 Jun 2013 22:44:03 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Web Payments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] HTTP Signatures security considerations X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 02:44:16 -0000 I took about two hours today to start the Security Considerations for HTTP Signatures document. It has a very long way to go. The latest editor's draft can be found here: https://payswarm.com/specs/source/http-signatures-audit/ We're going to be discussing this in more detail during the call tomorrow. Once we're done with the security audit of the spec, we can fix up any issues that we find in the main spec text and ask for a more public review of the complete spec. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Wed Jun 12 11:44:12 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6BE21E809A for ; Wed, 12 Jun 2013 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.062 X-Spam-Level: X-Spam-Status: No, score=-0.062 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 HIfUsH8dhVq2 for ; Wed, 12 Jun 2013 11:44:08 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCC211E80E8 for ; Wed, 12 Jun 2013 11:44:08 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1Umq1Y-0007pp-Sl; Wed, 12 Jun 2013 14:44:00 -0400 Message-ID: <51B8C170.6020603@digitalbazaar.com> Date: Wed, 12 Jun 2013 14:44:00 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: Web Payments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Web Payments Telecon Minutes for 2013-06-05 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2013 18:44:12 -0000 cc: IETF HTTP Auth WG (this call dealt with the HTTP Signatures spec) Thanks to Dave Lehn for scribing the call today. The minutes for this week's Web Payments telecon are now available here: http://payswarm.com/minutes/2013-06-12/ Full text of the discussion follows for archival purposes at the W3C. Audio of the meeting is available as well (link provided below). -------------- Web Payments Community Group Telecon Minutes for 2013-06-12 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0021.html Topics: 1. Security Considerations for HTTP Signatures 2. Nonces and Trailers 3. Amr Fahmy and Summer of Code 4. Active Attacks - Message Insertion 5. Active Attacks - Message Deletion / Modification 6. Active Attacks - Man-In-The-Middle 7. On-path / Off-path Attacks / Link-Local 8. Next Steps Resolutions: 1. Add a section on nonces to the HTTP Signatures specification, but make them an optional feature. Chair: Manu Sporny Scribe: David I. Lehn Present: David I. Lehn, Manu Sporny, Mark Cavage, Dave Longley, Amr Fahmy, Brent Shambaugh Audio: http://payswarm.com/minutes/2013-06-12/audio.ogg David I. Lehn is scribing. Manu Sporny: Any updates to agenda? Topic: Security Considerations for HTTP Signatures Manu Sporny: https://payswarm.com/specs/source/http-signatures-audit/ Manu Sporny: I've started the security considerations document, going to update as we go through attacks. Manu Sporny: New attack on message insertion. Not a big deal, and don't need to change spec, but need to let people now. Topic: Nonces and Trailers Mark Cavage: Should touch on nonces and trailers. Mark Cavage: Don't want to require nonces. Make the optional and not MUST. Too difficult for wide adoption. Manu Sporny: Seemed like consensus, have nonces but make them optional. Mark Cavage: For general spec it seems like too much, for payments it may be appropriate. Manu Sporny: Personal applications may not require nonces. Manu Sporny: What do people think? PROPOSAL: Add a section on nonces to the HTTP Signatures specification, but make them an optional feature. Manu Sporny: +1 Dave Longley: +1 David I. Lehn: +1 Mark Cavage: +1 RESOLUTION: Add a section on nonces to the HTTP Signatures specification, but make them an optional feature. Dave Longley: Can detail drawbacks for not implementing nonces Manu Sporny: Let's talk about signatures in trailers. Mark Cavage: Can you send authorization twice? once in header and once in trailer Manu Sporny: How to sign content? mcavage using Content-MD5 in spec but it's being deprecated in HTTP 2. Manu Sporny: Might need to use another header (Content-SHA256) or similar Mark Cavage: Why is the HTTPbis WG removing it? Manu Sporny: Issues with proxies and partial content. Was a brittle feature. Not sure what replacement is. Dave Longley: http://tools.ietf.org/html/rfc3230 Dave Longley: Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA== Dave Longley: Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637 Manu Sporny: Bring it up since you could put sig/hash in trailer Mark Cavage: Right way to do this is checksum the body and sign the checksum. Dave Longley: Replace Content-MD5 with generic Digest header and you can set algorithm and params Manu Sporny: We will need some form of Digest Mark Cavage: No problem using some other method vs Content-MD5 Manu Sporny: Want to use trailers? Mark Cavage: May need to buffer contents to do this, should spec it out. Manu Sporny: Do we do one signature for the headers, then another one for the trailer (with just the Digest?) Dave Longley: We would want one signature for the headers, then another one in the trailer that includes all the header signature fields. That would be the most secure way of doing it. Topic: Amr Fahmy and Summer of Code Manu Sporny: Get an idea of what Amr will work on. Amr: Give a quick intro and what you need. Amr Fahmy: Computer science student in Egypt, want to work on mobile PaySwarm APIs. Very excited to be a part of this work. Amr Fahmy: started with web keys, finishing registration process Amr Fahmy: Currently stuck on issue with getting registration to work on different systems. Manu Sporny: Might be browser, IP, cache, CORS, or similar. Manu Sporny: We'll debug this after the call. Manu Sporny: Planning to work on this to get web keys registration done, then publish asset and listing for sale? Amr Fahmy: correct Manu Sporny: Any trouble looking at javascript code? Amr Fahmy: Mozilla PaySwarm tutorials were enough to get it working. Amr Fahmy: Do you need web api done before mobile api? Manu Sporny: Probably should get python api working and build on top of that knowledge for the mobile API. Manu Sporny: Thanks for showing interest and let us know how we can help! Topic: Active Attacks - Message Insertion Manu Sporny: Back to HTTP Signatures Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.2 Manu Sporny: Message insertion has to do with forging a message and inserting it in the network. Manu Sporny: difficult to do when digital signatures are used. Mark Cavage: For https this is covered by TLS. For http you should be advised to sign everything. Manu Sporny: There's attack over https with comprimised certificate with MITM attack. For a monetary transfer the MITM could fake a rejection, trick victim to send request again, MITM queues up requests and sends them later. Manu Sporny: Attacker could just replay messages, not forge them. Mark Cavage: Basically issue of what to do when TLS channel not trusted. Mark Cavage: If you just sign Date header then attacker could do anything in this case. Brent Shambaugh: neurons firing: mitm ... Ettercap ... http://linux.die.net/man/8/ettercap Manu Sporny: This is really an issue at the application layer, but we do want to warn people about that possibility. Dave Longley: Yeah, you could solve this by having a challenge-response, or encrypting information in the channel as well as signing. Mark Cavage: Might need another side channel, like an additional key different from HTTPS. Manu Sporny: Could add other headers that are not signed. Applications should only trust signed headers. Dave Longley: Might need to authorize responses too. Dave Longley: We have no security authorization on responses. Not sure if Authorization header is allowed in responses. Manu Sporny: If doing this over HTTP use nonces and do digital signatures on response, good low-cost way to implement something that 'works' Manu Sporny: This devolves into implementing TLS over HTTP. Mark Cavage: You could copy semantics for response and make it optional depending if it's needed. Mark Cavage: Way to look at this is if you're not using TLS then you're off the rails. Dave Longley: Need to spec out something so if you can use HTTP - it needs to work. Brent Shambaugh: Mentioning ettercap when hearing of MITM Manu Sporny: Might be good to use for auding Topic: Active Attacks - Message Deletion / Modification Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.3 Manu Sporny: Message insertion, modification, deletion fall under same category. Usually why sequence numbers are used, to make deletion difficult. Mark Cavage: This heads towards IPSec / TLS over http. Mark Cavage: All related to MITM. Any of these things possible in the case where HTTPS/Certificate Authorities are broken. Mark Cavage: If you are MITM you can completely modify messages, hard to stop deletion in this spec. Manu Sporny: Deletion possible, modifiction difficult. Mark Cavage: If you sign everything you are covered on modification. Dave Longley: attacking identity vs message itself Mark Cavage: As long as you sign everything, you would need to break RSA to break the stream. Dave Longley: This is the same thing as attacking RSA for message inseration, deletion, and modification. Mark Cavage: This spec seems more aimed towards IP instead application level. Dave Longley: Need to mention all these issues in a MITM section. Dave Longley: Modification is going to fall under breaking RSA. Dave Longley: Anything not signed you could change since there's no protection. Manu Sporny: No state tracking. Could attack state of server, harder to attack client state. Manu Sporny: No traditional security handshaking, just a signed message. Manu Sporny: May be attacks at application level but not http signatures level. Dave Longley: Might want to define a message as anything signed according to the spec. Anything that is a message is protected and the security considerations become the same ones for RSA (in that, you have to break RSA). Dave Longley: Anything not considered a message is vulnerable to attack. Topic: Active Attacks - Man-In-The-Middle Manu Sporny: http://tools.ietf.org/html/rfc3552#section-3.3.5 Manu Sporny: HTTP can always have MITM attack, sign the stuff you don't want modified. You can still have deletion issues. Any headers that aren't signed should be assumed to have been modified. Manu Sporny: This is basically a re-cap of what we discussed. HTTP is wide open to MiTM. HTTP Signatures used with HTTP protects the information that is signed from insertion/modification, but not deletion. HTTPS protects against all of these attacks, unless HTTPS is broken. In the event that HTTPS is broken, the security is no better than HTTP with HTTP Signatures (which is better than just plain 'ol HTTP). Topic: On-path / Off-path Attacks / Link-Local Manu Sporny: On-path attacks are basically everything that we've covered to this point. Somebody inbetween has tampered with the message. Off-path is done a bit lower in the networking stack, TCP/IP layer. HTTP Signatures really don't care about the network topology, they just care about sender/receiver and protecting the data that is signed. Dave Longley: Our messages are protected by RSA. To break HTTP Signatures, you have to break RSA. Dave Longley: origins don't matter for our messages Manu Sporny: Anything else for on-path, off-path, link-local? Topic: Next Steps Manu Sporny: What's the next step? Manu Sporny: Can do STRIDE analysis on spec? Is that useful or do we have enough of an audit to put spec up for public review? Mark Cavage: We're going to add more verbage and prose but basic spec hasn't changed. Mark Cavage: Add nonces, trailer support. Is STRIDE going to add anything? Probably thinking along those lines anyway. Manu Sporny: Can only do so much here, good to point people to security review. Manu Sporny: Goal next week for nonces, server signatures, and so on. Then put it up for review to see what other people say. Mark Cavage: Should we split work up? Manu Sporny: I started security consideration section, can work on it today, mcavage can you work on nonces, ... Mark Cavage: Will try to work on it this week. Manu Sporny: We'll have another telecon next week to talk about nonces and server signatures or pick up mozpay navigator api. Manu Sporny: Thanks! -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Mon Jun 17 18:32:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97621F9CDE for ; Mon, 17 Jun 2013 18:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.17 X-Spam-Level: X-Spam-Status: No, score=-0.17 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 zHkinKuByBSB for ; Mon, 17 Jun 2013 18:32:17 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0EC21F9CDC for ; Mon, 17 Jun 2013 18:32:17 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UokmM-00008h-RY; Mon, 17 Jun 2013 21:32:16 -0400 Message-ID: <51BFB899.2030308@digitalbazaar.com> Date: Mon, 17 Jun 2013 21:32:09 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Web Payments CG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Agenda: Web Payments Telecon - Wednesday, June 19th 2013 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 01:32:21 -0000 This weeks telecon will cover details around nonces and HTTP trailers in the HTTP Signatures spec. We'll discuss a bit about the Web Keys spec and how it ties in with HTTP Signatures as well. This will be a 60 minute call. If you would like to add or change anything on the Agenda, please send the request to the mailing list before the telecon or mention the changes at the beginning of the call. The dial-in information as well as minutes and audio logs of previous meetings can be found here: https://payswarm.com/minutes/ ========== Wednesday, June 19th 2013 Time: 1500 UTC / 8am San Francisco / 11am Boston / 4pm London Digital Bazaar Telecon Bridge SIP: payswarm@digitalbazaar.com Phone US: +1.540.961.4469 x6300 irc://freenode.net/#payswarm Duration: 60 minutes Scribes: Longley, Manu, Lehn, others TBD ========== Agenda 1. Update on GSoC Student Progress 2. HTTP Signatures - Nonce Support 3. HTTP Signatures - Trailer Support 4. Web Keys - Next Steps -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Wed Jun 19 09:51:06 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD53221F99E9 for ; Wed, 19 Jun 2013 09:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.235 X-Spam-Level: X-Spam-Status: No, score=-0.235 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 LVyT33ig68c8 for ; Wed, 19 Jun 2013 09:51:03 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 135F621F92F5 for ; Wed, 19 Jun 2013 09:51:02 -0700 (PDT) Received: from zoe.digitalbazaar.com ([192.168.0.99] ident=msporny) by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UpLb3-0007y3-HE; Wed, 19 Jun 2013 12:51:01 -0400 Message-ID: <51C1E175.1010901@digitalbazaar.com> Date: Wed, 19 Jun 2013 12:51:01 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Web Payments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] Web Payments Telecon Minutes for 2013-06-19 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 16:51:06 -0000 cc: IETF HTTP Auth WG (this call dealt with the HTTP Signatures spec) Thanks to Dave Longley for scribing the call today. The minutes for this week's Web Payments telecon are now available here: https://payswarm.com/minutes/2013-06-19/ Full text of the discussion follows for archival purposes at the W3C. Audio of the meeting is available as well (link provided below). -------------- Web Payments Community Group Telecon Minutes for 2013-06-19 Agenda: http://lists.w3.org/Archives/Public/public-webpayments/2013Jun/0025.html Topics: 1. HTTP Signatures - Nonce Support 2. Update on GSoC Student Progress 3. HTTP Signatures - Trailer Support Chair: Manu Sporny Scribe: Dave Longley Present: Dave Longley, Manu Sporny, David I. Lehn, Brent Shambaugh, Andrei Oprea Audio: https://payswarm.com/minutes/2013-06-19/audio.ogg Dave Longley is scribing. Manu Sporny: Mark Cavage is not going to be able to join today, but we need to get through the nonce/trailer stuff since next week will be the Payment API. Any updates or changes to the Agenda? Topic: HTTP Signatures - Nonce Support Manu Sporny: we've been alluding to dealing with nonces in the last few calls and what we've been focusing on is looking at time-based (time-window) nonce Manu Sporny: we're expecting that the nonce will have some kind of client id/some kind of rule for the nonce to be incremented Manu Sporny: nonces could be used for both HTTP and HTTPS (if you want extra protection) Manu Sporny: nonces are specifically designed in this spec to handle replay attacks over HTTP Manu Sporny: the basic parameters are the nonces are generated and must always increment, if a nonce is used the date field must be included in the digital signature, if nonce is there, you must include a nonce parameter and the date field but it's currently unknown where the client ID will be placed Dave Longley: I don't know if we dramatically simplify server implementations by having a client-ID. If it just keeps track of every nonce that comes in over a time window. [scribe assist by Manu Sporny] Dave Longley: Having a client ID doesn't simplify the server, I don't think. [scribe assist by Manu Sporny] Dave Longley: The way the client generates a client ID is not necessary. [scribe assist by Manu Sporny] Dave Longley: it can just be a random value. [scribe assist by Manu Sporny] Manu Sporny: Isn't the random value a client ID. [scribe assist by Manu Sporny] Manu Sporny: i didn't intend for this to mean that it's a session Dave Longley: The nonce is an opaque value to the server. [scribe assist by Manu Sporny] Manu Sporny: what i'm trying to address here is what if you have two pieces of software on your phone from the same IP address, how the server know which incrementing nonce is which Dave Longley: It's true that a session ID + a counting nonce results in a smaller memory usage. [scribe assist by Manu Sporny] Dave Longley: The client generates a random value that is sufficiently long enough that there will be no clashes. The server looks for the next nonce to be higher than the previous nonce. [scribe assist by Manu Sporny] Dave Longley: emphasis is on incrementing, not necessarily by 1, it just needs to be higher than the previous one. [scribe assist by Manu Sporny] Manu Sporny: What exactly does the signature string look like now? [scribe assist by Manu Sporny] Dave Longley: I think we want something like this: clientId=abce7de767eebf, nonce=abac8ec6e7cece Dave Longley: Perhaps this instead, nonce=1 Manu Sporny: we should be very clear and explicit about how to implement nonces in the spec Manu Sporny: instead of just letting it be a grab bag of options Manu Sporny: to make things simpler for implementers Dave Longley: Let's just make the nonce a 32-bit integer, it counts up. Hopefully you won't make 4 billion requests in a 5 minute time window. If you do, generate a new clientId. The ClientID should be sufficiently long over a 5 minute window. [scribe assist by Manu Sporny] Manu Sporny: We could do it by IP address. [scribe assist by Manu Sporny] Dave Longley: I think it starts becoming more complicated in that sense... let's just make it sufficiently long enough - how many bytes, hex-encoded, placed into the signature as a signature parameter. [scribe assist by Manu Sporny] Manu Sporny: So how long is long enough? [scribe assist by Manu Sporny] Dave Longley: 128 bits - 16 bytes. [scribe assist by Manu Sporny] Dave Longley: nonce starts at 1 and counts up [scribe assist by Manu Sporny] Dave Longley: 32-bit number [scribe assist by Manu Sporny] Dave Longley: not hex-encoded [scribe assist by Manu Sporny] David I. Lehn: thinks these rules might be too arbitrary for a spec David I. Lehn: You're picking numbers and those numbers might not work for everyone. [scribe assist by Manu Sporny] Dave Longley: We're picking 128-bit because we want to pick something that will probably not clash. [scribe assist by Manu Sporny] Dave Longley: We could be more specific about talking about this stuff - we have a 5 minute time window, how many clients will connect over that timeframe. [scribe assist by Manu Sporny] Manu Sporny: we could look at the number of requests for google+ and see if you generated a random number if there would be a clash Manu Sporny: if we wanted to support a billion simultaneous clients, etc. we could see what the chance is for two clients picking the same ID Manu Sporny: we think 128 bit would make it very unlikely for a clash even for the next 10 years, etc. Brent Shambaugh: I found this while trying to learn more. Frame of reference? Nonces in Bitcoin: https://en.bitcoin.it/wiki/Nonce (32 bit) Dave Longley: Also, the time window matters - we aren't necessarily setting it. [scribe assist by Manu Sporny] Dave Longley: IPv6 addresses are 128-bit as well - it's not too large to put into an HTTP header... we don't need anything larger than that, really. number of unique addresses. [scribe assist by Manu Sporny] Manu Sporny: if the numbers we picked are wrong, reviewers will complain loudly Manu Sporny: we can also add a note to fix these limits later as needed David I. Lehn: it seems like everyone should just be using HTTPS, i don't understand the use case for HTTP David I. Lehn: are people actually going to use this protocol at all in the non-secure case? Manu Sporny: are you arguing to remove nonces from the spec and HTTP support? David I. Lehn: i just know it's complicated and wonder if we need to put the extra effort in for this Manu Sporny: if we don't put nonces in here it removes a class of applications that just wants to use HTTP David I. Lehn: i just think these issues will double the size of the spec or more, it will be added complexity that people will have to try and understand before using this Manu Sporny: before trying to run it over HTTP David I. Lehn: if half of the spec is optional it seems kind of silly to me David I. Lehn: we'll have to consider that clients will have to be buffering things Manu Sporny: well, it's much easier on the client because the client only needs to store one server session ID Manu Sporny: you generate a random number for the client ID and initialize the nonce to 1 and then count up, that should be it for sending requests Manu Sporny: for the server, you just store client IDs and then make sure the nonce is incrementing David I. Lehn: well, it's just more complicated than not having to do any of that Manu Sporny: well, yeah, but if someone wants to use HTTP this is what has to be done to prevent against replay attacks Manu Sporny: i agree that it's more complicated, but if we do want to support this over HTTP we have to do this Dave Longley: btw, we shouldn't call it client ID because the server might want to use it in responses Dave Longley: I think we include the request line, host and date. [scribe assist by Manu Sporny] Manu Sporny: should we always include the date? David I. Lehn: The implementation in PaySwarm does that by default, but the spec itself just does the date. We're more strict. [scribe assist by Manu Sporny] Dave Longley: What do we do? [scribe assist by Manu Sporny] Dave Longley: We sign the request line, host and date - it's going to be broken if you don't do that. [scribe assist by Manu Sporny] Manu Sporny: When you sign you have to include the sessionId and the nonce value? [scribe assist by Manu Sporny] Dave Longley: We could call it nonce and the other thing be the counter. [scribe assist by Manu Sporny] Dave Longley: We can mess around with the names later. [scribe assist by Manu Sporny] Manu Sporny: Seems strange - nonce stands for "only once" [scribe assist by Manu Sporny] Dave Longley: Let's not re-use that, I haven't looked that closely in Digest Access Auth, we should come up with another name. [scribe assist by Manu Sporny] Manu Sporny: Where does it go? At the front of the signature? [scribe assist by Manu Sporny] Dave Longley: Yeah, at the front, helps with randomness... [scribe assist by Manu Sporny] Manu Sporny: So place the clientID and then the nonce at the beginning as they're encoded in the message. [scribe assist by Manu Sporny] Dave Longley: There is no reason we need to decode them. Consider both a string. [scribe assist by Manu Sporny] Dave Longley: ASCII string since it's over HTTP. [scribe assist by Manu Sporny] Dave Longley: Once it's Base64 encoded, it's ASCII, just use that value. [scribe assist by Manu Sporny] Brent Shambaugh: wasn't really familiar with nonces, started looking at Bitcoin, proof of work. [scribe assist by Manu Sporny] Manu Sporny: I don't know how useful proof of work is - definitely not for the server, maybe for the client? [scribe assist by Manu Sporny] Dave Longley: Don't know how useful it is for what we're trying to do here. [scribe assist by Manu Sporny] Topic: Update on GSoC Student Progress Andrei Oprea: what i've done this week is implement a really basic website Andrei Oprea: i've managed to public/private key pair and register with payswarm using the JS module Manu Sporny: do you have the site running publically some where? Andrei Oprea: not yet, i'll do that Andrei Oprea: https://github.com/piatra/webpayments-marketplace Andrei Oprea: i wanted to get listings working sometime this week Andrei Oprea: i wanted to give a rough idea of what's going on and have some people try it out Manu Sporny: any questions? Andrei Oprea: so far things have gone well, i've been following along with the blog posts manu wrote and no questions so far Manu Sporny: yeah, we're interested in seeing how persona will work out, getting it integrated w/web payments Manu Sporny: ok, great job, andrei Topic: HTTP Signatures - Trailer Support Manu Sporny: so the main question here is what will be in the trailer's authentication header Manu Sporny: We will want to sign the header, and then sign the trailer (including all headers in the header) [scribe assist by Manu Sporny] Dave Longley: I think most servers can store all the headers that came across... trying to simplify processing of trailers authentication header. Could you just process the previous authentication header and then add whatever trailers you wanted? [scribe assist by Manu Sporny] Dave Longley: Would that work? Or would that looks strange? [scribe assist by Manu Sporny] Dave Longley: It would look like it's listing itself... if you authenticated other stuff previously, maybe that would be sufficient. [scribe assist by Manu Sporny] Manu Sporny: Authorization: Signature Manu Sporny: https://payswarm.com/specs/source/http-signatures/ Manu Sporny: Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="request-line host date content-type content-md5 content-length", Dave Longley: That's what it would look like, minus the content-md5 [scribe assist by Manu Sporny] Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="request-line host date content-type" Dave Longley: ^^ that would be in the request header. [scribe assist by Manu Sporny] Authorization: Signature keyId="Test",algorithm="rsa-sha256",headers="authorization content-md5 x-my-trailer" Dave Longley: In the trailer, you would get this ^^ [scribe assist by Manu Sporny] Dave Longley: It may seem circular to people. [scribe assist by Manu Sporny] Dave Longley: it isn't ... you are supposed to use the value from the header Manu Sporny: We might want to be more clear than just using 'authorization' [scribe assist by Manu Sporny] Dave Longley: We could make both suggestions, maybe Mark has an opinion. [scribe assist by Manu Sporny] Dave Longley: Other than that, it doesn't seem like there is a limitation in the trailers for what we could put in there. [scribe assist by Manu Sporny] Dave Longley: You can't have another trailers header in trailers. We could repeat the authorization header, it's just how implementations will deal with that and we still don't know how many implementations deal with it correctly anyway. [scribe assist by Manu Sporny] Dave Longley: We don't know how implementations deal w/ repeated headers... which authorization header? Trailer or Header? [scribe assist by Manu Sporny] Dave Longley: Our decision might depend on what we think other implementations might do - the problem with this idea is that it's not well implemented (trailers) [scribe assist by Manu Sporny] Dave Longley: sort of have a catch-22 here, we want to spec out what to do with trailers just in case anyone implements them, but we need to know how they implement them to get a good idea of how to specify this Manu Sporny: ok, next week we're going to be talking about whitelists Manu Sporny: with respect to payment APIs -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From internet-drafts@ietf.org Sat Jun 22 10:42:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587A021F9007; Sat, 22 Jun 2013 10:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 aoLyLSBxYNA9; Sat, 22 Jun 2013 10:42:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA12421F9D5D; Sat, 22 Jun 2013 10:42:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130622174204.6116.27265.idtracker@ietfa.amsl.com> Date: Sat, 22 Jun 2013 10:42:04 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 17:42:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Update Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-update-01.txt Pages : 9 Date : 2013-06-22 Abstract: This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for new digest algorithms to the HTTP Digest Access Authentication scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-update-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifatyu@avaya.com Sat Jun 22 10:46:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168F211E810B for ; Sat, 22 Jun 2013 10:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 fg4PfKCRrYTY for ; Sat, 22 Jun 2013 10:46:12 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6974311E811B for ; Sat, 22 Jun 2013 10:46:12 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloFAILhxVHGmAcF/2dsb2JhbABbgmghMUm/O3wWbQeCJQEBAxIoUQEVFRRCJgEEGwEZh2wBC5wPhEKbMY1+FIEGgzhhA54HiwCDD4FpPw X-IronPort-AV: E=Sophos;i="4.87,919,1363147200"; d="scan'208";a="14064442" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 22 Jun 2013 13:46:11 -0400 Received: from unknown (HELO AZ-US1EXHC02.global.avaya.com) ([135.11.85.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 22 Jun 2013 13:44:00 -0400 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC02.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Sat, 22 Jun 2013 13:46:09 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "http-auth@ietf.org" Thread-Topic: Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQag== Date: Sat, 22 Jun 2013 17:46:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 17:46:18 -0000 I have just submitted a new version of this draft. http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt With this new version I fixed few nits and removed the i18n section; I have= started working on a new separate draft to address the i18n. Meanwhile, I would like to continue the Algorithm Agility discussion to try= to come to an agreement on this issue. The feedback I got so far seems to indicate that we want to limit the algor= ithm agility to few of the best current algorithms. How about the following: SHA3-256 as the default algorithm. SHA2-256 as a backup algorithm. MD5 for backward compatibility. Any thoughts? Thanks, Rifaat From yaronf.ietf@gmail.com Sat Jun 22 13:04:09 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB1021F9F90 for ; Sat, 22 Jun 2013 13:04:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIcDxQ4cA7WR for ; Sat, 22 Jun 2013 13:04:09 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id D098421F9BF1 for ; Sat, 22 Jun 2013 13:04:08 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t59so7214546wes.20 for ; Sat, 22 Jun 2013 13:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=7xa77MiZvHit9ARrfu5xXt+g/8dyxEjhrqykwcL8K4w=; b=CXP0h2F7qZp/ZAIuEbykOm6aRJHLGHTNFQ+Usyhb+mbNbdf8HZJMnhVJSTnoK0cyma IeDUSR89nzUFYE/JKeXo78NoxAwGL3ysB9hy9gQTDcFU5S2SVvNtSjRD1b29W8xl0Roz U5jDQEIEM/EqIXg8C4u84OBYRqFwtdBqYSpuyWiEkoV45mMrc+O9uDPJ/4t4i48vx1ri oDAXzMH3eWQrbT4VZZfzdKyDvciwCe4C7OhratQLxYXw8ZgGPLL4el8+U+DiFbL+eWO+ uwrIuyLoEj1kTUYXuLi9H6dq3/azGN1dcW6N7eZgaoXZYBU0n3JLVcv4kbnarlDA6abP y1mg== X-Received: by 10.180.105.74 with SMTP id gk10mr2265240wib.3.1371931447999; Sat, 22 Jun 2013 13:04:07 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-148-209.red.bezeqint.net. [79.176.148.209]) by mx.google.com with ESMTPSA id b11sm5972434wiv.10.2013.06.22.13.04.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 13:04:07 -0700 (PDT) Message-ID: <51C60335.6070605@gmail.com> Date: Sat, 22 Jun 2013 23:04:05 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:04:09 -0000 Hi Rifaat, I'm confused by your message. SHA3 is not even mentioned in the draft, and (AFAIK) is not fully standardized yet. So it seems to me the default ought to be SHA2-256, with SHA3-256 coming in as the backup as soon as it is finalized. Thanks, Yaron On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: > I have just submitted a new version of this draft. > http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt > > With this new version I fixed few nits and removed the i18n section; I have started working on a new separate draft to address the i18n. > > Meanwhile, I would like to continue the Algorithm Agility discussion to try to come to an agreement on this issue. > The feedback I got so far seems to indicate that we want to limit the algorithm agility to few of the best current algorithms. > How about the following: > SHA3-256 as the default algorithm. > SHA2-256 as a backup algorithm. > MD5 for backward compatibility. > > Any thoughts? > > Thanks, > Rifaat > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From ynir@checkpoint.com Sat Jun 22 13:53:43 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253C221F9D69 for ; Sat, 22 Jun 2013 13:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.608 X-Spam-Level: X-Spam-Status: No, score=-10.608 tagged_above=-999 required=5 tests=[AWL=-0.009, 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 iPEaN-5EkAAJ for ; Sat, 22 Jun 2013 13:53:38 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 24A0D21F9D57 for ; Sat, 22 Jun 2013 13:53:36 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5MKrVMY014170; Sat, 22 Jun 2013 23:53:31 +0300 X-CheckPoint: {51C60ECB-15-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Sat, 22 Jun 2013 23:53:31 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQav//9D6AgAAN14A= Date: Sat, 22 Jun 2013 20:53:31 +0000 Message-ID: References: <51C60335.6070605@gmail.com> In-Reply-To: <51C60335.6070605@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.20.61] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11d8b8ed79c5f0ac8915ee9a8bf1b53a1828e07911 Content-Type: text/plain; charset="us-ascii" Content-ID: <2FE24807B973414880621B8930C196AA@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 20:53:43 -0000 Hi Yaron Agree about SHA-2 being the default. At SAAG last meeting there was a speak= er from NIST ( http://www.ietf.org/proceedings/86/slides/slides-86-saag-3.p= df ). The presentation doesn't say so, but he did say that the parameters f= or SHA-3 will be decided in the next few months. So SHA-3 may be finalized = before this draft goes out. Yoav On Jun 22, 2013, at 11:04 PM, Yaron Sheffer wrote: > Hi Rifaat, >=20 > I'm confused by your message. SHA3 is not even mentioned in the draft, an= d (AFAIK) is not fully standardized yet. >=20 > So it seems to me the default ought to be SHA2-256, with SHA3-256 coming = in as the backup as soon as it is finalized. >=20 > Thanks, > Yaron >=20 > On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: >> I have just submitted a new version of this draft. >> http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt >>=20 >> With this new version I fixed few nits and removed the i18n section; I h= ave started working on a new separate draft to address the i18n. >>=20 >> Meanwhile, I would like to continue the Algorithm Agility discussion to = try to come to an agreement on this issue. >> The feedback I got so far seems to indicate that we want to limit the al= gorithm agility to few of the best current algorithms. >> How about the following: >> SHA3-256 as the default algorithm. >> SHA2-256 as a backup algorithm. >> MD5 for backward compatibility. >>=20 >> Any thoughts? >>=20 >> Thanks, >> Rifaat >>=20 >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >>=20 > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth >=20 > Email secured by Check Point From yaronf.ietf@gmail.com Sat Jun 22 22:40:14 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E878311E80DF for ; Sat, 22 Jun 2013 22:40:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cW7Y7T1+t2Ec for ; Sat, 22 Jun 2013 22:40:14 -0700 (PDT) Received: from mail-ee0-x234.google.com (mail-ee0-x234.google.com [IPv6:2a00:1450:4013:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1FFEA11E80DC for ; Sat, 22 Jun 2013 22:40:13 -0700 (PDT) Received: by mail-ee0-f52.google.com with SMTP id c50so5319228eek.39 for ; Sat, 22 Jun 2013 22:40:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0VtoN/mKJYmb5vwLA7qKIaS+sAONR4/EVJkm5/BJxHA=; b=tb5w4pvpK7U5CfweNwFz5alS3a49qKCpr7CJHqDmZ+zR/Sfaap3sb6oauHXEKDVqFi OvSMhEOuXkZ9fJ1Rga2ZZzPa9ZJkZAW5Er+dt2YrSQT98egr6ZkbPfXCwV009r5DDtJm HkBpCIj/5pGzRax5DlKwnRMr/arOy+eA48ur6DiDofIMUXeWlGYVUZsFXYFIfAihYNr1 LzItpA5E6pJZWh9mIuTPRdSE0NVrvBv9N3d19qy8ZquGHj9pnWe1vaVXuGfhBwfUqhX9 /P1V+gaR5Jg5A3L2UY5TrzBGWRhcZcyFpI7PDg1ODknezjuWngE2LZMt2U8ViBpvhd1K JLxQ== X-Received: by 10.15.98.203 with SMTP id bj51mr19385811eeb.22.1371966011986; Sat, 22 Jun 2013 22:40:11 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-176-148-209.red.bezeqint.net. [79.176.148.209]) by mx.google.com with ESMTPSA id bj46sm18862446eeb.13.2013.06.22.22.40.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 22:40:11 -0700 (PDT) Message-ID: <51C68A38.8020005@gmail.com> Date: Sun, 23 Jun 2013 08:40:08 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 05:40:15 -0000 In addition to the algorithm question, there's the bigger question of the actual security (rather than "regulatory compliance") benefit that this buys us. If HTTP-Digest is used with short passwords over an unencrypted medium (or an encrypted one, where there may be a MITM attacker), then using SHA256 instead of MD5 has zero benefit. Dictionary attacks are much more effective than breaking MD5, and will remain so for the foreseeable future. So the whole exercise only seems worthwhile when used with non-memorable "passwords", i.e. with actual crypto keys. Which really only makes sense within web services, rather than regular browsing. I suggest adding the following section to the draft: --- start text --- Applicability HTTP Digest authentication, when used with human-memorable passwords, is vulnerable to dictionary attacks. Such attacks are much easier than cryptographic attacks on any widely used algorithm, including those that are no longer considered secure. In other words, algorithm agility does not make this usage any more secure. As a result, Digest authentication SHOULD be used only with passwords that have a reasonable amount of entropy, e.g. 128-bit or more. Such passwords typically cannot be memorized by humans but can be used for automated web services. --- end text --- Yes, the text refers to RFC 2617 in the security considerations. But 14 years later I believe we can do better than that. Thanks, Yaron On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: > I have just submitted a new version of this draft. > http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt > > With this new version I fixed few nits and removed the i18n section; I have started working on a new separate draft to address the i18n. > > Meanwhile, I would like to continue the Algorithm Agility discussion to try to come to an agreement on this issue. > The feedback I got so far seems to indicate that we want to limit the algorithm agility to few of the best current algorithms. > How about the following: > SHA3-256 as the default algorithm. > SHA2-256 as a backup algorithm. > MD5 for backward compatibility. > > Any thoughts? > > Thanks, > Rifaat > > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From rifatyu@avaya.com Sun Jun 23 03:03:02 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 800D721F9A65 for ; Sun, 23 Jun 2013 03:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.432 X-Spam-Level: X-Spam-Status: No, score=-3.432 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 yIqUGx4m-SZD for ; Sun, 23 Jun 2013 03:02:57 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id CA74021F8842 for ; Sun, 23 Jun 2013 03:02:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFDHxlGHCzI1/2dsb2JhbABagmghMUm/NnsWdIIjAQEBAQMBAQEPKDQLDAQCAQgNAQMEAQEBChQJByEGCxQJCAEBBAENBQgBGYdaAw8BC51UkiQNiDsXjGiBHAkLgQYxBwaCfGEDlVsBiCuFXIUkgxCBaQgXIA X-IronPort-AV: E=Sophos;i="4.87,922,1363147200"; d="scan'208";a="14104564" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 23 Jun 2013 06:02:55 -0400 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Jun 2013 05:57:42 -0400 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 06:02:53 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Yoav Nir , Yaron Sheffer Thread-Topic: [http-auth] Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQagANMu2AAAG5+IAAEusYsA== Date: Sun, 23 Jun 2013 10:02:52 +0000 Message-ID: References: <51C60335.6070605@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:03:02 -0000 Hi Yaron, You are right; I should have added SHA3 to the document before taken it int= o considerations. Will do that in the next version. I am ok with changing the default to SHA2-256, as follows: SHA2-256 as the default algorithm. SHA3-256 as a backup algorithm. MD5 for backward compatibility. We could revisit this decision if, as Yoav mentioned, SHA3 is finalized bef= ore this document is done. Regards, Rifaat > -----Original Message----- > From: Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Saturday, June 22, 2013 4:54 PM > To: Yaron Sheffer > Cc: Shekh-Yusef, Rifaat (Rifaat); http-auth@ietf.org > Subject: Re: [http-auth] Digest Update - Algorithm Agility >=20 > Hi Yaron >=20 > Agree about SHA-2 being the default. At SAAG last meeting there was a > speaker from NIST ( http://www.ietf.org/proceedings/86/slides/slides-86- > saag-3.pdf ). The presentation doesn't say so, but he did say that the > parameters for SHA-3 will be decided in the next few months. So SHA-3 > may be finalized before this draft goes out. >=20 > Yoav >=20 >=20 > On Jun 22, 2013, at 11:04 PM, Yaron Sheffer > wrote: >=20 > > Hi Rifaat, > > > > I'm confused by your message. SHA3 is not even mentioned in the draft, > and (AFAIK) is not fully standardized yet. > > > > So it seems to me the default ought to be SHA2-256, with SHA3-256 > coming in as the backup as soon as it is finalized. > > > > Thanks, > > Yaron > > > > On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: > >> I have just submitted a new version of this draft. > >> http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt > >> > >> With this new version I fixed few nits and removed the i18n section; > I have started working on a new separate draft to address the i18n. > >> > >> Meanwhile, I would like to continue the Algorithm Agility discussion > to try to come to an agreement on this issue. > >> The feedback I got so far seems to indicate that we want to limit the > algorithm agility to few of the best current algorithms. > >> How about the following: > >> SHA3-256 as the default algorithm. > >> SHA2-256 as a backup algorithm. > >> MD5 for backward compatibility. > >> > >> Any thoughts? > >> > >> Thanks, > >> Rifaat > >> > >> _______________________________________________ > >> http-auth mailing list > >> http-auth@ietf.org > >> https://www.ietf.org/mailman/listinfo/http-auth > >> > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > Email secured by Check Point From rifatyu@avaya.com Sun Jun 23 03:05:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D151321F9C5F for ; Sun, 23 Jun 2013 03:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.350, 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 ZiWhJ0gffDJM for ; Sun, 23 Jun 2013 03:05:13 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 525E521F9BFB for ; Sun, 23 Jun 2013 03:05:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAFDHxlHGmAcF/2dsb2JhbABagmghMUmDBbwxDW4WdIIjAQEBAQMBAQEPERE6AgkMBAIBCA0EBAEBAQICBh0DAgICHwYLFAEICAEBBA4FCAEZh1oDDwELnVSKOodqDYg7F4Emi0KBHBSBBhYbBwaCSTNhA5VbAYgrhVyFJIMQgWk/ X-IronPort-AV: E=Sophos;i="4.87,922,1363147200"; d="scan'208";a="17340859" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 23 Jun 2013 06:05:12 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2013 06:03:00 -0400 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 06:05:11 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Yaron Sheffer Thread-Topic: [http-auth] Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQagAhUTcAAADO6JA= Date: Sun, 23 Jun 2013 10:05:11 +0000 Message-ID: References: <51C68A38.8020005@gmail.com> In-Reply-To: <51C68A38.8020005@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:05:18 -0000 VGhhbmtzIFlhcm9uLA0KDQpJIGxpa2UgdGhlIHRleHQgeW91IHByb3Bvc2VkIGJlbG93OyBJIHdp bGwgYWRkIGl0IHRvIHRoZSBsaW1pdGF0aW9ucyBzZWN0aW9uLg0KDQpSZWdhcmRzLA0KIFJpZmFh dA0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWWFyb24gU2hlZmZl ciBbbWFpbHRvOnlhcm9uZi5pZXRmQGdtYWlsLmNvbV0NCj4gU2VudDogU3VuZGF5LCBKdW5lIDIz LCAyMDEzIDE6NDAgQU0NCj4gVG86IFNoZWtoLVl1c2VmLCBSaWZhYXQgKFJpZmFhdCkNCj4gQ2M6 IGh0dHAtYXV0aEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2h0dHAtYXV0aF0gRGlnZXN0IFVw ZGF0ZSAtIEFsZ29yaXRobSBBZ2lsaXR5DQo+IA0KPiBJbiBhZGRpdGlvbiB0byB0aGUgYWxnb3Jp dGhtIHF1ZXN0aW9uLCB0aGVyZSdzIHRoZSBiaWdnZXIgcXVlc3Rpb24gb2YNCj4gdGhlIGFjdHVh bCBzZWN1cml0eSAocmF0aGVyIHRoYW4gInJlZ3VsYXRvcnkgY29tcGxpYW5jZSIpIGJlbmVmaXQg dGhhdA0KPiB0aGlzIGJ1eXMgdXMuIElmIEhUVFAtRGlnZXN0IGlzIHVzZWQgd2l0aCBzaG9ydCBw YXNzd29yZHMgb3ZlciBhbg0KPiB1bmVuY3J5cHRlZCBtZWRpdW0gKG9yIGFuIGVuY3J5cHRlZCBv bmUsIHdoZXJlIHRoZXJlIG1heSBiZSBhIE1JVE0NCj4gYXR0YWNrZXIpLCB0aGVuIHVzaW5nIFNI QTI1NiBpbnN0ZWFkIG9mIE1ENSBoYXMgemVybyBiZW5lZml0LiBEaWN0aW9uYXJ5DQo+IGF0dGFj a3MgYXJlIG11Y2ggbW9yZSBlZmZlY3RpdmUgdGhhbiBicmVha2luZyBNRDUsIGFuZCB3aWxsIHJl bWFpbiBzbw0KPiBmb3IgdGhlIGZvcmVzZWVhYmxlIGZ1dHVyZS4NCj4gDQo+IFNvIHRoZSB3aG9s ZSBleGVyY2lzZSBvbmx5IHNlZW1zIHdvcnRod2hpbGUgd2hlbiB1c2VkIHdpdGggbm9uLW1lbW9y YWJsZQ0KPiAicGFzc3dvcmRzIiwgaS5lLiB3aXRoIGFjdHVhbCBjcnlwdG8ga2V5cy4gV2hpY2gg cmVhbGx5IG9ubHkgbWFrZXMgc2Vuc2UNCj4gd2l0aGluIHdlYiBzZXJ2aWNlcywgcmF0aGVyIHRo YW4gcmVndWxhciBicm93c2luZy4gSSBzdWdnZXN0IGFkZGluZyB0aGUNCj4gZm9sbG93aW5nIHNl Y3Rpb24gdG8gdGhlIGRyYWZ0Og0KPiANCj4gLS0tIHN0YXJ0IHRleHQgLS0tDQo+IA0KPiBBcHBs aWNhYmlsaXR5DQo+IA0KPiBIVFRQIERpZ2VzdCBhdXRoZW50aWNhdGlvbiwgd2hlbiB1c2VkIHdp dGggaHVtYW4tbWVtb3JhYmxlIHBhc3N3b3JkcywgaXMNCj4gdnVsbmVyYWJsZSB0byBkaWN0aW9u YXJ5IGF0dGFja3MuIFN1Y2ggYXR0YWNrcyBhcmUgbXVjaCBlYXNpZXIgdGhhbg0KPiBjcnlwdG9n cmFwaGljIGF0dGFja3Mgb24gYW55IHdpZGVseSB1c2VkIGFsZ29yaXRobSwgaW5jbHVkaW5nIHRo b3NlIHRoYXQNCj4gYXJlIG5vIGxvbmdlciBjb25zaWRlcmVkIHNlY3VyZS4gSW4gb3RoZXIgd29y ZHMsIGFsZ29yaXRobSBhZ2lsaXR5IGRvZXMNCj4gbm90IG1ha2UgdGhpcyB1c2FnZSBhbnkgbW9y ZSBzZWN1cmUuDQo+IA0KPiBBcyBhIHJlc3VsdCwgRGlnZXN0IGF1dGhlbnRpY2F0aW9uIFNIT1VM RCBiZSB1c2VkIG9ubHkgd2l0aCBwYXNzd29yZHMNCj4gdGhhdCBoYXZlIGEgcmVhc29uYWJsZSBh bW91bnQgb2YgZW50cm9weSwgZS5nLiAxMjgtYml0IG9yIG1vcmUuIFN1Y2gNCj4gcGFzc3dvcmRz IHR5cGljYWxseSBjYW5ub3QgYmUgbWVtb3JpemVkIGJ5IGh1bWFucyBidXQgY2FuIGJlIHVzZWQg Zm9yDQo+IGF1dG9tYXRlZCB3ZWIgc2VydmljZXMuDQo+IA0KPiAtLS0gZW5kIHRleHQgLS0tDQo+ IA0KPiBZZXMsIHRoZSB0ZXh0IHJlZmVycyB0byBSRkMgMjYxNyBpbiB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMuIEJ1dCAxNA0KPiB5ZWFycyBsYXRlciBJIGJlbGlldmUgd2UgY2FuIGRvIGJl dHRlciB0aGFuIHRoYXQuDQo+IA0KPiBUaGFua3MsDQo+IAlZYXJvbg0KPiANCj4gT24gMjAxMy0w Ni0yMiAyMDo0NiwgU2hla2gtWXVzZWYsIFJpZmFhdCAoUmlmYWF0KSB3cm90ZToNCj4gPiBJIGhh dmUganVzdCBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiBvZiB0aGlzIGRyYWZ0Lg0KPiA+IGh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1odHRwYXV0aC1kaWdlc3QtdXBkYXRlLTAxLnR4 dA0KPiA+DQo+ID4gV2l0aCB0aGlzIG5ldyB2ZXJzaW9uIEkgZml4ZWQgZmV3IG5pdHMgYW5kIHJl bW92ZWQgdGhlIGkxOG4gc2VjdGlvbjsgSQ0KPiBoYXZlIHN0YXJ0ZWQgd29ya2luZyBvbiBhIG5l dyBzZXBhcmF0ZSBkcmFmdCB0byBhZGRyZXNzIHRoZSBpMThuLg0KPiA+DQo+ID4gTWVhbndoaWxl LCBJIHdvdWxkIGxpa2UgdG8gY29udGludWUgdGhlIEFsZ29yaXRobSBBZ2lsaXR5IGRpc2N1c3Np b24NCj4gdG8gdHJ5IHRvIGNvbWUgdG8gYW4gYWdyZWVtZW50IG9uIHRoaXMgaXNzdWUuDQo+ID4g VGhlIGZlZWRiYWNrIEkgZ290IHNvIGZhciBzZWVtcyB0byBpbmRpY2F0ZSB0aGF0IHdlIHdhbnQg dG8gbGltaXQgdGhlDQo+IGFsZ29yaXRobSBhZ2lsaXR5IHRvIGZldyBvZiB0aGUgYmVzdCBjdXJy ZW50IGFsZ29yaXRobXMuDQo+ID4gSG93IGFib3V0IHRoZSBmb2xsb3dpbmc6DQo+ID4gICAgIFNI QTMtMjU2IGFzIHRoZSBkZWZhdWx0IGFsZ29yaXRobS4NCj4gPiAgICAgU0hBMi0yNTYgYXMgYSBi YWNrdXAgYWxnb3JpdGhtLg0KPiA+ICAgICBNRDUgZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxpdHku DQo+ID4NCj4gPiBBbnkgdGhvdWdodHM/DQo+ID4NCj4gPiBUaGFua3MsDQo+ID4gICBSaWZhYXQN Cj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gaHR0cC1hdXRoIG1haWxpbmcgbGlzdA0KPiA+IGh0dHAtYXV0aEBpZXRmLm9yZw0KPiA+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHR0cC1hdXRoDQo+ID4NCg== From stephen.farrell@cs.tcd.ie Sun Jun 23 03:16:26 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CA821F8E2A for ; Sun, 23 Jun 2013 03:16:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1RjZOpcnzdAX for ; Sun, 23 Jun 2013 03:16:22 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id DC94921F8D73 for ; Sun, 23 Jun 2013 03:16:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 275ADBE7D; Sun, 23 Jun 2013 11:15:58 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM5tteiY70Ap; Sun, 23 Jun 2013 11:15:54 +0100 (IST) Received: from [10.87.48.12] (unknown [86.42.28.228]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CC611BE73; Sun, 23 Jun 2013 11:15:54 +0100 (IST) Message-ID: <51C6CADA.70203@cs.tcd.ie> Date: Sun, 23 Jun 2013 11:15:54 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Shekh-Yusef, Rifaat (Rifaat)" References: <51C68A38.8020005@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 10:16:27 -0000 Seems like a fine direction. SHA3 defo ought not be the default but is probably ok as a backup. I'd add something along the lines that you really ought only send these headers over HTTPS, properly validated. And that since that's quite practical these days clients SHOULD require that (or stated another way clients SHOULD NOT send these headers in clear) and servers SHOULD log if they receive such headers in clear (but they MUST NOT log the header values!!) and try to something about that (go fix your own site's use of TLS). It might also be worth putting the same piece of text into all the drafts this wg produces where dictionary attacks are possible based on the headers emitted. That'd maybe also mean a few editorial changes. (No rush on that, probably better finalised when more than one doc is ready for WGLC.) As another point, it might also be worthwhile having a bit of text for all drafts that are vulnerable to password verifier database theft. IMO that really is the most important security consideration for all these mechanisms (today at least). I don't have time right now to draft that but will happily try later if someone reminds me. (maybe plonk an issue in the tracker?) Cheers, S On 06/23/2013 11:05 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > Thanks Yaron, > > I like the text you proposed below; I will add it to the limitations section. > > Regards, > Rifaat > > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Sunday, June 23, 2013 1:40 AM >> To: Shekh-Yusef, Rifaat (Rifaat) >> Cc: http-auth@ietf.org >> Subject: Re: [http-auth] Digest Update - Algorithm Agility >> >> In addition to the algorithm question, there's the bigger question of >> the actual security (rather than "regulatory compliance") benefit that >> this buys us. If HTTP-Digest is used with short passwords over an >> unencrypted medium (or an encrypted one, where there may be a MITM >> attacker), then using SHA256 instead of MD5 has zero benefit. Dictionary >> attacks are much more effective than breaking MD5, and will remain so >> for the foreseeable future. >> >> So the whole exercise only seems worthwhile when used with non-memorable >> "passwords", i.e. with actual crypto keys. Which really only makes sense >> within web services, rather than regular browsing. I suggest adding the >> following section to the draft: >> >> --- start text --- >> >> Applicability >> >> HTTP Digest authentication, when used with human-memorable passwords, is >> vulnerable to dictionary attacks. Such attacks are much easier than >> cryptographic attacks on any widely used algorithm, including those that >> are no longer considered secure. In other words, algorithm agility does >> not make this usage any more secure. >> >> As a result, Digest authentication SHOULD be used only with passwords >> that have a reasonable amount of entropy, e.g. 128-bit or more. Such >> passwords typically cannot be memorized by humans but can be used for >> automated web services. >> >> --- end text --- >> >> Yes, the text refers to RFC 2617 in the security considerations. But 14 >> years later I believe we can do better than that. >> >> Thanks, >> Yaron >> >> On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: >>> I have just submitted a new version of this draft. >>> http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt >>> >>> With this new version I fixed few nits and removed the i18n section; I >> have started working on a new separate draft to address the i18n. >>> >>> Meanwhile, I would like to continue the Algorithm Agility discussion >> to try to come to an agreement on this issue. >>> The feedback I got so far seems to indicate that we want to limit the >> algorithm agility to few of the best current algorithms. >>> How about the following: >>> SHA3-256 as the default algorithm. >>> SHA2-256 as a backup algorithm. >>> MD5 for backward compatibility. >>> >>> Any thoughts? >>> >>> Thanks, >>> Rifaat >>> >>> _______________________________________________ >>> http-auth mailing list >>> http-auth@ietf.org >>> https://www.ietf.org/mailman/listinfo/http-auth >>> > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > > From rifatyu@avaya.com Sun Jun 23 04:20:51 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D311A21F9C7E for ; Sun, 23 Jun 2013 04:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.417 X-Spam-Level: X-Spam-Status: No, score=-3.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 J9zjSQtxIRTL for ; Sun, 23 Jun 2013 04:20:40 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1321F9C7C for ; Sun, 23 Jun 2013 04:20:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAH/ZlHGmAcF/2dsb2JhbABQgmUhNsFIgQcWdIIfAQEBAQIBAQEBDyg0AgkFBwQCAQgNBAQBAQEKDgYJByEGCxQJCAEBBA4FCAEZh2ADCQYBC6A8kzkNiUYXjEOBCBSBBiYLBwYSgkhhA5UeAYgKhUyFHIMLgWsBHgYY X-IronPort-AV: E=Sophos;i="4.87,456,1363147200"; d="scan'208";a="16754903" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jun 2013 07:20:38 -0400 Received: from unknown (HELO AZ-US1EXHC03.global.avaya.com) ([135.11.85.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jun 2013 07:18:25 -0400 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC03.global.avaya.com ([::1]) with mapi id 14.02.0328.009; Sun, 23 Jun 2013 07:20:37 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Stephen Farrell Thread-Topic: [http-auth] Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQagAhUTcAAADO6JAACNKkAAAGVPWw Date: Sun, 23 Jun 2013 11:20:36 +0000 Message-ID: References: <51C68A38.8020005@gmail.com> <51C6CADA.70203@cs.tcd.ie> In-Reply-To: <51C6CADA.70203@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:20:52 -0000 Thanks Stephen, > I'd add something along the lines that you really ought only send > these headers over HTTPS, properly validated. And that since that's > quite practical these days clients SHOULD require that (or stated > another way clients SHOULD NOT send these headers in clear) and > servers SHOULD log if they receive such headers in clear (but they > MUST NOT log the header values!!) and try to something about that > (go fix your own site's use of TLS). I will add some text along these line to the next version of the draft. Regards, Rifaat > -----Original Message----- > From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie] > Sent: Sunday, June 23, 2013 6:16 AM > To: Shekh-Yusef, Rifaat (Rifaat) > Cc: Yaron Sheffer; http-auth@ietf.org > Subject: Re: [http-auth] Digest Update - Algorithm Agility >=20 >=20 > Seems like a fine direction. SHA3 defo ought not be the default > but is probably ok as a backup. >=20 > I'd add something along the lines that you really ought only send > these headers over HTTPS, properly validated. And that since that's > quite practical these days clients SHOULD require that (or stated > another way clients SHOULD NOT send these headers in clear) and > servers SHOULD log if they receive such headers in clear (but they > MUST NOT log the header values!!) and try to something about that > (go fix your own site's use of TLS). >=20 > It might also be worth putting the same piece of text into all the > drafts this wg produces where dictionary attacks are possible based > on the headers emitted. That'd maybe also mean a few editorial > changes. (No rush on that, probably better finalised when more than > one doc is ready for WGLC.) >=20 > As another point, it might also be worthwhile having a bit of > text for all drafts that are vulnerable to password verifier > database theft. IMO that really is the most important security > consideration for all these mechanisms (today at least). I don't > have time right now to draft that but will happily try later if > someone reminds me. (maybe plonk an issue in the tracker?) >=20 > Cheers, > S >=20 > On 06/23/2013 11:05 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: > > Thanks Yaron, > > > > I like the text you proposed below; I will add it to the limitations > section. > > > > Regards, > > Rifaat > > > > > >> -----Original Message----- > >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > >> Sent: Sunday, June 23, 2013 1:40 AM > >> To: Shekh-Yusef, Rifaat (Rifaat) > >> Cc: http-auth@ietf.org > >> Subject: Re: [http-auth] Digest Update - Algorithm Agility > >> > >> In addition to the algorithm question, there's the bigger question of > >> the actual security (rather than "regulatory compliance") benefit > that > >> this buys us. If HTTP-Digest is used with short passwords over an > >> unencrypted medium (or an encrypted one, where there may be a MITM > >> attacker), then using SHA256 instead of MD5 has zero benefit. > Dictionary > >> attacks are much more effective than breaking MD5, and will remain so > >> for the foreseeable future. > >> > >> So the whole exercise only seems worthwhile when used with non- > memorable > >> "passwords", i.e. with actual crypto keys. Which really only makes > sense > >> within web services, rather than regular browsing. I suggest adding > the > >> following section to the draft: > >> > >> --- start text --- > >> > >> Applicability > >> > >> HTTP Digest authentication, when used with human-memorable passwords, > is > >> vulnerable to dictionary attacks. Such attacks are much easier than > >> cryptographic attacks on any widely used algorithm, including those > that > >> are no longer considered secure. In other words, algorithm agility > does > >> not make this usage any more secure. > >> > >> As a result, Digest authentication SHOULD be used only with passwords > >> that have a reasonable amount of entropy, e.g. 128-bit or more. Such > >> passwords typically cannot be memorized by humans but can be used for > >> automated web services. > >> > >> --- end text --- > >> > >> Yes, the text refers to RFC 2617 in the security considerations. But > 14 > >> years later I believe we can do better than that. > >> > >> Thanks, > >> Yaron > >> > >> On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: > >>> I have just submitted a new version of this draft. > >>> http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt > >>> > >>> With this new version I fixed few nits and removed the i18n section; > I > >> have started working on a new separate draft to address the i18n. > >>> > >>> Meanwhile, I would like to continue the Algorithm Agility discussion > >> to try to come to an agreement on this issue. > >>> The feedback I got so far seems to indicate that we want to limit > the > >> algorithm agility to few of the best current algorithms. > >>> How about the following: > >>> SHA3-256 as the default algorithm. > >>> SHA2-256 as a backup algorithm. > >>> MD5 for backward compatibility. > >>> > >>> Any thoughts? > >>> > >>> Thanks, > >>> Rifaat > >>> > >>> _______________________________________________ > >>> http-auth mailing list > >>> http-auth@ietf.org > >>> https://www.ietf.org/mailman/listinfo/http-auth > >>> > > _______________________________________________ > > http-auth mailing list > > http-auth@ietf.org > > https://www.ietf.org/mailman/listinfo/http-auth > > > > From msporny@digitalbazaar.com Sun Jun 23 19:24:17 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2339911E8102 for ; Sun, 23 Jun 2013 19:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.022 X-Spam-Level: * X-Spam-Status: No, score=1.022 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 39DRsP9+N6rY for ; Sun, 23 Jun 2013 19:24:13 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 67A9811E8101 for ; Sun, 23 Jun 2013 19:24:13 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UqwRs-0007me-Jg; Sun, 23 Jun 2013 22:24:09 -0400 Message-ID: <51C7ADC2.7010008@digitalbazaar.com> Date: Sun, 23 Jun 2013 22:24:02 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Web Payments Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth Subject: [http-auth] New Security Considerations for HTTP Signatures draft X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 02:24:17 -0000 The first cut (static version) of the Security Considerations for HTTP Signatures draft is up: https://payswarm.com/specs/ED/http-signatures-audit/2013-06-23/ There are a number of other attacks that need to be detailed in this draft, many of the the ones from Hawk apply here as well: https://github.com/hueniverse/hawk#security-considerations -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From msporny@digitalbazaar.com Sun Jun 23 21:38:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5C121F9A77 for ; Sun, 23 Jun 2013 21:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=-0.558, BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] 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 dWxo9rMYd4bx for ; Sun, 23 Jun 2013 21:37:56 -0700 (PDT) Received: from mail.digitalbazaar.com (unknown [216.252.204.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6864D21F9A40 for ; Sun, 23 Jun 2013 21:37:56 -0700 (PDT) Received: from [192.168.100.5] by mail.digitalbazaar.com with esmtp (Exim 4.72) (envelope-from ) id 1UqyXG-0002AV-L0; Mon, 24 Jun 2013 00:37:51 -0400 Message-ID: <51C7CD18.5060801@digitalbazaar.com> Date: Mon, 24 Jun 2013 00:37:44 -0400 From: Manu Sporny User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.4) Gecko/20120510 Icedove/10.0.4 MIME-Version: 1.0 To: Mark Cavage Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: IETF HTTP Auth , Web Payments Subject: [http-auth] Lift nonces / trailers into separate spec X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 04:38:00 -0000 This is mostly directed at Mark Cavage, but thought it would be good to keep the Web Payments and HTTP Auth groups apprised of the situation. We had a quick 5 minute discussion on the #payswarm IRC channel about the optional features of HTTP signatures last week. Dave Lehn really didn't like that we were complicating the HTTP Signatures spec by talking about nonces (for HTTP) and HTTP trailer signatures. Dave Longley suggested that we move all optional features of HTTP Signatures spec into a separate spec. This would have two positive outcomes: 1. It would make it so that we can focus on the core spec and push that forward at IETF. 2. It would reduce the "aww, man - not nonces again!" complaints. While we do have a pretty solid plan for nonces and trailers[1], we may not want to burn the time on ironing out all of the gory details right now since we don't have anyone demanding that HTTP Signatures work over an unencrypted connection. Ben Adida pointed me at this spec when I mentioned that we were working on HTTP Signatures (he's a co-author of the Hawk protocol): https://github.com/hueniverse/hawk A couple of takeaways from that implementation: * The way they do time synchronization is interesting. * The way they do nonces is basically the same approach we take. * Theirs is an HMAC solution, which we really, really, don't want to support. * Bewit is interesting, but I don't think it has a place in HTTP Signatures. * We want to integrate most of their security considerations section into the HTTP Signatures Security Considerations document. -- manu [1] https://payswarm.com/minutes/2013-06-19/ -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: Meritora - Web payments commercial launch http://blog.meritora.com/launch/ From yaronf.ietf@gmail.com Mon Jun 24 00:56:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54BA21F9A8C for ; Mon, 24 Jun 2013 00:56:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76XJLA4RoZmy for ; Mon, 24 Jun 2013 00:56:14 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 7875C11E80E8 for ; Mon, 24 Jun 2013 00:55:39 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so8054714wev.14 for ; Mon, 24 Jun 2013 00:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3qGA6DTKEf2PFLaU5GMgxKSc+4rdWC58J6syOajVIu4=; b=P/UouhcZuyoUCoc5Ypw+XDhz+RooK/UacUsTEeqGUkrmWEl9e3RPMFGshE3GzATUDm o+Q2RC8naC12pRR86qFg9ofHShR204VOiCUPm2AmSHoZ+yHfs1epflSwPWUPu/KescYi gvbK5bcfW5bAyU8V/P1YUwgL6lI03w7RLfx6+zbAPLIFjBuprOclsje/5OfireJHlcBU 19ezZCweRYMNL3s194VAf/gZnqDM0DaOWWyiNPmLlRzAc3sqPjHBqeVCu53JYu6ZTX64 MiWKKKYw8GzmjHtePGDwNvieDZ3eDtnc1h+qz4KaPAJKmjDTUCJ/jKrEx9A0pOrRiNc0 ATFA== X-Received: by 10.180.36.36 with SMTP id n4mr5260709wij.0.1372060531966; Mon, 24 Jun 2013 00:55:31 -0700 (PDT) Received: from [10.0.0.14] (109-186-101-35.bb.netvision.net.il. [109.186.101.35]) by mx.google.com with ESMTPSA id ft10sm14598645wib.7.2013.06.24.00.55.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 00:55:30 -0700 (PDT) Message-ID: <51C7FB70.1060105@gmail.com> Date: Mon, 24 Jun 2013 10:55:28 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Stephen Farrell References: <51C68A38.8020005@gmail.com> <51C6CADA.70203@cs.tcd.ie> In-Reply-To: <51C6CADA.70203@cs.tcd.ie> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 07:56:18 -0000 Hi Stephen, please see some comments below. Thanks, Yaron On 2013-06-23 13:15, Stephen Farrell wrote: > > Seems like a fine direction. SHA3 defo ought not be the default > but is probably ok as a backup. > +1, even after SHA3 is finally standardized. Because it'll be quite a few years before it is widely implemented. > I'd add something along the lines that you really ought only send > these headers over HTTPS, properly validated. And that since that's > quite practical these days clients SHOULD require that (or stated > another way clients SHOULD NOT send these headers in clear) and > servers SHOULD log if they receive such headers in clear (but they > MUST NOT log the header values!!) and try to something about that > (go fix your own site's use of TLS). I think you're going too far here. There's value in authenticating HTTP, even when traffic is unencrypted, and especially if Session Continuation happens. OTOH I don't think the industry is ready to mandate encryption at the SHOULD level. > > It might also be worth putting the same piece of text into all the > drafts this wg produces where dictionary attacks are possible based > on the headers emitted. That'd maybe also mean a few editorial > changes. (No rush on that, probably better finalised when more than > one doc is ready for WGLC.) > > As another point, it might also be worthwhile having a bit of > text for all drafts that are vulnerable to password verifier > database theft. IMO that really is the most important security > consideration for all these mechanisms (today at least). I don't > have time right now to draft that but will happily try later if > someone reminds me. (maybe plonk an issue in the tracker?) I disagree about the relative important of these threats (passive/active attacks on traffic vs. off-line analysis of captured password databases), because we've seen to what lengths governments, enterprises and service providers are willing to go to MITM people's traffic. But I guess it's a pointless argument. > > Cheers, > S > > On 06/23/2013 11:05 AM, Shekh-Yusef, Rifaat (Rifaat) wrote: >> Thanks Yaron, >> >> I like the text you proposed below; I will add it to the limitations section. >> >> Regards, >> Rifaat >> >> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> Sent: Sunday, June 23, 2013 1:40 AM >>> To: Shekh-Yusef, Rifaat (Rifaat) >>> Cc: http-auth@ietf.org >>> Subject: Re: [http-auth] Digest Update - Algorithm Agility >>> >>> In addition to the algorithm question, there's the bigger question of >>> the actual security (rather than "regulatory compliance") benefit that >>> this buys us. If HTTP-Digest is used with short passwords over an >>> unencrypted medium (or an encrypted one, where there may be a MITM >>> attacker), then using SHA256 instead of MD5 has zero benefit. Dictionary >>> attacks are much more effective than breaking MD5, and will remain so >>> for the foreseeable future. >>> >>> So the whole exercise only seems worthwhile when used with non-memorable >>> "passwords", i.e. with actual crypto keys. Which really only makes sense >>> within web services, rather than regular browsing. I suggest adding the >>> following section to the draft: >>> >>> --- start text --- >>> >>> Applicability >>> >>> HTTP Digest authentication, when used with human-memorable passwords, is >>> vulnerable to dictionary attacks. Such attacks are much easier than >>> cryptographic attacks on any widely used algorithm, including those that >>> are no longer considered secure. In other words, algorithm agility does >>> not make this usage any more secure. >>> >>> As a result, Digest authentication SHOULD be used only with passwords >>> that have a reasonable amount of entropy, e.g. 128-bit or more. Such >>> passwords typically cannot be memorized by humans but can be used for >>> automated web services. >>> >>> --- end text --- >>> >>> Yes, the text refers to RFC 2617 in the security considerations. But 14 >>> years later I believe we can do better than that. >>> >>> Thanks, >>> Yaron >>> >>> On 2013-06-22 20:46, Shekh-Yusef, Rifaat (Rifaat) wrote: >>>> I have just submitted a new version of this draft. >>>> http://www.ietf.org/id/draft-ietf-httpauth-digest-update-01.txt >>>> >>>> With this new version I fixed few nits and removed the i18n section; I >>> have started working on a new separate draft to address the i18n. >>>> >>>> Meanwhile, I would like to continue the Algorithm Agility discussion >>> to try to come to an agreement on this issue. >>>> The feedback I got so far seems to indicate that we want to limit the >>> algorithm agility to few of the best current algorithms. >>>> How about the following: >>>> SHA3-256 as the default algorithm. >>>> SHA2-256 as a backup algorithm. >>>> MD5 for backward compatibility. >>>> >>>> Any thoughts? >>>> >>>> Thanks, >>>> Rifaat >>>> >>>> _______________________________________________ >>>> http-auth mailing list >>>> http-auth@ietf.org >>>> https://www.ietf.org/mailman/listinfo/http-auth >>>> >> _______________________________________________ >> http-auth mailing list >> http-auth@ietf.org >> https://www.ietf.org/mailman/listinfo/http-auth >> >> From ynir@checkpoint.com Mon Jun 24 01:34:34 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE65B21F9C74 for ; Mon, 24 Jun 2013 01:34:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.606 X-Spam-Level: X-Spam-Status: No, score=-10.606 tagged_above=-999 required=5 tests=[AWL=-0.007, 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 22MpE0jN+EdC for ; Mon, 24 Jun 2013 01:34:18 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C41E421F9A7E for ; Mon, 24 Jun 2013 01:33:32 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5O8XRn8015707; Mon, 24 Jun 2013 11:33:27 +0300 X-CheckPoint: {51C80457-33-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 11:33:27 +0300 From: Yoav Nir To: Yaron Sheffer Thread-Topic: [http-auth] Digest Update - Algorithm Agility Thread-Index: Ac5vcGDzjIMHkxy/T5CTGMqDZTuQagASpiAAAAlBu4AAAF/QAAAtYwgAAAFTcwA= Date: Mon, 24 Jun 2013 08:33:27 +0000 Message-ID: References: <51C68A38.8020005@gmail.com> <51C6CADA.70203@cs.tcd.ie> <51C7FB70.1060105@gmail.com> In-Reply-To: <51C7FB70.1060105@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.31.21.195] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11c2da332a7ebdc249643b50443315ca66f5e5a64e Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 08:34:36 -0000 Hi Yaron. On Jun 24, 2013, at 10:55 AM, Yaron Sheffer wrote: > Hi Stephen, >=20 > please see some comments below. >=20 > Thanks, > Yaron >=20 > On 2013-06-23 13:15, Stephen Farrell wrote: >>=20 >> Seems like a fine direction. SHA3 defo ought not be the default >> but is probably ok as a backup. >>=20 >=20 > +1, even after SHA3 is finally standardized. Because it'll be quite a few= years before it is widely implemented. >=20 >> I'd add something along the lines that you really ought only send >> these headers over HTTPS, properly validated. And that since that's >> quite practical these days clients SHOULD require that (or stated >> another way clients SHOULD NOT send these headers in clear) and >> servers SHOULD log if they receive such headers in clear (but they >> MUST NOT log the header values!!) and try to something about that >> (go fix your own site's use of TLS). >=20 > I think you're going too far here. There's value in authenticating HTTP, = even when traffic is unencrypted, and especially if Session Continuation ha= ppens. OTOH I don't think the industry is ready to mandate encryption at th= e SHOULD level. I agree that the industry is not ready, but this option was discussed exten= sively at httpbis last July, and not only by security geeks: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0455.html (OK,= not the best example of non-security-geek) http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0464.html http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0548.html >> It might also be worth putting the same piece of text into all the >> drafts this wg produces where dictionary attacks are possible based >> on the headers emitted. That'd maybe also mean a few editorial >> changes. (No rush on that, probably better finalised when more than >> one doc is ready for WGLC.) >>=20 >> As another point, it might also be worthwhile having a bit of >> text for all drafts that are vulnerable to password verifier >> database theft. IMO that really is the most important security >> consideration for all these mechanisms (today at least). I don't >> have time right now to draft that but will happily try later if >> someone reminds me. (maybe plonk an issue in the tracker?) >=20 > I disagree about the relative important of these threats (passive/active = attacks on traffic vs. off-line analysis of captured password databases), b= ecause we've seen to what lengths governments, enterprises and service prov= iders are willing to go to MITM people's traffic. But I guess it's a pointl= ess argument. >From what I've seen, they go to the provider. AFAIK breaking SSL on the nat= ional level is pretty rare.=20 Yoav From yaronf.ietf@gmail.com Mon Jun 24 01:45:13 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E493A11E80F2 for ; Mon, 24 Jun 2013 01:45:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mEUy0qPK2Vi3 for ; Mon, 24 Jun 2013 01:45:11 -0700 (PDT) Received: from mail-bk0-x231.google.com (mail-bk0-x231.google.com [IPv6:2a00:1450:4008:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id EBD3D21E80DE for ; Mon, 24 Jun 2013 01:43:22 -0700 (PDT) Received: by mail-bk0-f49.google.com with SMTP id mz10so4031314bkb.8 for ; Mon, 24 Jun 2013 01:43:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=m2YYsZOc+7LKTIrxKwmnH+Szy51eKMJiUWjqJq8z708=; b=oMERvE/9TZofzilQFBkcVvGBaqZov58tNpOv0Y21w1D3owXZi1n25Z4jKyMxi33qQY YrdFUL8Yx0HBWWL7fG8LrpTh6lvZpe3sBxbwfqpeX0WmBPQreFQzjNDldpZEHoU45ZNp 6kWwJOx6BT7EOpX81/Vofw0SLG+Ux0wkcVh3eu/V2iRAIIsaxe0WJcdp3cavfggwTbBD DXtB2Ke7fN6yOnH/b97dvf2nWHxkIE/D295AFTIf+lu7Yl8Kc6SKqxQSURL6za98He1w 6BBXd6s3zEOb313v3vG7J0SHkuldBnO+ldUD7PHx+nDWhFLpmP+FpCDvgzoMgAuoNQX2 Tz8g== X-Received: by 10.204.71.2 with SMTP id f2mr3525385bkj.54.1372063401753; Mon, 24 Jun 2013 01:43:21 -0700 (PDT) Received: from [10.0.0.14] (109-186-101-35.bb.netvision.net.il. [109.186.101.35]) by mx.google.com with ESMTPSA id jm15sm4001868bkb.13.2013.06.24.01.43.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 01:43:21 -0700 (PDT) Message-ID: <51C806A7.5030605@gmail.com> Date: Mon, 24 Jun 2013 11:43:19 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoav Nir References: <51C68A38.8020005@gmail.com> <51C6CADA.70203@cs.tcd.ie> <51C7FB70.1060105@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 08:45:13 -0000 Hi Yoav, out of the three messages you link, I tend to agree with Carsten who says that a mechanism should not mandate a policy. In any case, a new version of HTTP-Auth is NOT the right place to say, thou SHALL encrypt everything. Re: MITM, I did not mean specifically attacks on SSL. The Tunisian attack is an HTTP-level MITM for password recovery. The Iranian attack is an honest-to-God SSL MITM. Enterprise SSL proxies are an SSL MITM with (some, implicit) user consent. Traffic shaping being done every day by many providers *can* be considered a MITM attack, though some would disagree. Thanks, Yaron On 2013-06-24 11:33, Yoav Nir wrote: > Hi Yaron. > > On Jun 24, 2013, at 10:55 AM, Yaron Sheffer wrote: > >> Hi Stephen, >> >> please see some comments below. >> >> Thanks, >> Yaron >> >> On 2013-06-23 13:15, Stephen Farrell wrote: >>> >>> Seems like a fine direction. SHA3 defo ought not be the default >>> but is probably ok as a backup. >>> >> >> +1, even after SHA3 is finally standardized. Because it'll be quite a few years before it is widely implemented. >> >>> I'd add something along the lines that you really ought only send >>> these headers over HTTPS, properly validated. And that since that's >>> quite practical these days clients SHOULD require that (or stated >>> another way clients SHOULD NOT send these headers in clear) and >>> servers SHOULD log if they receive such headers in clear (but they >>> MUST NOT log the header values!!) and try to something about that >>> (go fix your own site's use of TLS). >> >> I think you're going too far here. There's value in authenticating HTTP, even when traffic is unencrypted, and especially if Session Continuation happens. OTOH I don't think the industry is ready to mandate encryption at the SHOULD level. > > I agree that the industry is not ready, but this option was discussed extensively at httpbis last July, and not only by security geeks: > > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0455.html (OK, not the best example of non-security-geek) > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0464.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0548.html > >>> It might also be worth putting the same piece of text into all the >>> drafts this wg produces where dictionary attacks are possible based >>> on the headers emitted. That'd maybe also mean a few editorial >>> changes. (No rush on that, probably better finalised when more than >>> one doc is ready for WGLC.) >>> >>> As another point, it might also be worthwhile having a bit of >>> text for all drafts that are vulnerable to password verifier >>> database theft. IMO that really is the most important security >>> consideration for all these mechanisms (today at least). I don't >>> have time right now to draft that but will happily try later if >>> someone reminds me. (maybe plonk an issue in the tracker?) >> >> I disagree about the relative important of these threats (passive/active attacks on traffic vs. off-line analysis of captured password databases), because we've seen to what lengths governments, enterprises and service providers are willing to go to MITM people's traffic. But I guess it's a pointless argument. > > From what I've seen, they go to the provider. AFAIK breaking SSL on the national level is pretty rare. > > Yoav > From stephen.farrell@cs.tcd.ie Mon Jun 24 02:14:18 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D215921E8098 for ; Mon, 24 Jun 2013 02:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, 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 Sy7Hu60iuJ72 for ; Mon, 24 Jun 2013 02:14:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8658F21F9E1C for ; Mon, 24 Jun 2013 02:14:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C0029BE79; Mon, 24 Jun 2013 10:13:48 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1krGWUvVWDHP; Mon, 24 Jun 2013 10:13:48 +0100 (IST) Received: from [IPv6:2001:770:10:203:4c2c:7455:93b4:4d5b] (unknown [IPv6:2001:770:10:203:4c2c:7455:93b4:4d5b]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94E2CBE68; Mon, 24 Jun 2013 10:13:48 +0100 (IST) Message-ID: <51C80DCC.4040907@cs.tcd.ie> Date: Mon, 24 Jun 2013 10:13:48 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Yoav Nir References: <51C68A38.8020005@gmail.com> <51C6CADA.70203@cs.tcd.ie> <51C7FB70.1060105@gmail.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "http-auth@ietf.org" Subject: Re: [http-auth] Digest Update - Algorithm Agility X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 09:14:19 -0000 Hi Yoav, Yaron, On 06/24/2013 09:33 AM, Yoav Nir wrote: > Hi Yaron. > > On Jun 24, 2013, at 10:55 AM, Yaron Sheffer wrote: > >> Hi Stephen, >> >> please see some comments below. >> >> Thanks, >> Yaron >> >> On 2013-06-23 13:15, Stephen Farrell wrote: >>> >>> Seems like a fine direction. SHA3 defo ought not be the default >>> but is probably ok as a backup. >>> >> >> +1, even after SHA3 is finally standardized. Because it'll be quite a few years before it is widely implemented. >> >>> I'd add something along the lines that you really ought only send >>> these headers over HTTPS, properly validated. And that since that's >>> quite practical these days clients SHOULD require that (or stated >>> another way clients SHOULD NOT send these headers in clear) and >>> servers SHOULD log if they receive such headers in clear (but they >>> MUST NOT log the header values!!) and try to something about that >>> (go fix your own site's use of TLS). >> >> I think you're going too far here. There's value in authenticating HTTP, even when traffic is unencrypted, and especially if Session Continuation happens. OTOH I don't think the industry is ready to mandate encryption at the SHOULD level. > > I agree that the industry is not ready, but this option was discussed extensively at httpbis last July, and not only by security geeks: > > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0455.html (OK, not the best example of non-security-geek) > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0464.html > http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/0548.html Its fair to say that my suggesting "SHOULD use TLS" is a bit bogus in 2119 terms. I guess "MUST use TLS" would also work for me and isn't bogus:-) I do however think that we ought to put in the strongest possible guidance we think is practical, because sending dictionary attackable values over the Internet in clear really is dumb and the world has moved on since 1999 when RFC 2617 was finished. BTW, "MUST use TLS" is demonstrably doable. I just setup a free (but real, i.e. verifiable in afaik all browsers) TLS server cert on a box and that took all of 20 minutes, with a bit of messing about setting up mail for the domain etc. so the 20 minutes of PKI was spread over a couple of days. That particular CA service does require you to control the domain, and that's not always possible, e.g. I couldn't have done it for a machine within tcd.ie, so for those I tend to use self-signed server certs rather than deal with college admin folks:-) So stuff I setup within tcd.ie does use TLS, but not entirely properly. And that's why I ended up with the dodgy SHOULD statement. How we wordsmith all that is a fine thing to discuss here, but I'm sure we can come up with something that'll be good enough. >>> It might also be worth putting the same piece of text into all the >>> drafts this wg produces where dictionary attacks are possible based >>> on the headers emitted. That'd maybe also mean a few editorial >>> changes. (No rush on that, probably better finalised when more than >>> one doc is ready for WGLC.) >>> >>> As another point, it might also be worthwhile having a bit of >>> text for all drafts that are vulnerable to password verifier >>> database theft. IMO that really is the most important security >>> consideration for all these mechanisms (today at least). I don't >>> have time right now to draft that but will happily try later if >>> someone reminds me. (maybe plonk an issue in the tracker?) >> >> I disagree about the relative important of these threats (passive/active attacks on traffic vs. off-line analysis of captured password databases), because we've seen to what lengths governments, enterprises and service providers are willing to go to MITM people's traffic. But I guess it's a pointless argument. > >>From what I've seen, they go to the provider. AFAIK breaking SSL on the national level is pretty rare. Guidance here ought be aimed at implementers and those who deploy authentication schemes that need password verifier databases. (PVDB) We clearly can't say "don't do that" because "doing that" is inherent in using these auth schemes, but we really have to call out the problem and 2617 doesn't really do that. (The closest it gets seems to be in 4.13 [1] which does discuss the problem but doesn't really reflect what's been happening with millions of PVDB entries leaking constantly as has been happening for the last few years.) Whether this is the most important thing or not is certainly debatable, and probably not a debate that we can resolve, but I hope we all do consider PVDB leaks a serious vulnerability and can agree we at least have to recognise the vulnerability where it exists and also the reality that this vulnerability has been exploited at scale and repeatedly and that there is a lot of code out there that helps one to exploit that vulnerability when you get your hands on PVDB entries. Cheers, S. [1] http://tools.ietf.org/html/rfc2617#section-4.13 > Yoav > > From mark.cavage@joyent.com Mon Jun 24 12:46:50 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316B321F9AC5 for ; Mon, 24 Jun 2013 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 11j6Eek2wOUj for ; Mon, 24 Jun 2013 12:46:49 -0700 (PDT) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 425BE21F9AA9 for ; Mon, 24 Jun 2013 12:46:49 -0700 (PDT) Received: by mail-ve0-f170.google.com with SMTP id 14so9189561vea.15 for ; Mon, 24 Jun 2013 12:46:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=BZNPb72x9PmorEuWfnIbjwYcqH9GJ2UsRVsng+/YwmA=; b=AxXofWfsK51CXAhwQYiwKg2O/2PAp76yhAs5AqC4WusUuHe++UOMEJ7QFI3aszdHey fDl2TmhMM730L3fntPPcqq1zEGZtaQndYOx+4gY0lYIJHsZRmxzQY4BI0AJF5LWwO/hj SxbUgo0IB+RcD/tZw+PE9eInCUOGVa8IS5c2LxObYrgamPKqOSy8EzuSBM7iaHskqJuP FcLHGhvefxTFK9kPwFkuxtzlGTlstqklzCG7nickOot9VGaxlX+T5TkCRAaQkaL5hDhQ 5s4kOuPeIooUeumo6GTB3OdnGIjhMiBLQdluzSCKHv15Hf8rW9yfhCKdra6AdWyTJNsQ 6ntQ== MIME-Version: 1.0 X-Received: by 10.52.231.130 with SMTP id tg2mr9959009vdc.84.1372103208535; Mon, 24 Jun 2013 12:46:48 -0700 (PDT) Received: by 10.58.196.230 with HTTP; Mon, 24 Jun 2013 12:46:48 -0700 (PDT) In-Reply-To: <51C7CD18.5060801@digitalbazaar.com> References: <51C7CD18.5060801@digitalbazaar.com> Date: Mon, 24 Jun 2013 12:46:48 -0700 Message-ID: From: Mark Cavage To: Manu Sporny Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkQnqCQym4i8XswAKS9madALvOOtr4MVEd1R+5Qav4qEYygCFdyWawc6gU12xAhJvbOhYBZ Cc: IETF HTTP Auth , Web Payments Subject: Re: [http-auth] Lift nonces / trailers into separate spec X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 19:46:50 -0000 Hi Manu, I think that's a great idea. Both of those use cases are necessary for completeness, but off the common path (at least IMO, and it sounds like David's as well). Yep, I knew about hawk which came out well after http-signatures, and as you said is HMAC only. But agreed we can bring their security considerations we didn't cover in. m On Sun, Jun 23, 2013 at 9:37 PM, Manu Sporny wrote: > This is mostly directed at Mark Cavage, but thought it would be good to > keep the Web Payments and HTTP Auth groups apprised of the situation. > > We had a quick 5 minute discussion on the #payswarm IRC channel about > the optional features of HTTP signatures last week. Dave Lehn really > didn't like that we were complicating the HTTP Signatures spec by > talking about nonces (for HTTP) and HTTP trailer signatures. Dave > Longley suggested that we move all optional features of HTTP Signatures > spec into a separate spec. > > This would have two positive outcomes: > > 1. It would make it so that we can focus on the core spec and push > that forward at IETF. > 2. It would reduce the "aww, man - not nonces again!" complaints. > > While we do have a pretty solid plan for nonces and trailers[1], we may > not want to burn the time on ironing out all of the gory details right > now since we don't have anyone demanding that HTTP Signatures work over > an unencrypted connection. > > Ben Adida pointed me at this spec when I mentioned that we were working > on HTTP Signatures (he's a co-author of the Hawk protocol): > > https://github.com/hueniverse/hawk > > A couple of takeaways from that implementation: > > * The way they do time synchronization is interesting. > * The way they do nonces is basically the same approach we take. > * Theirs is an HMAC solution, which we really, really, > don't want to support. > * Bewit is interesting, but I don't think it has a place in HTTP > Signatures. > * We want to integrate most of their security considerations section > into the HTTP Signatures Security Considerations document. > > -- manu > > [1] https://payswarm.com/minutes/2013-06-19/ > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Meritora - Web payments commercial launch > http://blog.meritora.com/launch/ From melvincarvalho@gmail.com Tue Jun 25 03:27:49 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5F11E80E0 for ; Tue, 25 Jun 2013 03:27:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.183 X-Spam-Level: X-Spam-Status: No, score=-2.183 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-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 smFECgo-XXeW for ; Tue, 25 Jun 2013 03:27:48 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EFCF521F9ED0 for ; Tue, 25 Jun 2013 03:27:47 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id er20so11876687lab.3 for ; Tue, 25 Jun 2013 03:27:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=74dfZDuKou6bbx52ye9/i5CxLt1Z2uamCXwZjVkNWw8=; b=eLQnqgW+hpM4gbKPrBuqkdHLHr23hujfGnlNPX3OJRHD2K6zRjO/NRwCNKJDwqeZ7g FYuqgBvnlgaHJeSGs+GkQdFiFzrjs9Dk+8aZmDpmgfnuzMfYE1J3KFUZosUoLFzX0Alw c2BJvuexOVUgdNp32GdUiokeSPHVwYoI87rqnFwv8d3Pu+ZOveYP7Ro24gAOAsIPpRET a5OQIKm8xB4+PZmsppmg/OWRnZ4Bh2wax8YhsFvwt2LBnlDNGCV9TJPKtMIgsMlMqQ5A FaceFWcESilbN5PcDJtVDL87630KAUBcEIZ+d6rkOnd4+61IV/ku8P+daOYBXmTs4DiV IzKQ== MIME-Version: 1.0 X-Received: by 10.152.26.2 with SMTP id h2mr13553193lag.52.1372156063491; Tue, 25 Jun 2013 03:27:43 -0700 (PDT) Received: by 10.112.119.138 with HTTP; Tue, 25 Jun 2013 03:27:43 -0700 (PDT) In-Reply-To: <51C7CD18.5060801@digitalbazaar.com> References: <51C7CD18.5060801@digitalbazaar.com> Date: Tue, 25 Jun 2013 12:27:43 +0200 Message-ID: From: Melvin Carvalho To: Manu Sporny Content-Type: multipart/alternative; boundary=089e0158be44bdb25404dff7faf7 X-Mailman-Approved-At: Tue, 25 Jun 2013 03:29:28 -0700 Cc: IETF HTTP Auth , Web Payments Subject: Re: [http-auth] Lift nonces / trailers into separate spec X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 10:27:49 -0000 --089e0158be44bdb25404dff7faf7 Content-Type: text/plain; charset=ISO-8859-1 On 24 June 2013 06:37, Manu Sporny wrote: > This is mostly directed at Mark Cavage, but thought it would be good to > keep the Web Payments and HTTP Auth groups apprised of the situation. > > We had a quick 5 minute discussion on the #payswarm IRC channel about > the optional features of HTTP signatures last week. Dave Lehn really > didn't like that we were complicating the HTTP Signatures spec by > talking about nonces (for HTTP) and HTTP trailer signatures. Dave > Longley suggested that we move all optional features of HTTP Signatures > spec into a separate spec. > > This would have two positive outcomes: > > 1. It would make it so that we can focus on the core spec and push > that forward at IETF. > 2. It would reduce the "aww, man - not nonces again!" complaints. > Nonces play a key role in bitcoin and ripple, I'd be keen to reuse them, but dont mind it moving to another spec. It will be in the same vocab, right? > > While we do have a pretty solid plan for nonces and trailers[1], we may > not want to burn the time on ironing out all of the gory details right > now since we don't have anyone demanding that HTTP Signatures work over > an unencrypted connection. > > Ben Adida pointed me at this spec when I mentioned that we were working > on HTTP Signatures (he's a co-author of the Hawk protocol): > > https://github.com/hueniverse/hawk > > A couple of takeaways from that implementation: > > * The way they do time synchronization is interesting. > * The way they do nonces is basically the same approach we take. > * Theirs is an HMAC solution, which we really, really, > don't want to support. > * Bewit is interesting, but I don't think it has a place in HTTP > Signatures. > * We want to integrate most of their security considerations section > into the HTTP Signatures Security Considerations document. > I've started looking at Hawk, it looks very interesting indeed. Eran of course was one of the people behind OAuth, and Hawk aims to address some of OAuth's weaknesses. I asked Eran if it was possible to identify yourself to a server using a URI (something which most Identity systems cant do), and he said that it should be possible. So I have to say this looks very promising! > > -- manu > > [1] https://payswarm.com/minutes/2013-06-19/ > > -- > Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) > Founder/CEO - Digital Bazaar, Inc. > blog: Meritora - Web payments commercial launch > http://blog.meritora.com/launch/ > > --089e0158be44bdb25404dff7faf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On 24 June 2013 06:37, Manu Sporny <msporny@digitalbazaar.= com> wrote:
This is mostly directed at Mark Cavage, but = thought it would be good to
keep the Web Payments and HTTP Auth groups apprised of the situation.

We had a quick 5 minute discussion on the #payswarm IRC channel about
the optional features of HTTP signatures last week. Dave Lehn really
didn't like that we were complicating the HTTP Signatures spec by
talking about nonces (for HTTP) and HTTP trailer signatures. Dave
Longley suggested that we move all optional features of HTTP Signatures
spec into a separate spec.

This would have two positive outcomes:

1. It would make it so that we can focus on the core spec and push
=A0 =A0that forward at IETF.
2. It would reduce the "aww, man - not nonces again!" complaints.=

Nonces play a key role in bitcoin and = ripple, I'd be keen to reuse them, but dont mind it moving to another s= pec.=A0 It will be in the same vocab, right?
=A0

While we do have a pretty solid plan for nonces and trailers[1], we may
not want to burn the time on ironing out all of the gory details right
now since we don't have anyone demanding that HTTP Signatures work over=
an unencrypted connection.

Ben Adida pointed me at this spec when I mentioned that we were working
on HTTP Signatures (he's a co-author of the Hawk protocol):

https://gi= thub.com/hueniverse/hawk

A couple of takeaways from that implementation:

* The way they do time synchronization is interesting.
* The way they do nonces is basically the same approach we take.
* Theirs is an HMAC solution, which we really, really,
=A0 don't want to support.
* Bewit is interesting, but I don't think it has a place in HTTP
=A0 Signatures.
* We want to integrate most of their security considerations section
=A0 into the HTTP Signatures Security Considerations document.

I've started looking at Hawk, it looks very int= eresting indeed.=A0 Eran of course was one of the people behind OAuth, and = Hawk aims to address some of OAuth's weaknesses.=A0 I asked Eran if it = was possible to identify yourself to a server using a URI (something which = most Identity systems cant do), and he said that it should be possible.=A0 = So I have to say this looks very promising!
=A0

-- manu

[1] = https://payswarm.com/minutes/2013-06-19/

--
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.= meritora.com/launch/


--089e0158be44bdb25404dff7faf7-- From internet-drafts@ietf.org Sun Jun 30 03:33:19 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86E621F9AE7; Sun, 30 Jun 2013 03:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 bFmDmjZ9inPh; Sun, 30 Jun 2013 03:33:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8095C21F925A; Sun, 30 Jun 2013 03:33:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130630103319.4296.44427.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 03:33:19 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-digest-update-02.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 10:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : HTTP Digest Update Author(s) : Rifaat Shekh-Yusef David Ahrens Filename : draft-ietf-httpauth-digest-update-02.txt Pages : 9 Date : 2013-06-30 Abstract: This documents specifies extensions to the HTTP Digest Authentication mechanism to add support for new digest algorithms to the HTTP Digest Access Authentication scheme. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-digest-update-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-digest-update-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rifatyu@avaya.com Sun Jun 30 03:44:32 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F43F21F9C7A for ; Sun, 30 Jun 2013 03:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1qW5A7kaUP2 for ; Sun, 30 Jun 2013 03:44:19 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E109521F9C70 for ; Sun, 30 Jun 2013 03:44:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkIFAJYL0FGHCzI1/2dsb2JhbABagkUjIQExg1C1DYcNcBZ0gioSEUsdAQwJNQIEMCYBBBwZh20BC5sahEKKOpBLjhOEIzNjA5dIhkSLAYMR X-IronPort-AV: E=Sophos;i="4.87,968,1363147200"; d="scan'208,217";a="18329212" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 30 Jun 2013 06:44:17 -0400 Received: from unknown (HELO AZ-US1EXHC01.global.avaya.com) ([135.11.85.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 30 Jun 2013 06:38:50 -0400 Received: from AZ-US1EXMB05.global.avaya.com ([fe80::d51e:20b6:bd25:82b7]) by AZ-US1EXHC01.global.avaya.com ([135.11.85.12]) with mapi id 14.02.0328.009; Sun, 30 Jun 2013 06:44:17 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: "http-auth@ietf.org" Thread-Topic: Digest Update - 02 Thread-Index: Ac51fsRGPYxsC6n5SvKqPS7krauCYQ== Date: Sun, 30 Jun 2013 10:44:15 +0000 Message-ID: <3924B850-6564-4BBF-AD24-11E4080F4B28@avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3924B85065644BBFAD2411E4080F4B28avayacom_" MIME-Version: 1.0 Subject: [http-auth] Digest Update - 02 X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 10:44:32 -0000 --_000_3924B85065644BBFAD2411E4080F4B28avayacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBEaWdlc3QgVXBkYXRl IGRyYWZ0Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWh0dHBhdXRoLWRpZ2Vz dC11cGRhdGUtMDIudHh0DQoNCg0KVGhlIG5ldyBkcmFmdCBoYXMgdGhlIGZvbGxvd2luZyBjaGFu Z2VzOg0KDQoxLiBDaGFuZ2VkIHRoZSBsaXN0IG9mIGFsZ29yaXRobXMsIGFzIGZvbGxvd3M6IFNI QTItMjU2IChkZWZhdWx0KSwgU0hBMy0yNTYgKGJhY2t1cCksIGFuZCBNRDUgKGZvciBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5KSwgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcg bGlzdC4NCg0KMi4gTmV3IHRleHQgaW4gdGhlIGxpbWl0YXRpb24gc2VjdGlvbiBiYXNlZCBvbiB0 aGUgZGlzY3Vzc2lvbiBvbiB0aGUgbWFpbGluZyBsaXN0IHdpdGggZmVlZGJhY2sgZnJvbSBZYXJv biBTaGVmZmVyIGFuZCBTdGVwaGVuIEZhcnJlbGwuDQoNCjMuIE5ldyBzZWN0aW9uIChzZWN0aW9u IDIpIGFyb3VuZCBzeW50YXggY29udmVudGlvbi4NCg0KDQpXZSB3b3VsZCBhcHByZWNpYXRlIHlv dXIgZmVlZGJhY2sgb24gdGhlIG5ldyBkcmFmdC4NCg0KVGhhbmtzLA0KIFJpZmFhdA0KDQpTZW50 IGZyb20gbXkgaVBob25lDQo= --_000_3924B85065644BBFAD2411E4080F4B28avayacom_ Content-Type: text/html; charset="utf-8" Content-ID: <95C47C93936D7B419AFCEB25E8119A61@avaya.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2IHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87ICI+PHNwYW4+PC9zcGFu PjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0 bzsgIj48c3BhbiBzdHlsZT0iLXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiByZ2JhKDI2LCAy NiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1maWxsLWNvbG9yOiByZ2JhKDE3 NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21wb3NpdGlvbi1mcmFtZS1jb2xvcjog cmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgIj5XZSBoYXZlIGp1c3QNCiBzdWJtaXR0ZWQg YSBuZXcgdmVyc2lvbiBvZiB0aGUgRGlnZXN0Jm5ic3A7VXBkYXRlIGRyYWZ0Ojwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6ICcuSGVsdmV0aWNhTmV1ZVVJJzsgZm9udC1zaXplOiAxNXB4OyBs aW5lLWhlaWdodDogMTlweDsgd2hpdGUtc3BhY2U6IG5vd3JhcDsgLXdlYmtpdC10YXAtaGlnaGxp Z2h0LWNvbG9yOiByZ2JhKDI2LCAyNiwgMjYsIDAuMjk2ODc1KTsgLXdlYmtpdC1jb21wb3NpdGlv bi1maWxsLWNvbG9yOiByZ2JhKDE3NSwgMTkyLCAyMjcsIDAuMjMwNDY5KTsgLXdlYmtpdC1jb21w b3NpdGlvbi1mcmFtZS1jb2xvcjogcmdiYSg3NywgMTI4LCAxODAsIDAuMjMwNDY5KTsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBub25lOyAiPjxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcv aWQvZHJhZnQtaWV0Zi1odHRwYXV0aC1kaWdlc3QtdXBkYXRlLTAyLnR4dCI+aHR0cDovL3d3dy5p ZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWh0dHBhdXRoLWRpZ2VzdC11cGRhdGUtMDIudHh0PC9hPjwv c3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsg Ij48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9Ii13 ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUs IDI1NSwgMjU1LCAwKTsiPlRoZSBuZXcgZHJhZnQgaGFzIHRoZSBmb2xsb3dpbmcgY2hhbmdlczo8 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87Ij48YnI+DQo8L3NwYW4+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6 ZS1hZGp1c3Q6IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7 Ij4xLiBDaGFuZ2VkIHRoZSBsaXN0IG9mIGFsZ29yaXRobXMsIGFzIGZvbGxvd3M6IFNIQTItMjU2 IChkZWZhdWx0KSwgU0hBMy0yNTYgKGJhY2t1cCksIGFuZCBNRDUgKGZvciBiYWNrd2FyZCBjb21w YXRpYmlsaXR5KSwgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gb24gdGhlIG1haWxpbmcgbGlzdC48 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij48YnI+DQo8 L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij4yLiBOZXcg dGV4dCBpbiB0aGUgbGltaXRhdGlvbiBzZWN0aW9uIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIG9u IHRoZSBtYWlsaW5nIGxpc3Qgd2l0aCBmZWVkYmFjayBmcm9tIFlhcm9uIFNoZWZmZXIgYW5kIFN0 ZXBoZW4gRmFycmVsbC48L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1 NSwgMCk7Ij48YnI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSItd2Via2l0LXRl eHQtc2l6ZS1hZGp1c3Q6IGF1dG87IGJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1 NSwgMCk7Ij4zLiBOZXcgc2VjdGlvbiAoc2VjdGlvbiAyKSBhcm91bmQgc3ludGF4IGNvbnZlbnRp b24uPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJy Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJy Pg0KPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+V2Ug d291bGQgYXBwcmVjaWF0ZSB5b3VyIGZlZWRiYWNrIG9uIHRoZSBuZXcgZHJhZnQuPC9zcGFuPjwv ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+PGJyPg0KPC9zcGFuPjwv ZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyBi YWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDApOyI+VGhhbmtzLDwvc3Bhbj48 L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9Ii13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsg YmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPiZuYnNwO1JpZmFhdDwv c3Bhbj48L2Rpdj4NCjxicj4NCjxzcGFuIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87ICI+U2VudCBmcm9tIG15IGlQaG9uZTwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_3924B85065644BBFAD2411E4080F4B28avayacom_-- From julian.reschke@gmx.de Sun Jun 30 06:12:27 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E0F21F9A31 for ; Sun, 30 Jun 2013 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-4.000, 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 wAZSh5MHiwnW for ; Sun, 30 Jun 2013 06:12:23 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7E21F9A33 for ; Sun, 30 Jun 2013 06:12:22 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MBptp-1V3xrO3jEd-00AkBI for ; Sun, 30 Jun 2013 15:12:21 +0200 Received: (qmail invoked by alias); 30 Jun 2013 13:12:21 -0000 Received: from p5DD97A5B.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.122.91] by mail.gmx.net (mp002) with SMTP; 30 Jun 2013 15:12:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/ji9sN2Bnjr9krpFxxi1znohPDdJQPYla67YRVA7 6VKYjm1IJYA5Vt Message-ID: <51D02EAC.5050907@gmx.de> Date: Sun, 30 Jun 2013 15:12:12 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Stephen Farrell References: <20130516191811.8525.51598.idtracker@ietfa.amsl.com> <5195F65F.7030803@cs.tcd.ie> <5196086B.3000700@gmx.de> In-Reply-To: <5196086B.3000700@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-00.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 13:12:27 -0000 On 2013-05-17 12:37, Julian Reschke wrote: > On 2013-05-17 11:20, Stephen Farrell wrote: >> >> Nice. This looks pretty baked to me. Some nitty comments >> below, nothing major at all. >> >> Cheers, >> S. >> >> - What's the story on updating/obsoleting 2617? I don't much > > HTTPbis P7 obsoletes the framework part of RFC 2617. We'll need two > additional specs defining Basic and Digest to get rid of RFC 2617 > completely. > > *This* draft just addresses the I18N issue of Basic. The reason why I > don't want to do it in a new Basic spec is that this *really* is > experimental. There's no point putting it into something that's > replacing 2617 if we don't have any evidence that it works. > >> care but this'd be a good thing to work out before IETF LC as >> otherwise we might end up doing multiple LC's to get it right. >> Seems like httpbis-p7 doesn't obsolete 2617 and nor does this >> and presumably nor would an updated digest. Somehow that seems >> wrong;-) I can't recall if 3 RFCs can all obsolete 2617 or >> not but maybe that'd be worth checking out with someone who >> cares. I can find someone who cares and ask if that's what >> the wg want - the chairs can tell me if so, or that might be >> better as a thing the httpbis wg think about, or perhaps its >> all been thought about already. >> >> - An additional example or two would be good, maybe with >> a username and password with asian characters or something. >> If sticking with one Example, maybe change the title of >> section 4:-) > > Ok. Done. >> - section 5: I wondered if there are any potential bad effects >> if a UA sends an Authorization header like this to a server >> that only supports ASCII. Is it worth adding a warning that >> servers that assume that they get ASCII after base64 decoding >> Authorization headers might get a surprise? Yes, it'd have >> to be pretty crappy server code for that to cause a security >> problem, but I guess it could happen. > > Clients already send non-ASCII; the issue here is making the encoding > reliable. > >> - A.1: do we know that current UAs will actually ignore the >> new parameter? I think I recall someone saying that is the >> case, but I forget. Ah - you have it in B.3 - I think it'd >> be better to merge those bits. The links from B.3 are great >> btw, thanks for doing that work. > > I can do that. Actually, that part is in B.3 because it's a section I assume will be removed in the final RFC. >> - A.1.1: trying twice made me wonder if there's any way to >> leverage that for some kind of side-channel/oracle attack. >> Can't think of one but has someone thought about that? > > Feedback appreciated :-) > >> - A.2: "as well as before" - is that being disingenuous? If >> so I think it'd be better not to do that since many people >> reading this won't get it. I'd suggest replacing that with >> "as well or as badly as before." > > Ack. Done. >> - B.2: "this scheme" - I think the "this" here refers to >> Digest, but its ambiguous as written. > > Also, this WG actually is chartered to update Digest, so this needs work. I rephrased this to say: "The Digest scheme has similar issues with respect to internationalization. The HTTPAuth Working Group is chartered to address this problem as well, and the solution might be very similar." >> - D.2: I don't understand this but then I never did and >> probably never will, so you could add anything and that'd >> work for me:-) > > Thanks for the feedback! > > Best regards, Julian Best regards, Julian PS: "done" meaning: in the HTTPauth SVN (see ) From internet-drafts@ietf.org Sun Jun 30 07:28:39 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3198121F9425; Sun, 30 Jun 2013 07:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 UNzfziOXaVgJ; Sun, 30 Jun 2013 07:28:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 958D521F8FF3; Sun, 30 Jun 2013 07:28:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> Date: Sun, 30 Jun 2013 07:28:38 -0700 Cc: http-auth@ietf.org Subject: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 14:28:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Hypertext Transfer Protocol Authenticatio= n Working Group of the IETF. Title : An Encoding Parameter for HTTP Basic Authentication Author(s) : Julian F. Reschke Filename : draft-ietf-httpauth-basicauth-enc-01.txt Pages : 11 Date : 2013-06-30 Abstract: The "Basic" authentication scheme defined in RFC 2617 does not properly define how to treat non-ASCII characters. This has led 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 the non-ASCII characters in the ISO-8859-1 character repertoire, and even less interoperability for any characters beyond that. This document defines a backwards-compatible extension to "Basic", specifying the server's character encoding scheme expectation, using a new authentication scheme parameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-enc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-httpauth-basicauth-enc-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-httpauth-basicauth-enc-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From julian.reschke@gmx.de Sun Jun 30 07:39:53 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C1BB21F9A97 for ; Sun, 30 Jun 2013 07:39:53 -0700 (PDT) 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, 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 6dtnR8f2fQLc for ; Sun, 30 Jun 2013 07:39:48 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 83FEE21F9A94 for ; Sun, 30 Jun 2013 07:39:42 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MKffd-1UvECI278B-00216C for ; Sun, 30 Jun 2013 16:39:41 +0200 Received: (qmail invoked by alias); 30 Jun 2013 14:39:41 -0000 Received: from p5DD950FE.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.80.254] by mail.gmx.net (mp016) with SMTP; 30 Jun 2013 16:39:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+RqSw/sLKRvQOglAn4Efd+4xrNp8CeYpA0lWix9P RblL1E23bTo/ju Message-ID: <51D04326.5060600@gmx.de> Date: Sun, 30 Jun 2013 16:39:34 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: http-auth@ietf.org References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> In-Reply-To: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [http-auth] I-D Action: draft-ietf-httpauth-basicauth-enc-01.txt X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 14:39:53 -0000 On 2013-06-30 16:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Hypertext Transfer Protocol Authentication Working Group of the IETF. > ... Diffs: http://trac.tools.ietf.org/rfcdiff?url2=draft-ietf-httpauth-basicauth-enc-01.txt This draft addresses most (all?) of the feedback I received so far. It also switches to RFC 6365 compliant terminology, and changes the parameter name to "charset" for consistency with RFC 2831 (Digest in SASL). For now, there's one open issue left: we currently do not say anything about Unicode normalization forms, but we probably should. Do we want to go to WGLC with that issue still open? Best regards, Julian From paul.hoffman@vpnc.org Sun Jun 30 11:22:21 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B4221F9A13 for ; Sun, 30 Jun 2013 11:22:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePz-JkZVVWkh for ; Sun, 30 Jun 2013 11:22:20 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD1921F9A03 for ; Sun, 30 Jun 2013 11:22:20 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5UIMFvQ039646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Jun 2013 11:22:16 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D04326.5060600@gmx.de> Date: Sun, 30 Jun 2013 11:22:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.1508) Cc: http-auth@ietf.org Subject: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 18:22:21 -0000 On Jun 30, 2013, at 7:39 AM, Julian Reschke = wrote: > For now, there's one open issue left: we currently do not say anything = about Unicode normalization forms, but we probably should. -1. This has made other protocols less interoperable with little = perceptable benefit. Normalization is useful for preventing false negatives (where you want = an unnormalized string to match a normalized string because they are = "equivalent"), at the expense of one or both parties needing to have a = normalization engine that is kept up to date, covers all scripts, and so = on. At most, the spec might say "the server might want to do some = normalization if a password does not exactly match with the server's = expected value in case the client used a different set of characters to = indicate the same password", but no more. --Paul Hoffman= From derhoermi@gmx.net Sun Jun 30 11:48:00 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E9621F9BF5 for ; Sun, 30 Jun 2013 11:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2GJu+a9N+Kh for ; Sun, 30 Jun 2013 11:47:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id 339E621F9BDC for ; Sun, 30 Jun 2013 11:47:56 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.27]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LpAXC-1UGz2T3xeG-00esFf for ; Sun, 30 Jun 2013 20:47:53 +0200 Received: (qmail invoked by alias); 30 Jun 2013 18:47:53 -0000 Received: from p5B232C45.dip0.t-ipconnect.de (EHLO netb.Speedport_W_700V) [91.35.44.69] by mail.gmx.net (mp027) with SMTP; 30 Jun 2013 20:47:53 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/vZ8h8zCPvTz0TzSyY9wLX90hCDyXtbLKu98lSGg XDmFS2cH08hGnX From: Bjoern Hoehrmann To: Paul Hoffman Date: Sun, 30 Jun 2013 20:47:55 +0200 Message-ID: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 18:48:01 -0000 * Paul Hoffman wrote: >On Jun 30, 2013, at 7:39 AM, Julian Reschke wrote: > >> For now, there's one open issue left: we currently do not say anything about Unicode normalization forms, but we probably should. > >-1. This has made other protocols less interoperable with little perceptable benefit. Being able to reliably use user names and passwords with non-ASCII characters in them seems rather important to me, and considering the strings here typically come from direct human input, people will run into problems without suitable normalisation. Since the whole point of the specification is to enable reliable use of non-ASCII, I think it would be quite appropriate to put in something about that. Since servers receive all the input data, they can normalize and compare however they want, so some informative text pointing out problems to expect and possible solutions should be enough. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From yaronf.ietf@gmail.com Sun Jun 30 14:14:05 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6391721F9C6E for ; Sun, 30 Jun 2013 14:14:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm+JmvT-kCxt for ; Sun, 30 Jun 2013 14:14:04 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 9038421F9C39 for ; Sun, 30 Jun 2013 14:14:04 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id n11so3241151wgh.9 for ; Sun, 30 Jun 2013 14:14:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=0wmJyq3OEN1Bz+lOIO1w168Qf4rgUv6HRpdLbstfNRA=; b=B9o2SStrAwuybiWt/GyEFndBuh6i7puTS0W69XtF/mIuv77ojHScvyMmIdBBBoh5LD owAi52FTjwoiE20frx760xLH3QwycQXSwIKwZHFY4UOxOd0VD+CDE9QrbGqLuGcuSYla HVf0u4Hsdcs0zEtIbj2/qqm3mblyLQSBn+Jid9Icn277HZO9AGRSPvpMkRPp57LCe6It Kjp9hKTGs5TsydyAsHfyZMNyugrkyUnn5B4izZIvtmlaFL7WwPDo2YclDqTo8xUw4A35 ZZIJHXX4SMD2HFLPiDqyJbGtEbZXyy3zBXYUZ+RHteFckVnN+tpw1DzWQwm3tVtNARBC K3iA== X-Received: by 10.194.63.46 with SMTP id d14mr18304301wjs.81.1372626843738; Sun, 30 Jun 2013 14:14:03 -0700 (PDT) Received: from [10.0.0.3] ([109.64.109.19]) by mx.google.com with ESMTPSA id dv12sm10341112wic.3.2013.06.30.14.14.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 30 Jun 2013 14:14:02 -0700 (PDT) Message-ID: <51D09F98.2070508@gmail.com> Date: Mon, 01 Jul 2013 00:14:00 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Paul Hoffman References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 21:14:05 -0000 Paul, your proposed text doesn't make sense to me, because with Basic auth, the server might keep a hash of the password instead of the raw password (to reduce the damage if the entire database gets stolen). In which case I would expect the server to normalize the password before it is being hashed without any check of the "expected value". Thanks, Yaron On 2013-06-30 21:22, Paul Hoffman wrote: > On Jun 30, 2013, at 7:39 AM, Julian Reschke wrote: > >> For now, there's one open issue left: we currently do not say anything about Unicode normalization forms, but we probably should. > > -1. This has made other protocols less interoperable with little perceptable benefit. > > Normalization is useful for preventing false negatives (where you want an unnormalized string to match a normalized string because they are "equivalent"), at the expense of one or both parties needing to have a normalization engine that is kept up to date, covers all scripts, and so on. > > At most, the spec might say "the server might want to do some normalization if a password does not exactly match with the server's expected value in case the client used a different set of characters to indicate the same password", but no more. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From paul.hoffman@vpnc.org Sun Jun 30 14:35:54 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F142721F9C65 for ; Sun, 30 Jun 2013 14:35:54 -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=[AWL=0.000, 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 ORis7DE2hV-A for ; Sun, 30 Jun 2013 14:35:54 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 5410921F9C52 for ; Sun, 30 Jun 2013 14:35:54 -0700 (PDT) Received: from [10.20.30.90] (50-1-98-228.dsl.dynamic.sonic.net [50.1.98.228]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5ULZihm042950 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 30 Jun 2013 14:35:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <51D09F98.2070508@gmail.com> Date: Sun, 30 Jun 2013 14:35:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1508) Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2013 21:35:55 -0000 On Jun 30, 2013, at 2:14 PM, Yaron Sheffer = wrote: > Paul, your proposed text doesn't make sense to me, because with Basic = auth, the server might keep a hash of the password instead of the raw = password (to reduce the damage if the entire database gets stolen). In = which case I would expect the server to normalize the password before it = is being hashed without any check of the "expected value". The process that is checking for equivalence is not necessarily the = process that stored the (possibly normalized) password, and the two = processes might have different views of what normalization to use. = Normalizing takes time. Thus, I would expect that the server would do a = straight check first, and only fall back to one or more forms of string = conversion (normalization, fixing of various i18n digit forms, removing = points in Hebrew, etc.) if the first test failed. This isn't to say that your assumption is wrong, but it is not the only = one. Thus, my particularly wavy wording. --Paul Hoffman= From duerst@it.aoyama.ac.jp Sun Jun 30 22:45:34 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAC421F9EE3 for ; Sun, 30 Jun 2013 22:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, 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 R7mu5RPaV0xo for ; Sun, 30 Jun 2013 22:45:29 -0700 (PDT) Received: from scintmta01.scbb.aoyama.ac.jp (scintmta01.scbb.aoyama.ac.jp [133.2.253.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3DF21F9D8F for ; Sun, 30 Jun 2013 22:45:28 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta01.scbb.aoyama.ac.jp (secret/secret) with SMTP id r615jATo023140; Mon, 1 Jul 2013 14:45:10 +0900 Received: from (unknown [133.2.206.134]) by scmse02.scbb.aoyama.ac.jp with smtp id 30e8_07cd_64ba0cd4_e211_11e2_8023_001e6722eec2; Mon, 01 Jul 2013 14:45:10 +0900 Received: from [IPv6:::1] (unknown [133.2.210.1]) by itmail2.it.aoyama.ac.jp (Postfix) with ESMTP id 67308C0003; Mon, 1 Jul 2013 14:43:37 +0900 (JST) Message-ID: <51D1175C.3020007@it.aoyama.ac.jp> Date: Mon, 01 Jul 2013 14:45:00 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Paul Hoffman References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Julian Reschke , http-auth@ietf.org Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 05:45:35 -0000 On 2013/07/01 6:35, Paul Hoffman wrote: > On Jun 30, 2013, at 2:14 PM, Yaron Sheffer wrote: > >> Paul, your proposed text doesn't make sense to me, because with Basic auth, the server might keep a hash of the password instead of the raw password (to reduce the damage if the entire database gets stolen). In which case I would expect the server to normalize the password before it is being hashed without any check of the "expected value". > > The process that is checking for equivalence is not necessarily the process that stored the (possibly normalized) password, and the two processes might have different views of what normalization to use. That's definitely an important aspect of the problem, and should be called out. In particular, it's important to say that if you don't normalize when creating a password hash, then in the odd case that you get something half-baked (e.g. half in NFC and half in NFD,...), then it's going to be very hard to get back to the original form. > Normalizing takes time. Well, that's often brought up but not really very true or relevant. First, it's easily possible to make normalization fast. In particular, it is possible to make normalization very fast for the frequent cases. (It's also possible to make it slow, but that's true of any kind of processing.) Second, security-related calculations (hashes,...) are regularly designed so as to not be too fast. So normalization shouldn't be the bottleneck. Regards, Martin. > Thus, I would expect that the server would do a straight check first, and only fall back to one or more forms of string conversion (normalization, fixing of various i18n digit forms, removing points in Hebrew, etc.) if the first test failed. > > This isn't to say that your assumption is wrong, but it is not the only one. Thus, my particularly wavy wording. > > --Paul Hoffman > _______________________________________________ > http-auth mailing list > http-auth@ietf.org > https://www.ietf.org/mailman/listinfo/http-auth > From julian.reschke@gmx.de Sun Jun 30 23:00:11 2013 Return-Path: X-Original-To: http-auth@ietfa.amsl.com Delivered-To: http-auth@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F1F21F9CD9 for ; Sun, 30 Jun 2013 23:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.116 X-Spam-Level: X-Spam-Status: No, score=-105.116 tagged_above=-999 required=5 tests=[AWL=-2.817, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 mbfuswbPJBd2 for ; Sun, 30 Jun 2013 23:00:05 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 0E53521F9CB3 for ; Sun, 30 Jun 2013 23:00:04 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MZRZ5-1Uf1bt0Dnx-00LJFd for ; Mon, 01 Jul 2013 08:00:04 +0200 Received: (qmail invoked by alias); 01 Jul 2013 06:00:03 -0000 Received: from p5DD96C36.dip0.t-ipconnect.de (EHLO [192.168.2.117]) [93.217.108.54] by mail.gmx.net (mp031) with SMTP; 01 Jul 2013 08:00:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19xyLksXt5xsMxefA5NHRD8i5KqjjEIqldYsNRK44 BRySTJiZRS9Xgl Message-ID: <51D11AD4.5050705@gmx.de> Date: Mon, 01 Jul 2013 07:59:48 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= References: <20130630142838.31885.15315.idtracker@ietfa.amsl.com> <51D04326.5060600@gmx.de> <51D09F98.2070508@gmail.com> <51D1175C.3020007@it.aoyama.ac.jp> In-Reply-To: <51D1175C.3020007@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: http-auth@ietf.org, Paul Hoffman Subject: Re: [http-auth] Normalization forms in draft-ietf-httpauth-basicauth-enc X-BeenThere: http-auth@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: HTTP authentication methods List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 06:00:11 -0000 On 2013-07-01 07:45, "Martin J. Dürst" wrote: > > > On 2013/07/01 6:35, Paul Hoffman wrote: >> On Jun 30, 2013, at 2:14 PM, Yaron Sheffer wrote: >> >>> Paul, your proposed text doesn't make sense to me, because with Basic >>> auth, the server might keep a hash of the password instead of the raw >>> password (to reduce the damage if the entire database gets stolen). >>> In which case I would expect the server to normalize the password >>> before it is being hashed without any check of the "expected value". >> >> The process that is checking for equivalence is not necessarily the >> process that stored the (possibly normalized) password, and the two >> processes might have different views of what normalization to use. > > That's definitely an important aspect of the problem, and should be > called out. In particular, it's important to say that if you don't > normalize when creating a password hash, then in the odd case that you > get something half-baked (e.g. half in NFC and half in NFD,...), then > it's going to be very hard to get back to the original form. > >> Normalizing takes time. > > Well, that's often brought up but not really very true or relevant. > > First, it's easily possible to make normalization fast. In particular, > it is possible to make normalization very fast for the frequent cases. > (It's also possible to make it slow, but that's true of any kind of > processing.) > > Second, security-related calculations (hashes,...) are regularly > designed so as to not be too fast. So normalization shouldn't be the > bottleneck. > > Regards, Martin. So what if we mandated normalization to happen on the client? Best regards, Julian