From nobody Fri May 1 14:15:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1881A009B for ; Fri, 1 May 2015 14:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJ_rHgAup7Vn for ; Fri, 1 May 2015 14:15:05 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CE7D51A0033 for ; Fri, 1 May 2015 14:15:05 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id 8AD3D202038; Fri, 1 May 2015 14:15:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HWqXo3eeqjBPCm 0fqu1cIDm2fKI=; b=hvTDBSfeVtQbOfdOw32CaThjvg0NRZo7gsrGKUqSDnWHer /ksCuLX7w1xB8o6S1QZ5VEeF0nlRpWXiTC5EgsWAYOOoqrwEiJQMHJXElZjFqB+c FuktldiJF0hVK8eyUILexgY7QsJ71JPPXplooVoJsnqw7++dZebwI4HXirhpQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 28729202022; Fri, 1 May 2015 14:15:05 -0700 (PDT) Date: Fri, 1 May 2015 16:15:04 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150501211503.GA10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:15:06 -0000 On Tue, Apr 28, 2015 at 05:53:01PM -0400, Benjamin Kaduk wrote: > "can't tell which factor was guessed incorrectly" seems like a pretty > important property (I would be really excited to see a scheme with this > property get deployed!), but it does not seem to be mentioned in the > current section 1.2 text. (It does talk about avoiding > ciphertexts^Wpackets which are vulnerable to offline brute-force attack, > but I don't see anything mentioning the online attack as well.) Hmm, this > is mentioned in the security considerations, at least. I think it should > be more prominent earlier in the document. > > However, it seems like the text at the end of section 4.3 wherein "[i]f > validation of the second factor requires furthe round-trips, the KDC MUST > reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" loses > the indistinguishability property, as the encrypted SPAKESecondFactor > would not be generated if the long-term key (password) was incorrect. > This seems inherent to second factors which require multiple round trips > to validate, though, so maybe we have to make a choice of the tradeoff. Yes. And 4.4 makes it worse because continued 2nd factor exchanges use EncryptedData, including from the AS to the client (which can then confirm that its choice of password guess was incorrect). The fix for this is to send AS->client 2nd factor continuations in the clear if at all possible. Which means that in the AS->client 3rd and subsequent passes we need a CHOICE of OCTET STRING or EncryptedData, or perhaps allow the use of the null enctype in the AS->client 2nd factor EncryptedData. The AS will know as soon as it tries to decrypt the client's 2nd factor (whose EncryptedData functions as a proof of possession) that the client doesn't know the password. In this case the AS should continue and process _a_ 2nd factor as much as possible as if the password was right. The AS could do this by arranging to have a special user account (so as not to lock out the real user) for testing bogus second factors, and using a random or constant 2nd factor for this. Nico -- From nobody Fri May 1 14:19:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5BB1A0069 for ; Fri, 1 May 2015 14:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.012 X-Spam-Level: X-Spam-Status: No, score=-4.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 126LCghtZtEF for ; Fri, 1 May 2015 14:19:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B41F1A0033 for ; Fri, 1 May 2015 14:19:00 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id 288092BB398; Fri, 1 May 2015 21:19:00 +0000 (UTC) Received: from vpn-58-124.rdu2.redhat.com (vpn-58-124.rdu2.redhat.com [10.10.58.124]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41LIwDl006766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 17:18:59 -0400 Message-ID: <1430515138.2514.10.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Fri, 01 May 2015 17:18:58 -0400 In-Reply-To: <20150501211503.GA10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:19:02 -0000 On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote: > On Tue, Apr 28, 2015 at 05:53:01PM -0400, Benjamin Kaduk wrote: > > "can't tell which factor was guessed incorrectly" seems like a > > pretty > > important property (I would be really excited to see a scheme with > > this > > property get deployed!), but it does not seem to be mentioned in > > the > > current section 1.2 text. (It does talk about avoiding > > ciphertexts^Wpackets which are vulnerable to offline brute-force > > attack, > > but I don't see anything mentioning the online attack as well.) > > Hmm, this > > is mentioned in the security considerations, at least. I think it > > should > > be more prominent earlier in the document. > > > > However, it seems like the text at the end of section 4.3 wherein > > "[i]f > > validation of the second factor requires furthe round-trips, the > > KDC MUST > > reply to the client with KDC_ERR_MORE_PREAUTH_DATA_REQUIRED [...]" > > loses > > the indistinguishability property, as the encrypted > > SPAKESecondFactor > > would not be generated if the long-term key (password) was > > incorrect. > > This seems inherent to second factors which require multiple round > > trips > > to validate, though, so maybe we have to make a choice of the > > tradeoff. > > Yes. And 4.4 makes it worse because continued 2nd factor exchanges > use > EncryptedData, including from the AS to the client (which can then > confirm that its choice of password guess was incorrect). > > The fix for this is to send AS->client 2nd factor continuations in > the > clear if at all possible. Which means that in the AS->client 3rd and > subsequent passes we need a CHOICE of OCTET STRING or EncryptedData, > or > perhaps allow the use of the null enctype in the AS->client 2nd > factor > EncryptedData. > > The AS will know as soon as it tries to decrypt the client's 2nd > factor > (whose EncryptedData functions as a proof of possession) that the > client > doesn't know the password. In this case the AS should continue and > process _a_ 2nd factor as much as possible as if the password was > right. > The AS could do this by arranging to have a special user account (so > as > not to lock out the real user) for testing bogus second factors, and > using a random or constant 2nd factor for this. I think this is overkill. Most continuations will have already validated some aspect of the second factor. For instance, in HOTP/TOTP continuations are used for synchronization of the token after the validation of the initial token code. Nathaniel From nobody Fri May 1 14:20:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B621A009C for ; Fri, 1 May 2015 14:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZL_Mn0CPj3p for ; Fri, 1 May 2015 14:20:05 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3C31A0069 for ; Fri, 1 May 2015 14:20:05 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id D7E1B2005D90E; Fri, 1 May 2015 14:20:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=SmdmvL1YedQn4+ UYQGI2X9BnpyI=; b=uQNjKdtJlSe3uWr1wVASlIIQjj1sPdwZMsT1gdLbl1cOwa 9a/WWbU+me97W76RRVyZo8u6QJcwasFXEMuzzOLOevahsuH7adGeKtwHCTpvRKYv zG70GtTqBVefjQs/LfJt/4FS1cMW/mG9rBBfRWvN7HFQ6/f+pCnV++dDBLAOw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPA id 8A6F32005D906; Fri, 1 May 2015 14:20:04 -0700 (PDT) Date: Fri, 1 May 2015 16:20:04 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150501212003.GB10065@localhost> References: <1430138754.2682.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430138754.2682.10.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:20:05 -0000 There should be a generic OTP 2nd factor type for user-input OTPs. There should also be a generic OTP 2nd factor for plug-in/NFC-type OTPs. For a generic OTP 2nd factor for user-input OTPs the 'data' in the AS->client second pass should be a UTF8String, or just UTF-8. It's important to define such generic OTP 2nd factors because they are quite popular. Nico -- From nobody Fri May 1 14:23:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F021B2E58 for ; Fri, 1 May 2015 14:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou2MAdrFD6a4 for ; Fri, 1 May 2015 14:23:23 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id EB9DB1A01F0 for ; Fri, 1 May 2015 14:23:22 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id C808B1636; Fri, 1 May 2015 14:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=bN0OAoOaCjTaGg I189CLM51d6J4=; b=N38EOvzw+43oKXOzoTUO6zH81h1duNLWnjJJtJiRoWUYO4 q2hjTilRhKprL/yElTEZxa+JWzXKtyWTWunTN7sKHecxroGaV9w6DueP7xPd/hnB YMYLz8RUmkQWa2W+K8AyM4QkVbeI81UZDURI2VIei8N8Bhw68+Bb2XDlPM92g= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 6CCAF1612; Fri, 1 May 2015 14:23:22 -0700 (PDT) Date: Fri, 1 May 2015 16:23:21 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150501212321.GC10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430515138.2514.10.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:23:23 -0000 On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote: > On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote: > > Yes. And 4.4 makes it worse because continued 2nd factor exchanges > > use EncryptedData, including from the AS to the client (which can > > then confirm that its choice of password guess was incorrect). > > > > The fix for this is to send AS->client 2nd factor continuations in > > the clear if at all possible. Which means that in the AS->client > > 3rd and subsequent passes we need a CHOICE of OCTET STRING or > > EncryptedData, or perhaps allow the use of the null enctype in the > > AS->client 2nd factor EncryptedData. > > > > The AS will know as soon as it tries to decrypt the client's 2nd > > factor (whose EncryptedData functions as a proof of possession) that > > the client doesn't know the password. In this case the AS should > > continue and process _a_ 2nd factor as much as possible as if the > > password was right. The AS could do this by arranging to have a > > special user account (so as not to lock out the real user) for > > testing bogus second factors, and using a random or constant 2nd > > factor for this. > > I think this is overkill. Most continuations will have already > validated some aspect of the second factor. For instance, in HOTP/TOTP > continuations are used for synchronization of the token after the > validation of the initial token code. It doesn't seem like overkill to me. Unless the property that an attacker can't distinguish which factor was wrong is not that important. Note that AS implementations could just always send continuations as EncryptedData, leaking that way. What I want is for it to be possible to implement an AS that doesn't leak. Nico -- From nobody Fri May 1 14:24:08 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD38B1B2E4B for ; Fri, 1 May 2015 14:24:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUgvm0t1CnhK for ; Fri, 1 May 2015 14:24:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3502E1A00EF for ; Fri, 1 May 2015 14:24:06 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id E61CC3C227; Fri, 1 May 2015 21:24:05 +0000 (UTC) Received: from vpn-58-124.rdu2.redhat.com (vpn-58-124.rdu2.redhat.com [10.10.58.124]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41LO4fD023108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 17:24:05 -0400 Message-ID: <1430515444.2514.14.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Fri, 01 May 2015 17:24:04 -0400 In-Reply-To: <20150501212003.GB10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:24:07 -0000 On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote: > There should be a generic OTP 2nd factor type for user-input OTPs. > > There should also be a generic OTP 2nd factor for plug-in/NFC-type > OTPs. > > For a generic OTP 2nd factor for user-input OTPs the 'data' in the > AS->client second pass should be a UTF8String, or just UTF-8. > > It's important to define such generic OTP 2nd factors because they > are > quite popular. I plan to create separate standards for OATH and U2F. Nathaniel From nobody Fri May 1 14:27:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5D11A005D for ; Fri, 1 May 2015 14:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvJh2ZMyPlQE for ; Fri, 1 May 2015 14:27:06 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D938F1A0066 for ; Fri, 1 May 2015 14:27:05 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t41LR4MB011736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 17:27:04 -0400 Received: from vpn-58-124.rdu2.redhat.com (vpn-58-124.rdu2.redhat.com [10.10.58.124]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41LR3GG004843 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 17:27:04 -0400 Message-ID: <1430515623.2514.16.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Fri, 01 May 2015 17:27:03 -0400 In-Reply-To: <20150501212321.GC10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:27:07 -0000 On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote: > On Fri, May 01, 2015 at 05:18:58PM -0400, Nathaniel McCallum wrote: > > On Fri, 2015-05-01 at 16:15 -0500, Nico Williams wrote: > > > Yes. And 4.4 makes it worse because continued 2nd factor > > > exchanges > > > use EncryptedData, including from the AS to the client (which can > > > then confirm that its choice of password guess was incorrect). > > > > > > The fix for this is to send AS->client 2nd factor continuations > > > in > > > the clear if at all possible. Which means that in the AS->client > > > 3rd and subsequent passes we need a CHOICE of OCTET STRING or > > > EncryptedData, or perhaps allow the use of the null enctype in > > > the > > > AS->client 2nd factor EncryptedData. > > > > > > The AS will know as soon as it tries to decrypt the client's 2nd > > > factor (whose EncryptedData functions as a proof of possession) > > > that > > > the client doesn't know the password. In this case the AS should > > > continue and process _a_ 2nd factor as much as possible as if the > > > password was right. The AS could do this by arranging to have a > > > special user account (so as not to lock out the real user) for > > > testing bogus second factors, and using a random or constant 2nd > > > factor for this. > > > > I think this is overkill. Most continuations will have already > > validated some aspect of the second factor. For instance, in > > HOTP/TOTP > > continuations are used for synchronization of the token after the > > validation of the initial token code. > > It doesn't seem like overkill to me. Unless the property that an > attacker can't distinguish which factor was wrong is not that > important. > > Note that AS implementations could just always send continuations as > EncryptedData, leaking that way. What I want is for it to be > possible > to implement an AS that doesn't leak. I don't think that is possible. The cost for sending data in the clear to avoid leaking EncryptedData is the loss of integrity protection. Nathaniel From nobody Fri May 1 14:30:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 672AE1B2E4B for ; Fri, 1 May 2015 14:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enk5xcY9tlFz for ; Fri, 1 May 2015 14:30:57 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C1E781B29B3 for ; Fri, 1 May 2015 14:30:57 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 9C2C627BC073; Fri, 1 May 2015 14:30:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=shdvIMiw/pF4lN JDECpe4bG3eIY=; b=b8ln9W1IkRz25agHE9aPLQECqTbBb7jx+yf0xXjofKEQIR qbjievjBs0zGwX3oXh2GtkRqaseLEFWQ22+1acVkKPqI+ArZ6w+7DoQ79WJ3XP9n PHqj7hsnNswJyA2uPpeCajqBMozs11oW0P9XFOJdDwEGMXqH7zb7vVfKxAlRw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 4353F27BC069; Fri, 1 May 2015 14:30:57 -0700 (PDT) Date: Fri, 1 May 2015 16:30:56 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150501213055.GD10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430515623.2514.16.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:30:58 -0000 On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote: > On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote: > > It doesn't seem like overkill to me. Unless the property that an > > attacker can't distinguish which factor was wrong is not that > > important. > > > > Note that AS implementations could just always send continuations as > > EncryptedData, leaking that way. What I want is for it to be > > possible to implement an AS that doesn't leak. > > I don't think that is possible. The cost for sending data in the clear > to avoid leaking EncryptedData is the loss of integrity protection. Any OTPs that require continuation then result in this leak. This has to be documented, since avoiding this leak is a core feature of this protocol. Nico -- From nobody Fri May 1 14:32:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33A231A19FE for ; Fri, 1 May 2015 14:32:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZrHTlOJ85hv for ; Fri, 1 May 2015 14:32:37 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 973461A01AE for ; Fri, 1 May 2015 14:32:37 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t41LWaCN012684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 1 May 2015 17:32:36 -0400 Received: from vpn-58-124.rdu2.redhat.com (vpn-58-124.rdu2.redhat.com [10.10.58.124]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t41LWZij006145 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 17:32:35 -0400 Message-ID: <1430515954.2514.17.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Fri, 01 May 2015 17:32:34 -0400 In-Reply-To: <20150501213055.GD10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> <20150501213055.GD10065@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 21:32:39 -0000 On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote: > On Fri, May 01, 2015 at 05:27:03PM -0400, Nathaniel McCallum wrote: > > On Fri, 2015-05-01 at 16:23 -0500, Nico Williams wrote: > > > It doesn't seem like overkill to me. Unless the property that an > > > attacker can't distinguish which factor was wrong is not that > > > important. > > > > > > Note that AS implementations could just always send > > > continuations as > > > EncryptedData, leaking that way. What I want is for it to be > > > possible to implement an AS that doesn't leak. > > > > I don't think that is possible. The cost for sending data in the > > clear > > to avoid leaking EncryptedData is the loss of integrity protection. > > Any OTPs that require continuation then result in this leak. This > has > to be documented, since avoiding this leak is a core feature of this > protocol. Correct. Is the current warning insufficient? It is my understanding this is spelled out in the security considerations section. Nathaniel From nobody Fri May 1 15:23:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAA1B2E77 for ; Fri, 1 May 2015 15:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGKr5OMvpDq2 for ; Fri, 1 May 2015 15:23:05 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 849771B2E81 for ; Fri, 1 May 2015 15:23:00 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 04C221DE083; Fri, 1 May 2015 15:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Hpa0RHU3+rgMYa 6B2IEQtwM0fPE=; b=kDlo0ZjAWFYcEdYc1ziHJhU7gDrb2jYJhw/mMi04BldatS nCW4OYEW9sKg2tDq5xndkW5l0r48+Rop4fSG5Kc71BhMjSNlqah30JZRroIbzk7u Jdt/+RanPZVCag0yvYpiFHz6puivmeNVr4TO33O4RaEKXbik/1HiLYNt2O9w4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPA id 9FF911DE081; Fri, 1 May 2015 15:22:59 -0700 (PDT) Date: Fri, 1 May 2015 17:22:58 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150501222257.GE10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> <1430515444.2514.14.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430515444.2514.14.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2015 22:23:06 -0000 On Fri, May 01, 2015 at 05:24:04PM -0400, Nathaniel McCallum wrote: > On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote: > > There should be a generic OTP 2nd factor type for user-input OTPs. > > > > There should also be a generic OTP 2nd factor for plug-in/NFC-type > > OTPs. > > > > For a generic OTP 2nd factor for user-input OTPs the 'data' in the > > AS->client second pass should be a UTF8String, or just UTF-8. > > > > It's important to define such generic OTP 2nd factors because they > > are > > quite popular. > > I plan to create separate standards for OATH and U2F. Is there any reason that a generic one couldn't be specified here? Nico -- From nobody Fri May 1 19:25:02 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6041A011B for ; Fri, 1 May 2015 19:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctKkUprD8wkO for ; Fri, 1 May 2015 19:25:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 571F21A0102 for ; Fri, 1 May 2015 19:25:00 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 9813E8EA57; Sat, 2 May 2015 02:24:59 +0000 (UTC) Received: from vpn-61-171.rdu2.redhat.com (vpn-61-171.rdu2.redhat.com [10.10.61.171]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t422OwxC002574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 1 May 2015 22:24:59 -0400 Message-ID: <1430533498.2720.3.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Fri, 01 May 2015 22:24:58 -0400 In-Reply-To: <20150501222257.GE10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> <1430515444.2514.14.camel@redhat.com> <20150501222257.GE10065@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 02:25:01 -0000 On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote: > On Fri, May 01, 2015 at 05:24:04PM -0400, Nathaniel McCallum wrote: > > On Fri, 2015-05-01 at 16:20 -0500, Nico Williams wrote: > > > There should be a generic OTP 2nd factor type for user-input > > > OTPs. > > > > > > There should also be a generic OTP 2nd factor for plug-in/NFC > > > -type > > > OTPs. > > > > > > For a generic OTP 2nd factor for user-input OTPs the 'data' in > > > the > > > AS->client second pass should be a UTF8String, or just UTF-8. > > > > > > It's important to define such generic OTP 2nd factors because > > > they > > > are > > > quite popular. > > > > I plan to create separate standards for OATH and U2F. > > Is there any reason that a generic one couldn't be specified here? Speaking for myself, I want to create a high-quality integrated experience, not a generic one. I would prefer picking one open standard (such as OATH) and getting the details right. This is somewhat hard for me to quantify, but it arises from my experience implementing RFC 6560. Nathaniel From nobody Fri May 1 19:58:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653A61A016B for ; Fri, 1 May 2015 19:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvu8UYf5FpFl for ; Fri, 1 May 2015 19:58:06 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4E25C1A0155 for ; Fri, 1 May 2015 19:58:06 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AA79F4E5F1 for ; Fri, 1 May 2015 22:58:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:mime-version:content-type:date:message-id; s=sasl; bh=lfrJ0goAKCeWFWZR25e1RADDVVs=; b=l6R1QfHoKOCEV3ZUjoV2 VHylAYH8ohIO+O3K03BN+oSvTmyjX4oq/yTxsG4N0z9JQOf07wg10o/bLzYwmZro YxfrfK8JXFshODKsOKmzs1Afw3HEEQwwjJw6Up/M8hzTGS4hBQR9BD4ILDTpkXW3 M0vPWWGxYySYksR4PJ0mjlg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:mime-version:content-type:date:message-id; q=dns; s=sasl; b=NZz09LwhpyA0d+qjS5W8h24cquufcdl+BadmwK0qsR/91vL1fdkud Nn/2ax3Ufwr/i4+hfvrHOBghsjSxaeDAyPFI47tu+s8ANINXH4GSGKHMblpGi4EQ 8ifCXopdeyNgLRtw4nheeLbt2Gq/gShsVIGLQ4ah0ZvgaPv2MSL2CY= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A41394E5EF for ; Fri, 1 May 2015 22:58:05 -0400 (EDT) Received: from pendragon.internal (unknown [96.255.161.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 5970B4E5ED for ; Fri, 1 May 2015 22:58:05 -0400 (EDT) From: Ken Hornstein To: In-Reply-To: <1430533498.2720.3.camel@redhat.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 01 May 2015 22:58:04 -0400 X-Pobox-Relay-ID: 0DF49376-F077-11E4-99D8-83E09F42C9D4-90216062!pb-smtp1.pobox.com Message-Id: <20150502025805.A41394E5EF@pb-smtp1.pobox.com> Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 02:58:09 -0000 >Speaking for myself, I want to create a high-quality integrated >experience, not a generic one. I would prefer picking one open >standard (such as OATH) and getting the details right. This is >somewhat hard for me to quantify, but it arises from my experience >implementing RFC 6560. So ... I hate to ask this, but does this mean KITTEN is coming around to officially deciding that OTP in Kerberos should _not_ use FAST? I will fully admit that I've been out of the Kerberos game for a while, but seeing Nathan's description of the challenges with deploying FAST makes me realize that I'd run into the exact same problems ... and that makes me think that a FAST-based OTP would probably be very challenging if you had a diverse Kerberos deployment. And I simply wouldn't bother deploying both FAST and SPAKE; I'd just pick one to make things easier. --Ken From nobody Sat May 2 11:15:36 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796721A8A96 for ; Sat, 2 May 2015 11:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D19xSgam1_wj for ; Sat, 2 May 2015 11:15:34 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAD61A8A95 for ; Sat, 2 May 2015 11:15:33 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-b7-554514435147 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 79.6B.03488.34415455; Sat, 2 May 2015 14:15:31 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t42IFVh8011199; Sat, 2 May 2015 14:15:31 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t42IFSKr022033 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 May 2015 14:15:30 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t42IFSIl010018; Sat, 2 May 2015 14:15:28 -0400 (EDT) Date: Sat, 2 May 2015 14:15:28 -0400 (EDT) From: Benjamin Kaduk To: Nathaniel McCallum In-Reply-To: <1430515954.2514.17.camel@redhat.com> Message-ID: References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> <20150501213055.GD10065@localhost> <1430515954.2514.17.camel@redhat.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hTV1nUWcQ01mLHG3OLo5lUsFqeuHWGz mPt1FqsDs8fLU+cYPZYs+cnk8X7fVbYA5igum5TUnMyy1CJ9uwSujE8nrzMWfGKtWHDhPVMD 4x2WLkYODgkBE4m7T/K7GDmBTDGJC/fWs3UxcnEICSxmkvi9+xWUs4FR4n/zXVYI5yCTxOKm JiaQFiGBeolNn/eC2SwCWhInt05jBrHZBFQkZr7ZyAZiiwjoSSzbN4ERxGYW8JN4e+o8WFxY QFni7KtT7CA2p4CRxLSuJ2BzeAUcJTov9jFDLHvMJPH28DOwZlEBHYnV+6ewQBQJSpyc+YQF YqiWxPLp21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6RXm5miV5qSukm RnD4SvLuYHx3UOkQowAHoxIP7wctl1Ah1sSy4srcQ4ySHExKorx3/wKF+JLyUyozEosz4otK c1KLDzFKcDArifB2M7uGCvGmJFZWpRblw6SkOViUxHk3/eALERJITyxJzU5NLUgtgsnKcHAo SfCaCQM1ChalpqdWpGXmlCCkmTg4QYbzAA2PB6nhLS5IzC3OTIfIn2LU5bgz5f8iJiGWvPy8 VClx3gSQIgGQoozSPLg5sLTzilEc6C1h3k6QKh5gyoKb9ApoCRPQkgP1LiBLShIRUlINjPVF HernJd8vldXj22Xy6/jeiNDVvaFf/X/f5KtPzqzaGn7lze64NIszz2UObfz7Resgo7Sa0b9N /HPuLv6Wyan56uuLrtXTxCV/P6qZeF0j5nDuPr/IXV+tDG/FHmYR5Pu/ZavXsoTFZ7gmbtpc dPve728JzxZsnBno6bnDvfCQ5DmpmQ5109mVWIozEg21mIuKEwGubmQPFgMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 18:15:35 -0000 On Fri, 1 May 2015, Nathaniel McCallum wrote: > On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote: > > > > Any OTPs that require continuation then result in this leak. This > > has > > to be documented, since avoiding this leak is a core feature of this > > protocol. > > Correct. Is the current warning insufficient? It is my understanding > this is spelled out in the security considerations section. I think I already mentioned this in my earlier comments, but I think that mentioning more prominently in the introduction the goal of not leaking which factor was incorrect, with the caveat about continuation messages losing this property, would be an improvement to just mentioning it in the security considerations. -Ben From nobody Sat May 2 14:59:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3BD1A90C5 for ; Sat, 2 May 2015 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5QsWXINgIKB for ; Sat, 2 May 2015 14:59:28 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 128871A90B7 for ; Sat, 2 May 2015 14:59:12 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-5c-554548b04255 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 8C.08.03451.0B845455; Sat, 2 May 2015 17:59:12 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t42LxB2f027363; Sat, 2 May 2015 17:59:11 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t42Lx96r011108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 2 May 2015 17:59:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t42Lx9ic007991; Sat, 2 May 2015 17:59:09 -0400 (EDT) Date: Sat, 2 May 2015 17:59:08 -0400 (EDT) From: Benjamin Kaduk To: Ken Hornstein In-Reply-To: <20150502025805.A41394E5EF@pb-smtp1.pobox.com> Message-ID: References: <20150502025805.A41394E5EF@pb-smtp1.pobox.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrbvBwzXU4Md2Lov+puMsFkc3r2Jx YPJYsuQnk8fFS8oBTFFcNimpOZllqUX6dglcGXv29zAXPOWo6Pgxh7WBsZG9i5GTQ0LARKL/ /XtmCFtM4sK99WxdjFwcQgKLmSRmrd/CBOFsYJR4dW4hC4RzkEli4sdNYC1CAvUSjUdOs4HY LAJaEs8714HF2QRUJGa+2QgU5+AQEVCSOHNOAiTMLCAssf7cDLASYQFlibOvToFdwSlgLTH5 5RwWEJtXwFHiUl8rC8R4K4kHTUtYQWxRAR2J1funQNUISpyc+YQFYqaWxPLp21gmMArOQpKa hSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6pXm5miV5qSukmRlCYsrso7WD8eVDpEKMA B6MSD+8HLZdQIdbEsuLK3EOMkhxMSqK8d/8ChfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwcku7 hgrxpiRWVqUW5cOkpDlYlMR5N/3gCxESSE8sSc1OTS1ILYLJynBwKEnwrnYHahQsSk1PrUjL zClBSDNxcIIM5wEa7ghSw1tckJhbnJkOkT/FqCglzvsEJCEAksgozYPrhaWRV4ziQK8I854F qeIBpiC47ldAg5mABh+odwEZXJKIkJJqYAx8r8z+pjb9xqzOgsiYWOs68ZyTZvpTZx4OmTeD y/OPzom64JOaU34ZWGUk7s5P1udIUbNp+xY423qu/tTCZw/LH0W0Jc6p1om7lx9376/Y9/y9 TJbX4kuKy3Qen9/p/lvnMrP18uKbu7wi8puLvf/V9fxJ3udzrvZ6unigRcHE5/Ii5RYiSizF GYmGWsxFxYkAV07DP/4CAAA= Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 21:59:29 -0000 On Fri, 1 May 2015, Ken Hornstein wrote: > >Speaking for myself, I want to create a high-quality integrated > >experience, not a generic one. I would prefer picking one open > >standard (such as OATH) and getting the details right. This is > >somewhat hard for me to quantify, but it arises from my experience > >implementing RFC 6560. > > So ... I hate to ask this, but does this mean KITTEN is coming around > to officially deciding that OTP in Kerberos should _not_ use FAST? I > will fully admit that I've been out of the Kerberos game for a while, > but seeing Nathan's description of the challenges with deploying FAST > makes me realize that I'd run into the exact same problems ... and that > makes me think that a FAST-based OTP would probably be very challenging > if you had a diverse Kerberos deployment. And I simply wouldn't bother > deploying both FAST and SPAKE; I'd just pick one to make things easier. Essentially, the answer is different whether OTP is supposed to be the first (and only) authentication factor, or a second factor to be used in conjunction with a password. -Ben From nobody Sat May 2 16:09:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D40B51A9112 for ; Sat, 2 May 2015 16:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAY241ma32WL for ; Sat, 2 May 2015 16:08:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 291861A9110 for ; Sat, 2 May 2015 16:08:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id A3BE759406B; Sat, 2 May 2015 16:08:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=z8fU89K3Vu0Ttu 3m7lRZ0amT+vU=; b=cQOulwngNU8fiaOrP3WI/7j+K+N48sliXBCbvgvOAPTALE qSikYwvugD1d0TohNUkNag+1udFrHAOjr+ssgNzxpNZ0+U2Dl/knM2/R+TpO5Kb+ AZJ3HTOTpk6yHseyQBm5E/SC1SLP2CH1evfDq1Gp92Sv66/KdRS7WU+VC3Rt4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id 5B9D6594057; Sat, 2 May 2015 16:08:58 -0700 (PDT) Date: Sat, 2 May 2015 18:08:57 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150502230856.GF10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> <1430515444.2514.14.camel@redhat.com> <20150501222257.GE10065@localhost> <1430533498.2720.3.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430533498.2720.3.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 23:09:00 -0000 On Fri, May 01, 2015 at 10:24:58PM -0400, Nathaniel McCallum wrote: > On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote: > > Is there any reason that a generic one couldn't be specified here? > > Speaking for myself, I want to create a high-quality integrated > experience, not a generic one. I would prefer picking one open > standard (such as OATH) and getting the details right. This is > somewhat hard for me to quantify, but it arises from my experience > implementing RFC 6560. I don't buy this. I understand and agree about how a dependency on _FAST_ made RFC6560 difficult to deploy, and also how RFC6560's incomplete/missing handling of *multiple* factors made it less useful than expected. I don't think that means "generality -> bad". Also, I don't think a generic OTP 2nd factor here would necessarily lead to a low-quality user experience. For all user-input OTPs, all the user needs is a prompt, which can be sent in UTF-8 and already localized to a language of the user's preference (since the AS ought to know what that might be). I don't see how the user-input OTP experience can get much better than that. I suppose one could add media (a vine showing the act of pulling the OTP out of one's pocket or purse, reading the OTP, then entering it on a keyboard? an audio description of the same?), but text is quite accessible. Nico -- From nobody Sat May 2 16:16:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9387A1A9125 for ; Sat, 2 May 2015 16:16:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.634 X-Spam-Level: * X-Spam-Status: No, score=1.634 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xKcfHGaIO7mq for ; Sat, 2 May 2015 16:16:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id E0E511A8FD5 for ; Sat, 2 May 2015 16:16:07 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id 90CA5B805B; Sat, 2 May 2015 16:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=ee/yCi6s4+KN8r vL2lC2Efwnx+o=; b=KNyVv4tk+D0ziGr6vZkco4FbbKDYyYhmcL1G9A2YoWdrVM E6e9psVvrD1RuRBMuXc8PftbFVz+NX38bWCAntF4EBs93ZgxunEsHaW92D8B9PCn 5el1Vyy88RW9a4FuSl59fYOdHY7IfkxX/5vTJfdQKS9/qV91iysn9ySeQyhC8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 5DA04B8058; Sat, 2 May 2015 16:16:07 -0700 (PDT) Date: Sat, 2 May 2015 18:16:04 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150502231603.GG10065@localhost> References: <1430138754.2682.10.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430138754.2682.10.camel@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 23:16:08 -0000 In addition to adding some standard OTP-ish second factors, I'd like to have a way to "augment" the PAKE with the same user password so as to improve resistance to KDC database compromise. For example, if we had a password->signature key algorithm then we could have a second factor that consists of a signature of the AS' and user's PAKE public keys (say; handwaving a bit)m and then the AS ends up storing w (from the PAKE) and the public key for the signature. If we salt the password differently to derive w and the siging key, then the AS ends up storing not a password equivalent, but a password verifier. That makes KDB compromise somewhat less bad than today, since attackers would have to mount off-line dictionary attacks, giving realm operators more time to have users change their passwords. (Service keys remain a problem, but that can be addressed too, separately.) But augmenting the PAKE this way means we may need to use two second factors: one to augment the PAKE, and one that's the actual OTP-ish second factor. That will require some tweaking of the proposed protocol. Nico -- From nobody Sat May 2 16:24:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308B51A913B for ; Sat, 2 May 2015 16:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsZjYvN2ZUt7 for ; Sat, 2 May 2015 16:24:37 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 75FBF1A9138 for ; Sat, 2 May 2015 16:24:37 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 581802005D005; Sat, 2 May 2015 16:24:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=yGAdQfTJPHqMED 0O0WMjogC9P/w=; b=QqJQlICZodS6xDIRjRi9fsDjZUgfv/8v2wh0uFwUADY/1d 0YovMKYo681TobIzlIUDwG+XA6fwslboTZUAYW3/SOzxWsAWYi1BPMHluWMH0ut7 U/FFjE2e637aoLd2i+8x6WKcOQ9F5LDZJU7jiYpMvktAjjoZsT6soj4mvehAA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPA id EE2AB2005D004; Sat, 2 May 2015 16:24:36 -0700 (PDT) Date: Sat, 2 May 2015 18:24:36 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20150502232435.GH10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <553FA2B3.8030301@mit.edu> <20150501211503.GA10065@localhost> <1430515138.2514.10.camel@redhat.com> <20150501212321.GC10065@localhost> <1430515623.2514.16.camel@redhat.com> <20150501213055.GD10065@localhost> <1430515954.2514.17.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2015 23:24:38 -0000 On Sat, May 02, 2015 at 02:15:28PM -0400, Benjamin Kaduk wrote: > On Fri, 1 May 2015, Nathaniel McCallum wrote: > > > On Fri, 2015-05-01 at 16:30 -0500, Nico Williams wrote: > > > > > > Any OTPs that require continuation then result in this leak. This > > > has > > > to be documented, since avoiding this leak is a core feature of this > > > protocol. > > > > Correct. Is the current warning insufficient? It is my understanding > > this is spelled out in the security considerations section. > > I think I already mentioned this in my earlier comments, but I think that > mentioning more prominently in the introduction the goal of not leaking > which factor was incorrect, with the caveat about continuation messages > losing this property, would be an improvement to just mentioning it in the > security considerations. Agreed, but I also wonder if there might be second factor types where the AS->client continuations could be sent with no protection and still be secure. Consider an OTP resync use case where the client gets asked to send N more OTPs. The AS stores N (then N-1, N-2, .., N==1) in the state cookie, while the client binds all the resync requests (and response OTPs) into the transcript, so the AS can't be tricked into taking more OTPs than it needs, and the resync doesn't hurst the client, leaking nothing to the attacker. Granted, this analysis has to be done on a per-second factor type basis. Perhaps we don't or shouldn't care. But if this failure cause indistinguishability feature is critical, then maybe we should care. Nico -- From nobody Sun May 3 08:16:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4121A6EF9 for ; Sun, 3 May 2015 08:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03P2zraJeQxY for ; Sun, 3 May 2015 08:16:53 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BF611A6EF4 for ; Sun, 3 May 2015 08:16:52 -0700 (PDT) X-AuditID: 1209190f-f79d16d000000d3d-8c-55463be3e49e Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 7D.AA.03389.3EB36455; Sun, 3 May 2015 11:16:51 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t43FGojM005172 for ; Sun, 3 May 2015 11:16:51 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t43FGn1I023414 for ; Sun, 3 May 2015 11:16:50 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sun, 03 May 2015 11:16:49 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixG6novvY2i3U4P08CYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY0HXZqaCiWIV05ZsY2xgbBLqYuTkkBAwkdj44wg7hC0mceHe erYuRi4OIYHFTBKHOmezQjjHGCUOHPjCBOG0M0k0HD3ABtLCJqAssX7/VhYQW0RAWGL31nfM ILawgJbE4wXTwGpYBFQl+hqfAtkcHLwChhI7V9qDhHkFBCVOznwC1sosICFx8MUL5gmMPLOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRFByckvw7GL8dVDrE KMDBqMTD+yPWNVSINbGsuDL3EKMkB5OSKG/iIqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEV4V HbdQId6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCV5nYBQICRalpqdW pGXmlCCkmTg4QYbzAA3XB6nhLS5IzC3OTIfIn2JUlBLnTQVJCIAkMkrz4Hph0fuKURzoFWHe jVZAVTzAyIfrfgU0mAlo8IF6F5DBJYkIKakGRhu++ldSzJr5Uap/fh18uVD75euaaUJOdQf6 HGx+z3Up95+waKXg/jaPWYeMN0yf4qonrzrxMKO3i5+ioMCKS5mpfed3iW6/N8XT0KnjM9Nd IWud8HSRms5p53/16nW5NDiZ3DPJlKpr//sosSnrzKY9H284Gf2Tm7l92Zfzk20jXLez/bj6 Q4mlOCPRUIu5qDgRAAMRwSK5AgAA Archived-At: Subject: [kitten] RFC 3961 key-derivation operation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 15:16:55 -0000 RFC 3961 defines an abstract interface for an encryption algorithm profile (colloquially known as an enctype) and a checksum algorithm profile. It also defines a "simplified profile," which can be used to construct an enctype from a block cipher and hash, and several specific enctypes and checksum profiles. The operations specified in sections 3 and 4 are visible to consumers such as RFC 4120 and AFS, while other sections define internal details of specific enctypes and cksumtypes. I was recently surprised to notice that section 3 includes a key-derivation operation, (protocol-key, integer)->(specific-key). I had previously assumed that key derivation was an internal detail of enctypes, aside from the requirement that consumers provide a key usage number for each encryption and checksum operation. The presence of a key-derivation operation in section 3 suggests that a consumer could invoke the key-derivation operation explicitly. I don't think any Kerberos specification does this. I'm not sure there is any reason to do so other than to directly use the bits of the specific-key, and the PRF operation is probably more suited to that kind of use. Things only get more confusing as one looks into this further: * Section 2 says "The specific key should not be explicitly referenced outside of this document." So why does a public enctype operation produce a specific-key output? * Section 5.3, which defines the transformation from simplified profile to enctype, specifies a key-derivation function which does not meet the abstract form of the key-derivation. It picks a byte depending on whether Kc, Ke, or Ki is being derived. Note that section 3 states "no additional or implicit inputs... are permitted." * RFC 4757 does not explicitly define a key-derivation operation, although it of course uses key derivation internally. * RFC 6803 mirrors RFC 3961 section 5.3 in defining a key-derivation function which does not fit the form of RFC 3961 section 3. MIT krb5 does not provide a public interface for key derivation. Heimdal provides a krb5_derive_key() function which accepts a byte-string input instead of an integer, and implements the simplified-profile key derivation function; it appears to return an error for a key of any enctype other than DES3 or the AES-SHA1s. I think the best conclusion is that RFC 3961 section 3 was mistaken to include a key-derivation operation, and that future enctype specifications should not that operation as part of their enctype profiles. They should, of course, continue to use key derivation internally, using the consumer-provided key usage number. Do others agree? Should we file an erratum? This has an impact on the aes-sha2 spec (as a matter of form, not function, of course). From nobody Sun May 3 15:32:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC771A8A59 for ; Sun, 3 May 2015 15:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.013 X-Spam-Level: X-Spam-Status: No, score=-5.013 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhSLUpj_EOdC for ; Sun, 3 May 2015 15:32:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B08DD1A00B0 for ; Sun, 3 May 2015 15:32:46 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 042A08E795; Sun, 3 May 2015 22:32:45 +0000 (UTC) Received: from [10.3.113.107] (ovpn-113-107.phx2.redhat.com [10.3.113.107]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t43MWieT028522; Sun, 3 May 2015 18:32:45 -0400 Message-ID: <1430692364.916.58.camel@willson.usersys.redhat.com> From: Simo Sorce To: Nico Williams Date: Sun, 03 May 2015 18:32:44 -0400 In-Reply-To: <20150502230856.GF10065@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> <1430515444.2514.14.camel@redhat.com> <20150501222257.GE10065@localhost> <1430533498.2720.3.camel@redhat.com> <20150502230856.GF10065@localhost> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 May 2015 22:32:48 -0000 On Sat, 2015-05-02 at 18:08 -0500, Nico Williams wrote: > On Fri, May 01, 2015 at 10:24:58PM -0400, Nathaniel McCallum wrote: > > On Fri, 2015-05-01 at 17:22 -0500, Nico Williams wrote: > > > Is there any reason that a generic one couldn't be specified here? > > > > Speaking for myself, I want to create a high-quality integrated > > experience, not a generic one. I would prefer picking one open > > standard (such as OATH) and getting the details right. This is > > somewhat hard for me to quantify, but it arises from my experience > > implementing RFC 6560. > > I don't buy this. I understand and agree about how a dependency on > _FAST_ made RFC6560 difficult to deploy, and also how RFC6560's > incomplete/missing handling of *multiple* factors made it less useful > than expected. I don't think that means "generality -> bad". > > Also, I don't think a generic OTP 2nd factor here would necessarily lead > to a low-quality user experience. For all user-input OTPs, all the user > needs is a prompt, which can be sent in UTF-8 and already localized to > a language of the user's preference (since the AS ought to know what > that might be). I don't see how the user-input OTP experience can get > much better than that. I think we explicitly exclude sending unauthenticated prompts from the KDC, as it would be easy to confuse/subvert the user experience by an attacker. Because the prompts would have to be sent unauthenticated in the SPAKE algorithm we'd have to define either generic, unhelpful prompts, or define specific OTP mechanisms so that clients have prompts backed in and just reference them by id internally. > I suppose one could add media (a vine showing the act of pulling the OTP > out of one's pocket or purse, reading the OTP, then entering it on a > keyboard? an audio description of the same?), but text is quite > accessible. See above, a generic OTP would have to rely on no text coming from the KDC. Simo. -- Simo Sorce * Red Hat, Inc * New York From nobody Sun May 3 18:04:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C91A92BC for ; Sun, 3 May 2015 18:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKukVWJWY89l for ; Sun, 3 May 2015 18:04:29 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2661A92B9 for ; Sun, 3 May 2015 18:04:29 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 398B42005E61A; Sun, 3 May 2015 18:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=K99taFHkRB2D/n 4MQGV/61GDj3I=; b=TreD5+bBpZ54M1wDt6qJpkSBklCRsfQfb2syqkxYzUUNr8 jVHUQWhvVtc7YQc8LBbnCuBtEJB06OXG5KeYGM95NmJz7QVRShwy0ie5i1WSdJvm Kf29ZlK0TXrkNA93dF3mivMNe8jGiQ3a7GW9gSg3n0whKYNMTa8Pyz5DsUkFQ= Received: from localhost (ip-64-134-47-45.public.wayport.net [64.134.47.45]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id CC5D22005E605; Sun, 3 May 2015 18:04:28 -0700 (PDT) Date: Sun, 3 May 2015 20:04:28 -0500 From: Nico Williams To: Simo Sorce Message-ID: <20150504010427.GC7287@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150501212003.GB10065@localhost> <1430515444.2514.14.camel@redhat.com> <20150501222257.GE10065@localhost> <1430533498.2720.3.camel@redhat.com> <20150502230856.GF10065@localhost> <1430692364.916.58.camel@willson.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1430692364.916.58.camel@willson.usersys.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 01:04:30 -0000 On Sun, May 03, 2015 at 06:32:44PM -0400, Simo Sorce wrote: > On Sat, 2015-05-02 at 18:08 -0500, Nico Williams wrote: > > I don't buy this. I understand and agree about how a dependency on > > _FAST_ made RFC6560 difficult to deploy, and also how RFC6560's > > incomplete/missing handling of *multiple* factors made it less useful > > than expected. I don't think that means "generality -> bad". > > > > Also, I don't think a generic OTP 2nd factor here would necessarily lead > > to a low-quality user experience. For all user-input OTPs, all the user > > needs is a prompt, which can be sent in UTF-8 and already localized to > > a language of the user's preference (since the AS ought to know what > > that might be). I don't see how the user-input OTP experience can get > > much better than that. > > I think we explicitly exclude sending unauthenticated prompts from the > KDC, as it would be easy to confuse/subvert the user experience by an > attacker. > > Because the prompts would have to be sent unauthenticated in the SPAKE > algorithm we'd have to define either generic, unhelpful prompts, or > define specific OTP mechanisms so that clients have prompts backed in > and just reference them by id internally. Ah, I see. OK, thanks. Nico -- From nobody Mon May 4 05:48:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C0B1A005F for ; Mon, 4 May 2015 05:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 68xNSdvg2F6Z for ; Mon, 4 May 2015 05:48:55 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CF91A0069 for ; Mon, 4 May 2015 05:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 0054E2070F; Mon, 4 May 2015 08:47:35 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r7gVGkfP4at; Mon, 4 May 2015 08:47:35 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 May 2015 08:47:34 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AB57C82158; Mon, 4 May 2015 08:48:41 -0400 (EDT) From: Sam Hartman To: Benjamin Kaduk References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> Date: Mon, 04 May 2015 08:48:41 -0400 In-Reply-To: (Benjamin Kaduk's message of "Wed, 29 Apr 2015 16:25:00 -0400 (EDT)") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 12:48:56 -0000 I think it is entirely reasonably to ask all clients to send a freshness request. From nobody Mon May 4 07:40:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3545C1A1A91 for ; Mon, 4 May 2015 07:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6ZPWwVnZxRS for ; Mon, 4 May 2015 07:40:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 48DF41A1A8C for ; Mon, 4 May 2015 07:40:07 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B72284D3E6 for ; Mon, 4 May 2015 10:40:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:mime-version:content-type:date:message-id; s=sasl; bh=nev9BXEpFdgGyMOX9XJ861kGAlk=; b=vH8YKHT9css1VzHEzJcI OgyaPAQtthm1goADbYgfDSpmMC5svrA2WF7sMbbchoc0GV2YOoUzgddbyvD0JkzQ Xm/YyOZ/0dwgaFs7GwZh/qg1cO8Ai0A2et4NqaqTr4fbsFT/M1QuLlz13rEBQ/VL zKIPcE4rQ877UIB+If0FJkQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:mime-version:content-type:date:message-id; q=dns; s=sasl; b=e4NtnsqqJI4G+eHG3ngDKaNIaBTQdly1+FRNBO2FxdQBIjXXPjCmh moOBESqiFNuodIxc+xlg03iyptqhqEGwseP/LFWDXltp2ymFhS3CdPfCzlbZ6ByF 0ZHg4PHIUoAOJR8ji1D3GeAkMjAy6zvKG/HBJWw6JNfAGW3MlUez/Y= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AFB1A4D3E1 for ; Mon, 4 May 2015 10:40:05 -0400 (EDT) Received: from zoolander.cmf.nrl.navy.mil (unknown [134.207.12.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 4CC1B4D3DF for ; Mon, 4 May 2015 10:40:05 -0400 (EDT) From: Ken Hornstein To: kitten@ietf.org In-Reply-To: X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 May 2015 10:40:59 -0400 X-Pobox-Relay-ID: 743A3F00-F26B-11E4-B236-83E09F42C9D4-90216062!pb-smtp1.pobox.com Message-Id: <20150504144005.AFB1A4D3E1@pb-smtp1.pobox.com> Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 14:40:08 -0000 >Essentially, the answer is different whether OTP is supposed to be the >first (and only) authentication factor, or a second factor to be used in >conjunction with a password. See, I think you've got the question all wrong. My question is NOT, "Is OTP supposed to be the only authentication factor?", it's, "Which protocol is it actually possible for me to deploy successfully?" --Ken From nobody Mon May 4 08:12:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1152B1A1BCF for ; Mon, 4 May 2015 08:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCELrWgcf5MQ for ; Mon, 4 May 2015 08:12:57 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6FD81A1BCD for ; Mon, 4 May 2015 08:12:43 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-98-55478c6a69a6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 90.35.03493.A6C87455; Mon, 4 May 2015 11:12:42 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t44FCaX1021611; Mon, 4 May 2015 11:12:37 -0400 Received: from [18.101.8.98] (vpn-18-101-8-98.mit.edu [18.101.8.98]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t44FCY4I016706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 May 2015 11:12:35 -0400 Message-ID: <55478C61.2040601@mit.edu> Date: Mon, 04 May 2015 11:12:33 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sam Hartman , Benjamin Kaduk References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT183qcQ81OP3WzOJr2wM2i6ObV7FY /Ovmc2D2WLLkJ5NH646/7B4rp55mD2CO4rJJSc3JLEst0rdL4Mr4vfAIW8F/lopl/9uYGxhb WLoYOTkkBEwkjt1bwAhhi0lcuLeerYuRi0NIYDGTxPrvV1ghnA2MEtcfzWaGcA4wSax4dYQV pIVXQE2i8/AqIJuDg0VAVWJFiytImE1AWWL9/q1gG0QFwiSm/X4OVS4ocXLmE7C4iIC7xMFX Z5hAbGaBCIl/B6aygIwRFvCWeL1GF2LVWxaJXVd7wXo5gVbdXPeNGaJeT2LH9V+sELa8xPa3 c5gnMArOQrJiFpKyWUjKFjAyr2KUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgO aReVHYzNh5QOMQpwMCrx8J5c5RYqxJpYVlyZe4hRkoNJSZTXIsU9VIgvKT+lMiOxOCO+qDQn tfgQowQHs5IIL0cLUI43JbGyKrUoHyYlzcGiJM676QdfiJBAemJJanZqakFqEUxWhoNDSYI3 uxuoUbAoNT21Ii0zpwQhzcTBCTKcB2i4LEgNb3FBYm5xZjpE/hSjLsedKf8XMQmx5OXnpUqJ 8/qCFAmAFGWU5sHNgaWiV4ziQG8J804GqeIBpjG4Sa+AljABLTlQ7wKypCQRISXVwBiU+fGm kzO7Tnh27EV5t/+3o1malU+8rIlWCFbWcvFRyhL2rMsytA8/HVq7UXpCo4B0b+S5fdFN33bN OSPulCP78nj4taaIMNfJE9murkn/NMtW48YmG61L79JTLUJu/5LxtH+5y0ju/uZ4a3aG86r9 6rnvIlQVPR9+rvQ0f7M9YU3GmhRjJZbijERDLeai4kQAXEa2BiADAAA= Archived-At: Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 15:12:58 -0000 On 05/04/2015 08:48 AM, Sam Hartman wrote: > I think it is entirely reasonably to ask all clients to send a freshness > request. I think it's a little unfortunate, but if it will make Microsoft's life easier, an few extra bytes in each AS request won't break the world. MIT krb5 clients will probably send the freshness request unconditionally, since our preauth framework doesn't make it easy to determine ahead of time whether the client can do authenticated PKINIT. We'll need to be prepared to retry without it because of older MIT krb5 KDCs, but we already have logic for that because of PA-REQ-ENC-PA-REP (RFC 6806). From nobody Mon May 4 08:25:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C9F1A1EF3 for ; Mon, 4 May 2015 08:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.91 X-Spam-Level: X-Spam-Status: No, score=-5.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9CCRXE8lIih for ; Mon, 4 May 2015 08:25:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E45E61A1BDD for ; Mon, 4 May 2015 08:25:51 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 984C98F024; Mon, 4 May 2015 15:25:51 +0000 (UTC) Received: from vpn-57-206.rdu2.redhat.com (vpn-57-206.rdu2.redhat.com [10.10.57.206]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t44FPoqa001692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 May 2015 11:25:51 -0400 Message-ID: <1430753150.2798.13.camel@redhat.com> From: Nathaniel McCallum To: Ken Hornstein Date: Mon, 04 May 2015 11:25:50 -0400 In-Reply-To: <20150504144005.AFB1A4D3E1@pb-smtp1.pobox.com> References: <20150504144005.AFB1A4D3E1@pb-smtp1.pobox.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 15:25:53 -0000 On Mon, 2015-05-04 at 10:40 -0400, Ken Hornstein wrote: > > Essentially, the answer is different whether OTP is supposed to be > > the > > first (and only) authentication factor, or a second factor to be > > used in > > conjunction with a password. > > See, I think you've got the question all wrong. My question is NOT, > "Is OTP supposed to be the only authentication factor?", it's, "Which > protocol is it actually possible for me to deploy successfully?" I believe the tension you are seeing here is the result of commoditization of 2FA. Early on, 2FA systems were entirely parallel authentication stacks which authenticators would need to integrate with. As 2FA commoditized, we see open protocols which can be integrated into existing authentication stacks. Pre-commiditized 2FA is the context of RFC 6560. There is no attempt here to use the existing 1FA infrastructure of Kerberos. RFC 6560 is just a fancy method for passing credentials in cleartext through Kerberos protected by FAST. The KDC then passes these credentials directly to the parallel authentication stack. It is the HTTPS Basic Auth of the Kerberos world. However, after 2FA commoditized the question becomes how can I augment my existing authentication stack (1FA Kerberos) with a 2FA method. This is what SPAKE Preauth provides. Now, I think your questions here raise an interesting point: can and should we require some standardization to use the 2FA feature of SPAKE preauth? I think the answer is no. And I've come to think that the SPAKESecondFactor type field should really be OBJECT IDENTIFIER. Nathaniel From nobody Mon May 4 08:31:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB421A7022 for ; Mon, 4 May 2015 08:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7GfL79WgLxw for ; Mon, 4 May 2015 08:31:23 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7408A1A1B9A for ; Mon, 4 May 2015 08:31:23 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-68-554790c95105 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B1.2F.03355.AC097455; Mon, 4 May 2015 11:31:22 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t44FVLr4027634; Mon, 4 May 2015 11:31:21 -0400 Received: from [18.101.8.98] (vpn-18-101-8-98.mit.edu [18.101.8.98]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t44FVJf8025905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 May 2015 11:31:20 -0400 Message-ID: <554790C7.30801@mit.edu> Date: Mon, 04 May 2015 11:31:19 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ken Hornstein , kitten@ietf.org References: <20150504144005.AFB1A4D3E1@pb-smtp1.pobox.com> In-Reply-To: <20150504144005.AFB1A4D3E1@pb-smtp1.pobox.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrJIsWRmVeSWpSXmKPExsUixCmqrHtqgnuowbF3nBb9TcdZLI5uXsXi wOSxZMlPJo+Ll5QDmKK4bFJSczLLUov07RK4Mn71vmQreMBXsb8proHxI3cXIyeHhICJxMQ7 M9khbDGJC/fWs3UxcnEICSxmktjyYAIrhLOBUWJN/2dWkCohgQNMEh/n8YHYvAIqEj3vVzGC 2CwCqhIzLt0Es9kElCXW79/KAmKLCoRJTPv9nBWiXlDi5MwnQHEODhEBY4nfc8HGCAOVn311 ih1ivJXE1IUXwVo5Bawl9k/eCWYzC+hJ7Lj+ixXClpdo3jqbeQKjwCwkU2chKZuFpGwBI/Mq RtmU3Crd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2M4BCV5NvB+PWg0iFGAQ5GJR7eE6vc QoVYE8uKK3MPMUpyMCmJ8lqkuIcK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHlaAHK8aYkVlal FuXDpKQ5WJTEeTf94AsREkhPLEnNTk0tSC2CycpwcChJ8Nr3ATUKFqWmp1akZeaUIKSZODhB hvMADZ/eDzK8uCAxtzgzHSJ/ilFRSpzXDyQhAJLIKM2D64WlkFeM4kCvCPMeA6niAaYfuO5X QIOZgAYfqHcBGVySiJCSamAUOsg8h6F6nXVD/92/DTqmjNLvjs6a+MBkm/P5sz/f9S725p8k 3HHo/7EcywlsLxnsypo+T3hw96L/a981UTuWLA3+Gsl1dX3+78safT/+9HPs13DpFhXd9NPG 7ccVxyCPD5t9bhocOrIiNlNLU8rqj+/bSNvILcLOssGfBC5q106Wls9ayXFXiaU4I9FQi7mo OBEAz186JvwCAAA= Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 15:31:26 -0000 On 05/04/2015 10:40 AM, Ken Hornstein wrote: >> Essentially, the answer is different whether OTP is supposed to be the >> first (and only) authentication factor, or a second factor to be used in >> conjunction with a password. > See, I think you've got the question all wrong. My question is NOT, > "Is OTP supposed to be the only authentication factor?", it's, "Which > protocol is it actually possible for me to deploy successfully?" Deployability is a big motivator for SPAKE preauth. I wasn't involved in the early stages of FAST OTP, but I believe it was primarily trying to solve the problem of bridging between an OTP master authentication server and the Kerberos protocol. In a deployment where the KDC has no user-specific shared secrets with the client, there needs to be some way of establishing a confidential, server-authenticated channel from the client to the KDC, so that the client can send the PIN+OTP value to the KDC for verification against the OTP back end. FAST allows that channel to be created using either a host keytab or an X.509 KDC certificate (using anonymous PKINIT). The big challenges of deploying FAST OTP as I see it are threefold: * It is designed to replace rather than augment Kerberos long-term keys. * At least in MIT krb5, we haven't added enough FAST support to the upper layers of the get-init-creds stack to make it easy to deploy. * Unless you can assume host keytabs on all of the clients, there's no good way around the requirement to put an X.509 certificate on the KDC and configuring all of the clients to trust its CA. SPAKE preauth doesn't have these problems, but it does require you to start with traditional Kerberos back-end database containing string2key'd user passwords. If you don't have that, and instead have an OTP server with PINs, then FAST OTP may still be a better answer. From nobody Mon May 4 08:53:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3D91A8725 for ; Mon, 4 May 2015 08:53:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQO2_zqJsQUj for ; Mon, 4 May 2015 08:53:40 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id AF1B61A1ACA for ; Mon, 4 May 2015 08:53:40 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id B64174D682 for ; Mon, 4 May 2015 11:53:38 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:mime-version:content-type:date:message-id; s=sasl; bh=HvTmZawSvzEcqKQaLJte4mRA9Fs=; b=v6hTeGO0WdI1EuaGfOW4 SsxTR6XCCB7Lrl9w2XQ3725seMtUGtKpumE6MtmA/2q+StTfYhyQ6LUp4SRwzU/H Z8/9rlG2ja8i3dwkH7I8hH11HqxdSDxkPXiMVLmN0Tp7H8XqNLu15heLE9wFPm21 yrDmv9CUBNdasBM5lnAz9J4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:mime-version:content-type:date:message-id; q=dns; s=sasl; b=X+XMqS24P9c0PoYhQ10RbbKuQPkJhT86difxVQVr0P5jy+aMVbg/m R0JB8LJ1xYHjOgvrBjpWQlC3bMrAWaHivjiqzLWcZXpccJtn3b5+BYNB3WLA+qwa aP5MGFgFdbbuiaH9imVzJ1u6Ns5yWjG544J75ykqKDxqCGH4tA8u4U= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id AF0894D67D for ; Mon, 4 May 2015 11:53:38 -0400 (EDT) Received: from zoolander.cmf.nrl.navy.mil (unknown [134.207.12.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id D8C334D67C for ; Mon, 4 May 2015 11:53:37 -0400 (EDT) From: Ken Hornstein To: kitten@ietf.org In-Reply-To: <1430753150.2798.13.camel@redhat.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 04 May 2015 11:54:32 -0400 X-Pobox-Relay-ID: BA53FD00-F275-11E4-BC7E-83E09F42C9D4-90216062!pb-smtp1.pobox.com Message-Id: <20150504155338.AF0894D67D@pb-smtp1.pobox.com> Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 15:53:42 -0000 >> See, I think you've got the question all wrong. My question is NOT, >> "Is OTP supposed to be the only authentication factor?", it's, "Which >> protocol is it actually possible for me to deploy successfully?" > >I believe the tension you are seeing here is the result of >commoditization of 2FA. Early on, 2FA systems were entirely parallel >authentication stacks which authenticators would need to integrate >with. As 2FA commoditized, we see open protocols which can be >integrated into existing authentication stacks. Well ... I understand why you'd say that, but I disagree. We use the old, old SAM protocol with what you call a pre-commiditized 2FA system today. So I was thinking of migrating that to FAST as part of our long-overdue Kerberos upgrade. But I hadn't really sat down and understood FAST (I did try to start reading the RFC several times, but man, it's pretty dense ... I mean, yeah, I understand it's a protocol document so that's just a necessity, but if you want a broad overview it's a tough read). So now you spelled out, "Hey, you need ANOTHER key to create the FAST channel" ... and that's really a non-starter for our environment, because those keys don't exist for our users that most need 2FA (and see previous discussion about the problems of requiring anonymous pkinit). >However, after 2FA commoditized the question becomes how can I augment >my existing authentication stack (1FA Kerberos) with a 2FA method. >This is what SPAKE Preauth provides. Well ... again, I don't think that's really the "true" question that gets asked. I mean, the people who are pushing the use of 2FA are generally not qualified to talk about Kerberos at a protocol level. Really, the question is, "Are you using 2FA with Kerberos?". Well, actually, I doubt that the word "Kerberos" appears anywhere. It's more like there's a STIG or checklist somewhere that says, "2FA is required", or maybe, "2FA is required when passwords are used". As long as we can legitimately assert that 2FA is in use, that's really all we care about at a fundamental level; if it's "2FA + Kerberos password", that is totally fine (that's what we have today). Yes, I _personally_ care that the crypto is the best that we can possibly do, but having something that is deployable is more important. >Now, I think your questions here raise an interesting point: can and >should we require some standardization to use the 2FA feature of SPAKE >preauth? I think the answer is no. And I've come to think that the >SPAKESecondFactor type field should really be OBJECT IDENTIFIER. I do not quite understand your point ... are you saying that your I-D should completely specify how all 2FA systems work with SPAKE? And personally I'd vote to keeping SPAKESecondFactor an Int32 rather than an OID. --Ken From nobody Mon May 4 10:32:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159B91A86EF for ; Mon, 4 May 2015 10:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8piXytD4Yl9 for ; Mon, 4 May 2015 10:32:20 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DB31A86E8 for ; Mon, 4 May 2015 10:32:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id AAD36206F7; Mon, 4 May 2015 13:31:10 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sln4mtnCPHbP; Mon, 4 May 2015 13:31:10 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 May 2015 13:31:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9594483168; Mon, 4 May 2015 13:32:17 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> <55478C61.2040601@mit.edu> Date: Mon, 04 May 2015 13:32:17 -0400 In-Reply-To: <55478C61.2040601@mit.edu> (Greg Hudson's message of "Mon, 04 May 2015 11:12:33 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 17:32:22 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On 05/04/2015 08:48 AM, Sam Hartman wrote: >> I think it is entirely reasonably to ask all clients to send a >> freshness request. Greg> I think it's a little unfortunate, but if it will make Greg> Microsoft's life easier, an few extra bytes in each AS request Greg> won't break the world. Well, it is kind of what RFC 4120 anticipates you'll do whenever you introduce a new option. From nobody Mon May 4 11:35:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42701ACD41 for ; Mon, 4 May 2015 11:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgGk9LXC4uir for ; Mon, 4 May 2015 11:35:26 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5A91ACD40 for ; Mon, 4 May 2015 11:35:25 -0700 (PDT) X-AuditID: 12074422-f79cb6d000000d7b-57-5547bbecf67d Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 44.30.03451.CEBB7455; Mon, 4 May 2015 14:35:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t44IZIoL021443; Mon, 4 May 2015 14:35:19 -0400 Received: from [18.101.8.98] (vpn-18-101-8-98.mit.edu [18.101.8.98]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t44IZG2e005435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 4 May 2015 14:35:17 -0400 Message-ID: <5547BBE4.4000006@mit.edu> Date: Mon, 04 May 2015 14:35:16 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sam Hartman References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> <55478C61.2040601@mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphleLIzCtJLcpLzFFi42IRYrdT132z2z3U4P0ZY4uvbQ/YLI5uXsVi 8a+bz4HZY8mSn0werTv+snusnHqaPYA5issmJTUnsyy1SN8ugSuj4ckF9oJ/rBVty56zNzDe Yuli5OSQEDCR+LtxPxuELSZx4d56IJuLQ0hgMZPEqUOT2EESQgIbGCUePnaHsA8wSdxaVAFi 8wqoSfyb/pUVxGYRUJXo33AIzGYTUJZYv38r2AJRgTCJab+fs0LUC0qcnPkELC4ioC6x+hLE fGaBCombnS1MXYwcHMIC3hKv1+hC3LCIVeLMzW+MIDWcQLu2fvkLVa8nseP6L1YIW16ieets 5gmMgrOQrJiFpGwWkrIFjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdE31cjNL9FJTSjcxggPa RWkH48+DSocYBTgYlXh4Fda6hQqxJpYVV+YeYpTkYFIS5d2xzj1UiC8pP6UyI7E4I76oNCe1 +BCjBAezkgjvnbVAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd6U XUCNgkWp6akVaZk5JQhpJg5OkOE8QMPPgNTwFhck5hZnpkPkTzHqctyZ8n8RkxBLXn5eqpQ4 7zKQIgGQoozSPLg5sET0ilEc6C1h3hBgWhLiASYxuEmvgJYwAS05UO8CsqQkESEl1cCo3Si3 XOPqlNSEhRz5rBNnBQkYeoazbDR0VVHuWdQTMvnMytf2+6vOJJm+fV0sp9WhXir1Y1GxdaJh z+mKJdm/gg5wyQU+uts5+UDDtClT1tyeo36zvJt34jqFK/+euPLN7z6XaCQx/1To9wlCPCqX t+anM9+8fUJKPiiEc5bmBu2lV6qiTd8psRRnJBpqMRcVJwIAv8ptmx8DAAA= Archived-At: Cc: "kitten@ietf.org" , Michiko Short Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 18:35:27 -0000 On 05/04/2015 01:32 PM, Sam Hartman wrote: > Greg> I think it's a little unfortunate, but if it will make > Greg> Microsoft's life easier, an few extra bytes in each AS request > Greg> won't break the world. > > Well, it is kind of what RFC 4120 anticipates you'll do whenever you > introduce a new option. The freshness token is a padata value in the method-data of a PREAUTH_REQUIRED error. To an old client, it looks like like an unsupported preauth mech or a piece of unrecognized informational preauth data (which is what it is). We have never required clients to indicate support for either of these things. For instance, RFC 4120 requires KDCs to send ETYPE-INFO2 in method-data even if the request does not use a new enctype. From nobody Mon May 4 11:56:05 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207A11ACDC7 for ; Mon, 4 May 2015 11:56:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tPO_hLcGR1X for ; Mon, 4 May 2015 11:56:04 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 550731ACD63 for ; Mon, 4 May 2015 11:56:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 70372206FF; Mon, 4 May 2015 14:54:55 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-aYlC3aoQSw; Mon, 4 May 2015 14:54:55 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 4 May 2015 14:54:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C2DC3812D1; Mon, 4 May 2015 14:56:01 -0400 (EDT) From: Sam Hartman To: Greg Hudson References: <20150307024328.31740.75123.idtracker@ietfa.amsl.com> <5500AD51.5030902@mit.edu> <550339DA.6000109@mit.edu> <55478C61.2040601@mit.edu> <5547BBE4.4000006@mit.edu> Date: Mon, 04 May 2015 14:56:01 -0400 In-Reply-To: <5547BBE4.4000006@mit.edu> (Greg Hudson's message of "Mon, 04 May 2015 14:35:16 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "kitten@ietf.org" , Michiko Short , Sam Hartman Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2015 18:56:05 -0000 >>>>> "Greg" == Greg Hudson writes: Greg> On 05/04/2015 01:32 PM, Sam Hartman wrote: Greg> I think it's a little unfortunate, but if it will make Greg> Microsoft's life easier, an few extra bytes in each AS request Greg> won't break the world. >> >> Well, it is kind of what RFC 4120 anticipates you'll do whenever >> you introduce a new option. Greg> The freshness token is a padata value in the method-data of a Greg> PREAUTH_REQUIRED error. To an old client, it looks like like Greg> an unsupported preauth mech or a piece of unrecognized Greg> informational preauth data (which is what it is). We have Greg> never required clients to indicate support for either of these Greg> things. For instance, RFC 4120 requires KDCs to send Greg> ETYPE-INFO2 in method-data even if the request does not use a Greg> new enctype. We require clients to indicate support for FAST and permit them to indicate support for pkinit. My point is that RFC 4120 anticipates people indicating support for features when a KDC might wish to know whether the feature is supported prior to generating a response. From nobody Mon May 4 17:16:59 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A801B2D16 for ; Mon, 4 May 2015 17:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.911 X-Spam-Level: X-Spam-Status: No, score=-5.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOK5eVpH3B7B for ; Mon, 4 May 2015 17:16:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 071C31B2D10 for ; Mon, 4 May 2015 17:16:54 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t450GsBm032541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 4 May 2015 20:16:54 -0400 Received: from vpn-59-107.rdu2.redhat.com (vpn-59-107.rdu2.redhat.com [10.10.59.107]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t450GrSr002830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 May 2015 20:16:53 -0400 Message-ID: <1430785012.4335.1.camel@redhat.com> From: Nathaniel McCallum To: Ken Hornstein Date: Mon, 04 May 2015 20:16:52 -0400 In-Reply-To: <20150504155338.AF0894D67D@pb-smtp1.pobox.com> References: <20150504155338.AF0894D67D@pb-smtp1.pobox.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 00:16:57 -0000 On Mon, 2015-05-04 at 11:54 -0400, Ken Hornstein wrote: > > > See, I think you've got the question all wrong. My question is > > > NOT, > > > "Is OTP supposed to be the only authentication factor?", it's, > > > "Which > > > protocol is it actually possible for me to deploy successfully?" > > > > I believe the tension you are seeing here is the result of > > commoditization of 2FA. Early on, 2FA systems were entirely > > parallel > > authentication stacks which authenticators would need to integrate > > with. As 2FA commoditized, we see open protocols which can be > > integrated into existing authentication stacks. > > Well ... I understand why you'd say that, but I disagree. > > We use the old, old SAM protocol with what you call a pre > -commiditized > 2FA system today. So I was thinking of migrating that to FAST as > part > of our long-overdue Kerberos upgrade. But I hadn't really sat down > and > understood FAST (I did try to start reading the RFC several times, > but > man, it's pretty dense ... I mean, yeah, I understand it's a protocol > document so that's just a necessity, but if you want a broad overview > it's a tough read). So now you spelled out, "Hey, you need ANOTHER > key > to create the FAST channel" ... and that's really a non-starter for > our environment, because those keys don't exist for our users that > most need 2FA (and see previous discussion about the problems of > requiring > anonymous pkinit). > > > However, after 2FA commoditized the question becomes how can I > > augment > > my existing authentication stack (1FA Kerberos) with a 2FA method. > > This is what SPAKE Preauth provides. > > Well ... again, I don't think that's really the "true" question that > gets asked. I mean, the people who are pushing the use of 2FA are > generally not qualified to talk about Kerberos at a protocol level. > Really, the question is, "Are you using 2FA with Kerberos?". Well, > actually, I doubt that the word "Kerberos" appears anywhere. It's > more > like there's a STIG or checklist somewhere that says, "2FA is > required", > or maybe, "2FA is required when passwords are used". As long as we > can legitimately assert that 2FA is in use, that's really all we care > about at a fundamental level; if it's "2FA + Kerberos password", > that is > totally fine (that's what we have today). Yes, I _personally_ care > that > the crypto is the best that we can possibly do, but having something > that is deployable is more important. > > > Now, I think your questions here raise an interesting point: can > > and > > should we require some standardization to use the 2FA feature of > > SPAKE > > preauth? I think the answer is no. And I've come to think that the > > SPAKESecondFactor type field should really be OBJECT IDENTIFIER. > > I do not quite understand your point ... are you saying that your I-D > should completely specify how all 2FA systems work with SPAKE? And > personally I'd vote to keeping SPAKESecondFactor an Int32 rather than > an OID. No. I'm saying a vendor can define their own 2FA and assign it an enterprise OID number and use it out of the box. No standardization required. Then we would create some IETF OIDs for open protocols (such as OATH and U2F). Nathaniel From nobody Mon May 4 21:17:44 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4601A90BA for ; Mon, 4 May 2015 21:17:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpfJtvItLqB6 for ; Mon, 4 May 2015 21:17:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8F51A9062 for ; Mon, 4 May 2015 21:17:38 -0700 (PDT) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 832F241429 for ; Tue, 5 May 2015 00:17:36 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to :subject:in-reply-to:mime-version:content-type:date:message-id; s=sasl; bh=E1OyzhYR27RAwQ7+8D8hf9KO6yw=; b=tpCYqkZI6hQRWxZL+aeR 8PXRCtdheybpW8843YZE4DfGXCDzwttSJSX7zLO77mogJMcL4mgCcabY87aWik08 i6VynW++6VCPTM8Inammz5j0NzBVk0DtAw4oBnrh3YGcuTsxX0THoel4G2kRdzBq wzFwpgaZ8lB+fAcdAAdKYug= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:subject :in-reply-to:mime-version:content-type:date:message-id; q=dns; s=sasl; b=d4nhq6TCTHDPnajnXA3y+RIwblPul6QLWbkrcFm4Sc2ddQ7lWxKCi 7JQ1cVXMa82Q0wKCS+KIpqsoEDz6HqXomXq6lvlZydgFJc8ee6mhR5j+MZ6jkok9 cB4VGcFErIxgMaLhpsNXATY31CgrgeKeS4qzGDYrTZe8sIBLU6NAJQ= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 7CC3741428 for ; Tue, 5 May 2015 00:17:36 -0400 (EDT) Received: from paradise-falls.internal (unknown [96.255.161.217]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 2A1AF41426 for ; Tue, 5 May 2015 00:17:36 -0400 (EDT) From: Ken Hornstein To: kitten@ietf.org In-Reply-To: <1430785012.4335.1.camel@redhat.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 May 2015 00:17:34 -0400 X-Pobox-Relay-ID: A8D18710-F2DD-11E4-AEC3-83E09F42C9D4-90216062!pb-smtp1.pobox.com Message-Id: <20150505041736.7CC3741428@pb-smtp1.pobox.com> Archived-At: Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 04:17:41 -0000 >> I do not quite understand your point ... are you saying that your I-D >> should completely specify how all 2FA systems work with SPAKE? And >> personally I'd vote to keeping SPAKESecondFactor an Int32 rather than >> an OID. > >No. I'm saying a vendor can define their own 2FA and assign it an >enterprise OID number and use it out of the box. No standardization >required. > >Then we would create some IETF OIDs for open protocols (such as OATH >and U2F). I'm wondering how that is better than the "normal" Kerberos scheme where vendors can register their 2FA or whatever with IANA. And on further thought ... I realize that I'm strongly with Nico in that a generic OTP should be specified somewhere. I know you mentioned U2F, but that just seems like an additional unnecessary layer (also, the U2F protocol seems to be web-specific, in that it mentions adding the origin URL and TLS channel ID to the authentication flow). Sure, if people want to use U2F no objections here, but it just seems lousy that the initial specification(s) don't mention a generic OTP protocol; like Nico said, there are a ton of these devices. --Ken From nobody Tue May 5 10:56:09 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725781A902B for ; Tue, 5 May 2015 10:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.612 X-Spam-Level: X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdvBRLwvrlVw for ; Tue, 5 May 2015 10:55:57 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 687541A9042 for ; Tue, 5 May 2015 10:55:39 -0700 (PDT) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t45HtcnW046515; Tue, 5 May 2015 13:55:38 -0400 Date: Tue, 5 May 2015 13:55:38 -0400 (EDT) From: Simo Sorce To: Ken Hornstein Message-ID: <1132502056.11486843.1430848538821.JavaMail.zimbra@redhat.com> In-Reply-To: <20150505041736.7CC3741428@pb-smtp1.pobox.com> References: <20150505041736.7CC3741428@pb-smtp1.pobox.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.4.164.1, 10.5.101.130] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: SPAKE Preauth Thread-Index: RIU8AvY0wishdOx8KlNZizxEeQN0kw== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 17:56:02 -0000 ----- Original Message ----- > From: "Ken Hornstein" > To: kitten@ietf.org > Sent: Tuesday, May 5, 2015 12:17:34 AM > Subject: Re: [kitten] SPAKE Preauth > > >> I do not quite understand your point ... are you saying that your I-D > >> should completely specify how all 2FA systems work with SPAKE? And > >> personally I'd vote to keeping SPAKESecondFactor an Int32 rather than > >> an OID. > > > >No. I'm saying a vendor can define their own 2FA and assign it an > >enterprise OID number and use it out of the box. No standardization > >required. > > > >Then we would create some IETF OIDs for open protocols (such as OATH > >and U2F). > > I'm wondering how that is better than the "normal" Kerberos scheme where > vendors can register their 2FA or whatever with IANA. > > And on further thought ... I realize that I'm strongly with Nico in that > a generic OTP should be specified somewhere. I know you mentioned U2F, > but that just seems like an additional unnecessary layer (also, the U2F > protocol seems to be web-specific, in that it mentions adding the origin > URL and TLS channel ID to the authentication flow). Sure, if people > want to use U2F no objections here, but it just seems lousy that the > initial specification(s) don't mention a generic OTP protocol; like Nico > said, there are a ton of these devices. If by "genric" protocol you mena TOTP or HOTP tokens we'll definitely provide that. I think Nico meant "generic" as in really "free form as long as it is a text string" type of generic which I would object too(it would require sending prompts from the KDC. See previous message about why that is not ok. Simo. -- Simo Sorce * Red Hat, Inc. * New York From nobody Tue May 5 11:02:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60C9C1A903E for ; Tue, 5 May 2015 11:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFQGONfVz5wX for ; Tue, 5 May 2015 11:02:45 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71A9E1A90CF for ; Tue, 5 May 2015 11:02:19 -0700 (PDT) Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 0AD56200D3097 for ; Tue, 5 May 2015 11:02:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=M3P67+7kPLlvJkzlWPwW yyQ98M8=; b=Tzd7RhG5Zy9ylT4CMU/gWiNNIV95bWlRj1EsRleL/1iu9OYUmTAo mdnedUpbcM11M9qjM+uAt7Lf41g58kCY2Veu/Tqcht+pMHLAJx5YJUD392B6FOa/ IlD+zZ/EGqRVHQt+gfanx9mxkQxVMtqNcUxQhPnDb+Krpmz4TcsqDG4= Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 8D65E200D3096 for ; Tue, 5 May 2015 11:02:18 -0700 (PDT) Received: by yhda23 with SMTP id a23so43181698yhd.2 for ; Tue, 05 May 2015 11:02:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.2.97 with SMTP id 61mr4263789yhe.195.1430848936449; Tue, 05 May 2015 11:02:16 -0700 (PDT) Received: by 10.13.253.3 with HTTP; Tue, 5 May 2015 11:02:16 -0700 (PDT) In-Reply-To: <1132502056.11486843.1430848538821.JavaMail.zimbra@redhat.com> References: <20150505041736.7CC3741428@pb-smtp1.pobox.com> <1132502056.11486843.1430848538821.JavaMail.zimbra@redhat.com> Date: Tue, 5 May 2015 13:02:16 -0500 Message-ID: From: Nico Williams To: Simo Sorce Content-Type: multipart/alternative; boundary=089e013a10a8959d6e0515597a9c Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2015 18:02:46 -0000 --089e013a10a8959d6e0515597a9c Content-Type: text/plain; charset=UTF-8 I meant generic as in: works with all the commonly deployed OTPs such as HOTP, including all schemes where the user merely types in a sequence of digits appearing in a display on a token. --089e013a10a8959d6e0515597a9c Content-Type: text/html; charset=UTF-8 I meant generic as in: works with all the commonly deployed OTPs such as HOTP, including all schemes where the user merely types in a sequence of digits appearing in a display on a token. --089e013a10a8959d6e0515597a9c-- From nobody Tue May 12 11:51:23 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964AB1B2F14 for ; Tue, 12 May 2015 11:51:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aNDLuRF1cctx for ; Tue, 12 May 2015 11:51:06 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CE61B2F23 for ; Tue, 12 May 2015 11:51:06 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-c9-55524b98ca7f Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 72.DF.03493.89B42555; Tue, 12 May 2015 14:51:04 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t4CIp4mH010720 for ; Tue, 12 May 2015 14:51:04 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4CIp3lL023392 for ; Tue, 12 May 2015 14:51:04 -0400 From: Greg Hudson To: kitten@ietf.org Date: Tue, 12 May 2015 14:51:02 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUixCmqrDvDOyjUYPEUG4ujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY8PHy6wFvwQqpmzczNbA+I63i5GTQ0LARKL74xEWCFtM4sK9 9WwgtpDAYiaJ1s02XYxcQPZxRomNF7pZIZwOJolLk/4wglSxCShLrN+/FaxbREBYYvfWd8wg trCApcTOJ3+Bajg4WARUJRZ3coGEeQUMJdb+aGSGsAUlTs58AtbKLCAhcfDFC+YJjDyzkKRm IUktYGRaxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERQa7C4qOxibDykdYhTg YFTi4Z3wLDBUiDWxrLgy9xCjJAeTkiivpGZQqBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3lVG QDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQleNS+gRsGi1PTUirTM nBKENBMHJ8hwHqDhd0BqeIsLEnOLM9Mh8qcYFaXEeTNAEgIgiYzSPLheWOy+YhQHekWY9yNI FQ8w7uG6XwENZgIa7BgXADK4JBEhJdXAuD7hbMnyc/P+bbW0+qyaK+T3LDim/ozHpM0d7Wqb H5TPbN1QZN7dkheyxZrnUM/3pXKqiw4pda+6Oe/AMtnIJ5cjK5IvWqfZ32eevTvIYsnWXe+P H7nX4fb9t/KvoElZq4WmpZusnXQ/zGfSnCncFxn5Kt++SYm8OPnc9HOpqR/69XVidwVb9imx FGckGmoxFxUnAgBX+g+3uAIAAA== Archived-At: Subject: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 18:51:18 -0000 SPAKE preauth[1] will use the client long-term key as input to the SPAKE2 algorithm[2] as the shared secret w value. The current draft doesn't say how to derive the w value, and the SPAKE2 draft doesn't say much either (just "Typically w will be the hash of a user-supplied password, truncated and taken mod p"). The proof of concept just converts the bits of the key into a bignum, which doesn't match our usual cryptographic practices. I expect we will want to start by generating some uniformly distributed bytes using PRF+(k, "someconstant") with an output length dependent on the curve. Beyond that point, I think it will depend on the curve type. For CFRG curves (when they exist), we'll be done; CFRG curves accept uniformly distributed bytes as input and force them into appropriate form for a scalar. For instance, for curve25519/ed25519, five bits of the input are forced to specific values. For P-256, P-384, and P-521, we need a large integer in the range of the group order, which is not bit-aligned. The simplest option is to just decode the bytes as a bignum and let the resulting distribution of scalar values be somewhat non-uniform (a small fraction of scalar values are effectively twice as likely as the other ones). I don't think this slight non-uniformity is a problem, and so far the people I have talked to have agreed. But I'd like to check here, and will probably also need to solicit opinions from Walter Ladd and maybe others. I don't know if there are likely to be additional considerations for other old curves. For example, if the curve cofactor is not 1, do we need to make sure the scalar value is divisible by the cofactor? This ties into the larger question of whether we can really make SPAKE preauth work with arbitrary non-CFRG curves without additional per-curve specification. Whatever we do needs to be well-specified (or we will have interoperability issues), and cannot contain inherent timing channels since it operates on a secret input. [1] https://tools.ietf.org/html/draft-mccallum-kitten-krb-spake-preauth-00 [2] https://tools.ietf.org/html/draft-irtf-cfrg-spake2-01 From nobody Tue May 12 14:47:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD821AD28D for ; Tue, 12 May 2015 14:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3TBOYY2uPDz for ; Tue, 12 May 2015 14:47:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 43A2D1A9239 for ; Tue, 12 May 2015 14:47:43 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 102A52C808C; Tue, 12 May 2015 14:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=grew+XxynUw9Ua 9heBhyVKEnz5w=; b=nC8npNWDPa2WZzoVV+YKImYAjwvky/IzzTyuSjdDcWXBQO Fes0SIgN1xET98D9KVU5IKGAs8HZgeieFB9Ow7EuEhSoow6s68EdOtkon2bEzLnk fv6Bip3cvOn/vsEPyUCnBZcvTWbsXaUKGC5qokhCV0pj4wpVSmXtGs6tthtSA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 7A6302C806E; Tue, 12 May 2015 14:47:42 -0700 (PDT) Date: Tue, 12 May 2015 16:47:41 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150512214740.GT7287@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2015 21:47:44 -0000 On Tue, May 12, 2015 at 02:51:02PM -0400, Greg Hudson wrote: > For CFRG curves (when they exist), we'll be done; CFRG curves accept > uniformly distributed bytes as input and force them into appropriate > form for a scalar. For instance, for curve25519/ed25519, five bits of > the input are forced to specific values. Will that be true for other CFRG curves? I hope so, that'd be nice. > For P-256, P-384, and P-521, we need a large integer in the range of the > group order, which is not bit-aligned. The simplest option is to just > decode the bytes as a bignum and let the resulting distribution of > scalar values be somewhat non-uniform (a small fraction of scalar values > are effectively twice as likely as the other ones). I don't think this > slight non-uniformity is a problem, and so far the people I have talked > to have agreed. But I'd like to check here, and will probably also need > to solicit opinions from Walter Ladd and maybe others. Yes, this is really a question for Watson Ladd in particular and CFRG in general. My take is that the public values being of the for xG + wM, where x should be a randomly and uniformly chosen scalar, the xG term will cause the public value to be as uniformly distributed as x regardless of how non-uniform w might be. So I think there's no harm in picking a simple mapping from the long-term key to w, provided there's a way to abstract this (see below). However, don't you run into the same problem when generating the ephemeral scalars? Or does OpenSSL provide a function for that? If distributions of both w and x are uniform, then I don't know if x's mere randomness is enough (again, a question for Watson L.). > I don't know if there are likely to be additional considerations for > other old curves. For example, if the curve cofactor is not 1, do we > need to make sure the scalar value is divisible by the cofactor? This Yes. > ties into the larger question of whether we can really make SPAKE > preauth work with arbitrary non-CFRG curves without additional per-curve > specification. Can we define a curve abstraction that provides what we need? - random2scalar(r) -> scalar - randomscalar() -> scalar - dh(s) -> public # for Curve25519-like curves - dh_sharedsecret(s, public) -> secret # for Curve25519-like curves - scalarmult(s, point) -> point # generic; points are opaque - add(point1, point2) -> point - sub(point1, point2) -> point - encode_point(point) -> octet string - decode_point(octet string) -> point - point_x(point) -> x scalar - point_y(point) -> y scalar - make_point(x, y) -> point ... Ideally CFRG should be providing this for its curves. It should be pssible to implement such things for other curves too. Some of the above abstractions are a consequence of CFRG electing to leave point encoding to each curve for DH (and, if it were useful, perhaps for signatures too, though that's a debate that hasn't happened yet). > Whatever we do needs to be well-specified (or we will have > interoperability issues), and cannot contain inherent timing channels > since it operates on a secret input. Yes. Nico -- From nobody Wed May 13 06:51:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67121B2BBF for ; Wed, 13 May 2015 06:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.311 X-Spam-Level: X-Spam-Status: No, score=-5.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, J_CHICKENPOX_101=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ui9nPrmNG1Pz for ; Wed, 13 May 2015 06:51:39 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD93F1A1C02 for ; Wed, 13 May 2015 06:51:39 -0700 (PDT) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4DDpXHP022188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 13 May 2015 09:51:34 -0400 Received: from vpn-48-157.rdu2.redhat.com (vpn-48-157.rdu2.redhat.com [10.10.48.157]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4DDpV03030846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 13 May 2015 09:51:32 -0400 Message-ID: <1431525091.3260.26.camel@redhat.com> From: Nathaniel McCallum To: Nico Williams Date: Wed, 13 May 2015 09:51:31 -0400 In-Reply-To: <20150512214740.GT7287@localhost> References: <20150512214740.GT7287@localhost> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 Archived-At: Cc: kitten@ietf.org, Watson Ladd Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 13:51:42 -0000 On Tue, 2015-05-12 at 16:47 -0500, Nico Williams wrote: > On Tue, May 12, 2015 at 02:51:02PM -0400, Greg Hudson wrote: > > For CFRG curves (when they exist), we'll be done; CFRG curves > > accept > > uniformly distributed bytes as input and force them into > > appropriate > > form for a scalar. For instance, for curve25519/ed25519, five > > bits of > > the input are forced to specific values. > > Will that be true for other CFRG curves? I hope so, that'd be nice. > > > For P-256, P-384, and P-521, we need a large integer in the range > > of the > > group order, which is not bit-aligned. The simplest option is to > > just > > decode the bytes as a bignum and let the resulting distribution of > > scalar values be somewhat non-uniform (a small fraction of scalar > > values > > are effectively twice as likely as the other ones). I don't think > > this > > slight non-uniformity is a problem, and so far the people I have > > talked > > to have agreed. But I'd like to check here, and will probably > > also need > > to solicit opinions from Walter Ladd and maybe others. > > Yes, this is really a question for Watson Ladd in particular and > CFRG in > general. I have CC'd Watson Ladd. > My take is that the public values being of the for xG + wM, where x > should be a randomly and uniformly chosen scalar, the xG term will > cause > the public value to be as uniformly distributed as x regardless of > how > non-uniform w might be. So I think there's no harm in picking a > simple > mapping from the long-term key to w, provided there's a way to > abstract > this (see below). > > However, don't you run into the same problem when generating the > ephemeral scalars? Or does OpenSSL provide a function for that? If > distributions of both w and x are uniform, then I don't know if x's > mere > randomness is enough (again, a question for Watson L.). OpenSSL provides a function for generating a random scalar uniformly distributed within a given range. It works by generating n bytes of random data, where n is the smallest number of bytes that can represent the range. Then it checks to see if the generated random data is within the range. If it is, the value is returned. If it is not, it repeats the process until an appropriate random value is found. > > I don't know if there are likely to be additional considerations > > for > > other old curves. For example, if the curve cofactor is not 1, do > > we > > need to make sure the scalar value is divisible by the cofactor? > > This > > Yes. The SPAKE draft covers this scenario. > > ties into the larger question of whether we can really make SPAKE > > preauth work with arbitrary non-CFRG curves without additional per > > -curve > > specification. > > Can we define a curve abstraction that provides what we need? > > - random2scalar(r) -> scalar > - randomscalar() -> scalar > - dh(s) -> public # for Curve25519-like > curves > - dh_sharedsecret(s, public) -> secret # for Curve25519-like > curves > - scalarmult(s, point) -> point # generic; points are > opaque > - add(point1, point2) -> point > - sub(point1, point2) -> point > - encode_point(point) -> octet string > - decode_point(octet string) -> point Specifying an abstraction this tightly removes the possibility for at least one optimization. I'm not sure I want to get into the abstraction business. > - point_x(point) -> x scalar > - point_y(point) -> y scalar > - make_point(x, y) -> point > ... I'm not sure what these are even used for. > Ideally CFRG should be providing this for its curves. It should be > pssible to implement such things for other curves too. > > Some of the above abstractions are a consequence of CFRG electing to > leave point encoding to each curve for DH (and, if it were useful, > perhaps for signatures too, though that's a debate that hasn't > happened > yet). I'm not sure this is necessary. I think it is sufficient to specify that the group OIDs MUST define things like point encoding and M/N values or MUST implicitly use SEC1 compressed and the M/N values generated using the technique in the SPAKE draft. > > Whatever we do needs to be well-specified (or we will have > > interoperability issues), and cannot contain inherent timing > > channels > > since it operates on a secret input. > > Yes. +1 From nobody Wed May 13 07:47:55 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EB11B2C9B for ; Wed, 13 May 2015 07:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_101=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8JNFT-Pb1bh8 for ; Wed, 13 May 2015 07:18:09 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE351B2CA4 for ; Wed, 13 May 2015 07:18:00 -0700 (PDT) Received: by wizk4 with SMTP id k4so200856210wiz.1 for ; Wed, 13 May 2015 07:17:59 -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=Xfl+n4BoHUmKZMGpYPAEF54TL1JSBlCv/8mH2tCj550=; b=oDJe4IRBZXTSLy9C4EcGi2XPG5gaGHgQlO0g1GXKzvv2aZM20BExPiBTN6CChZaUfO kVGivX5lzt1TW2QcnW614kEK9TGMLWtl7zmuh6dHsgUfwswBe7zfgRmzhKDututIM60h 7oQo5vp+2HbQYmarZ6micmPwm39oem34+g9IWJeGQSIwubupd9i974J47ufzEVvKn6H3 6/8OUbqynFvlI+wb570ky+/t6alL/KOSPwQVra8CDwo/LqGqfJWePYiG2tqshps4uFfV U1fb0V7oG0wJlqPTy45JqwKn5EHC6HbJft0tDmfl9AMoHFYLuhR8dG53xaxkKKhVez8C 2tWQ== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr39586350wjb.94.1431526679565; Wed, 13 May 2015 07:17:59 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 13 May 2015 07:17:59 -0700 (PDT) In-Reply-To: <1431525091.3260.26.camel@redhat.com> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> Date: Wed, 13 May 2015 07:17:59 -0700 Message-ID: From: Watson Ladd To: Nathaniel McCallum Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Wed, 13 May 2015 07:47:54 -0700 Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 14:18:11 -0000 On Wed, May 13, 2015 at 6:51 AM, Nathaniel McCallum wrote: > On Tue, 2015-05-12 at 16:47 -0500, Nico Williams wrote: >> On Tue, May 12, 2015 at 02:51:02PM -0400, Greg Hudson wrote: >> > For CFRG curves (when they exist), we'll be done; CFRG curves >> > accept >> > uniformly distributed bytes as input and force them into >> > appropriate >> > form for a scalar. For instance, for curve25519/ed25519, five >> > bits of >> > the input are forced to specific values. >> >> Will that be true for other CFRG curves? I hope so, that'd be nice. >> >> > For P-256, P-384, and P-521, we need a large integer in the range >> > of the >> > group order, which is not bit-aligned. The simplest option is to >> > just >> > decode the bytes as a bignum and let the resulting distribution of >> > scalar values be somewhat non-uniform (a small fraction of scalar >> > values >> > are effectively twice as likely as the other ones). I don't think >> > this >> > slight non-uniformity is a problem, and so far the people I have >> > talked >> > to have agreed. But I'd like to check here, and will probably >> > also need >> > to solicit opinions from Walter Ladd and maybe others. >> >> Yes, this is really a question for Watson Ladd in particular and >> CFRG in >> general. > > I have CC'd Watson Ladd. The question of whether or not a protocol requires a uniformly determined scalar is not a function of the curve, but the protocol. EdDSA is much more stringent than key agreement, for instance: the same scalar conversion code is dangerous to use with it. Of course, the curve doesn't tell you how to sample values: that's an implementation detail and the there is nothing about P256 or P521 that stops you from doing it by modular reduction of values only slightly larger than the curvesize. > >> My take is that the public values being of the for xG + wM, where x >> should be a randomly and uniformly chosen scalar, the xG term will >> cause >> the public value to be as uniformly distributed as x regardless of >> how >> non-uniform w might be. So I think there's no harm in picking a >> simple >> mapping from the long-term key to w, provided there's a way to >> abstract >> this (see below). w is not distributed uniformly: far from it. The question of how far from uniform x may be distributed is a subtle one, but my guess is that even gross deviations from uniformity are fine, so taking a bunch of bytes mod the curve order is ok. But rejection sampling or modular reduction of longer strings are both easy to implement to sidestep this issue. >> >> However, don't you run into the same problem when generating the >> ephemeral scalars? Or does OpenSSL provide a function for that? If >> distributions of both w and x are uniform, then I don't know if x's >> mere >> randomness is enough (again, a question for Watson L.). > > OpenSSL provides a function for generating a random scalar uniformly > distributed within a given range. It works by generating n bytes of > random data, where n is the smallest number of bytes that can > represent the range. Then it checks to see if the generated random > data is within the range. If it is, the value is returned. If it is > not, it repeats the process until an appropriate random value is found. > >> > I don't know if there are likely to be additional considerations >> > for >> > other old curves. For example, if the curve cofactor is not 1, do >> > we >> > need to make sure the scalar value is divisible by the cofactor? >> > This >> >> Yes. > > The SPAKE draft covers this scenario. > >> > ties into the larger question of whether we can really make SPAKE >> > preauth work with arbitrary non-CFRG curves without additional per >> > -curve >> > specification. >> >> Can we define a curve abstraction that provides what we need? >> >> - random2scalar(r) -> scalar >> - randomscalar() -> scalar >> - dh(s) -> public # for Curve25519-like >> curves >> - dh_sharedsecret(s, public) -> secret # for Curve25519-like >> curves >> - scalarmult(s, point) -> point # generic; points are >> opaque >> - add(point1, point2) -> point >> - sub(point1, point2) -> point >> - encode_point(point) -> octet string >> - decode_point(octet string) -> point > > Specifying an abstraction this tightly removes the possibility for at > least one optimization. I'm not sure I want to get into the > abstraction business. > >> - point_x(point) -> x scalar >> - point_y(point) -> y scalar >> - make_point(x, y) -> point >> ... > > I'm not sure what these are even used for. > >> Ideally CFRG should be providing this for its curves. It should be >> pssible to implement such things for other curves too. >> >> Some of the above abstractions are a consequence of CFRG electing to >> leave point encoding to each curve for DH (and, if it were useful, >> perhaps for signatures too, though that's a debate that hasn't >> happened >> yet). SPAKE2 requires addition be supported. That rules out Kummer lines. The CFRG has not specified a model and how to encode points on that for addition to work. When they do I will modify the draft accordingly. However, I don't understand why the above abstraction isn't an implementation detail only. All one has to provide to use this draft are two generators and how to encode group elements. The algorithms for addition, multiplication etc. will be documented in the CFRG eventually. It's true that many groups only come with one canonical generator, but any sort of hashing method will give you two generators. > > I'm not sure this is necessary. I think it is sufficient to specify > that the group OIDs MUST define things like point encoding and M/N > values or MUST implicitly use SEC1 compressed and the M/N values > generated using the technique in the SPAKE draft. > >> > Whatever we do needs to be well-specified (or we will have >> > interoperability issues), and cannot contain inherent timing >> > channels >> > since it operates on a secret input. >> >> Yes. > > +1 -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed May 13 09:06:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5001A8AC0 for ; Wed, 13 May 2015 09:05:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AySn_g3eYR9y for ; Wed, 13 May 2015 09:05:54 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id AD9AA1A8A48 for ; Wed, 13 May 2015 09:05:52 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 7D5322C8094; Wed, 13 May 2015 09:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=GHqk8XYfvccRD2 dJacqnifYRXVo=; b=uFeso2B8R9gkRr6itgIbR8opzKPb+IH1xJqLM9MoaJG7eF GGooDhF6oVJaQFGZlgXnaVA74yJYxfy8yscPIVJ3Ge4LSYIDa6trhZsdkR0prjG5 gM33T9kHG8VaZKkrfHMJU8lzyMKaSngiKJ+L9qwTgM+tmfHQ2ql9IZ5qGyLP4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id 002292C808C; Wed, 13 May 2015 09:05:51 -0700 (PDT) Date: Wed, 13 May 2015 11:05:51 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20150513160549.GV7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:05:59 -0000 On Wed, May 13, 2015 at 07:17:59AM -0700, Watson Ladd wrote: > >> My take is that the public values being of the for xG + wM, where x > >> should be a randomly and uniformly chosen scalar, the xG term will > >> cause > >> the public value to be as uniformly distributed as x regardless of > >> how > >> non-uniform w might be. So I think there's no harm in picking a > >> simple > >> mapping from the long-term key to w, provided there's a way to > >> abstract > >> this (see below). > > w is not distributed uniformly: far from it. The question of how far That depends on how its salted. For our purposes, in practice it's not. > from uniform x may be distributed is a subtle one, but my guess is > that even gross deviations from uniformity are fine, so taking a bunch > of bytes mod the curve order is ok. But rejection sampling or modular > reduction of longer strings are both easy to implement to sidestep > this issue. That's what I thought. > SPAKE2 requires addition be supported. That rules out Kummer lines. > The CFRG has not specified a model and how to encode points on that > for addition to work. When they do I will modify the draft > accordingly. > > However, I don't understand why the above abstraction isn't an > implementation detail only. All one has to provide to use this draft > are two generators and how to encode group elements. The algorithms > for addition, multiplication etc. will be documented in the CFRG > eventually. It's true that many groups only come with one canonical > generator, but any sort of hashing method will give you two > generators. It absolutely could be an implementation-only abstraction. If it will be useful for many implementations though, it'd be useful to write that up. In particular, adding curves to an implementation will be easy if there is such an abstraction internally. (This was in response to an off-list question by an implementor about how to make it easy to add curves to their implementation given that they are using OpenSSL, without first having to add them to OpenSSL. Two simple answers are: don't, or add such an abstraction.) Nico -- From nobody Wed May 13 09:30:54 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B41B2D99 for ; Wed, 13 May 2015 09:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SeibXDTaj05l for ; Wed, 13 May 2015 09:30:53 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7231B2D10 for ; Wed, 13 May 2015 09:30:53 -0700 (PDT) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id B422D202060; Wed, 13 May 2015 09:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=OKBNVB17ZfL7sQ Klp7IocY062e8=; b=duqYX3KBolsVLueiL2cDcNgaze1kGqLMroTdwMOrJ9pYYO y+i3JZOV017mhTYTO6I9IlHHfUknui95+kW68Xsn5y3Z5OAa/z7oqLqIYDtUwpy0 d1Eba+OX78qSqzoOHaDyuy6PU3nJYTdNrGFdkVzSIrtvE4JykDJ7Ml1e8Muw8= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPA id 48169202054; Wed, 13 May 2015 09:30:52 -0700 (PDT) Date: Wed, 13 May 2015 11:30:51 -0500 From: Nico Williams To: Nathaniel McCallum Message-ID: <20150513163050.GW7287@localhost> References: <1430138754.2682.10.camel@redhat.com> <20150502231603.GG10065@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150502231603.GG10065@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE Preauth X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 16:30:53 -0000 On Sat, May 02, 2015 at 06:16:04PM -0500, Nico Williams wrote: > In addition to adding some standard OTP-ish second factors, I'd like to > have a way to "augment" the PAKE with the same user password so as to > improve resistance to KDC database compromise. As discussed off-list, Nathaniel proposes that an augmentation factor can wrap other factors, and so can be left to later. I'm satisfied with that answer. Nico -- From nobody Wed May 13 14:16:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A0D1ACEA2; Wed, 13 May 2015 14:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qv1l6ig-ehYT; Wed, 13 May 2015 14:16:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 633211ACE52; Wed, 13 May 2015 14:16:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id ED44B180209; Wed, 13 May 2015 14:14:20 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150513211420.ED44B180209@rfc-editor.org> Date: Wed, 13 May 2015 14:14:20 -0700 (PDT) Archived-At: Cc: kitten@ietf.org, rfc-editor@rfc-editor.org Subject: [kitten] RFC 7546 on Structure of the Generic Security Service (GSS) Negotiation Loop X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2015 21:16:12 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7546 Title: Structure of the Generic Security Service (GSS) Negotiation Loop Author: B. Kaduk Status: Informational Stream: IETF Date: May 2015 Mailbox: kaduk@mit.edu Pages: 21 Characters: 50075 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-kitten-gss-loop-05.txt URL: https://www.rfc-editor.org/info/rfc7546 DOI: http://dx.doi.org/10.17487/RFC7546 This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified. This document is a product of the Common Authentication Technology Next Generation Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Wed May 13 21:15:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473E11B3311 for ; Wed, 13 May 2015 21:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AFJCylUx4c3 for ; Wed, 13 May 2015 21:15:21 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33D7C1ABD37 for ; Wed, 13 May 2015 21:15:21 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so246515wic.0 for ; Wed, 13 May 2015 21:15:20 -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=zT8E/SXHqM6qNxVrAXl+bn2GfUdWYmCSB3FCOFyFkjI=; b=aRFrjbz3+TaDjQ4YQkOsGzjNFo07hkQcZW+GaO9LfO+BKEBvpyzcfSw/Wi2A+xN8L+ peq90u9yQc/lIALeFY1SLn3gpvtPXWG2vOQA/7gtu8dxgztMno4BK9yS7cmXkz4JYBYy wuCCNnOK6ki1XAvFH/j8LiHPIt7i9Udx6Ov5MeXO/UQPhF+7PzhJlPnHKGXR7+TcaFzL JCy/J0oP5oPd5t29WSTCqGJaU+yww2O/aNDBFo/6BV5P94ufmm2NXqkROGpYWyO4KL2T uGBTcg0VpV7GkuZn1qRUfO80bM8ibUibhZgDLjghspQGQHFOug79/OaK/aGC/b7CSgeA BBTg== MIME-Version: 1.0 X-Received: by 10.180.19.134 with SMTP id f6mr44583049wie.35.1431576919974; Wed, 13 May 2015 21:15:19 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Wed, 13 May 2015 21:15:19 -0700 (PDT) In-Reply-To: <20150513160549.GV7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> Date: Wed, 13 May 2015 21:15:19 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 04:15:23 -0000 On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > On Wed, May 13, 2015 at 07:17:59AM -0700, Watson Ladd wrote: > > >> My take is that the public values being of the for xG + wM, where x > > >> should be a randomly and uniformly chosen scalar, the xG term will > > >> cause > > >> the public value to be as uniformly distributed as x regardless of > > >> how > > >> non-uniform w might be. So I think there's no harm in picking a > > >> simple > > >> mapping from the long-term key to w, provided there's a way to > > >> abstract > > >> this (see below). > > > > w is not distributed uniformly: far from it. The question of how far > > That depends on how its salted. For our purposes, in practice it's not. Not true: w comes from a much smaller list of values. If it was uniformly distributed over a wide range, we could use it as a key directly. > > > from uniform x may be distributed is a subtle one, but my guess is > > that even gross deviations from uniformity are fine, so taking a bunch > > of bytes mod the curve order is ok. But rejection sampling or modular > > reduction of longer strings are both easy to implement to sidestep > > this issue. > > That's what I thought. > > > SPAKE2 requires addition be supported. That rules out Kummer lines. > > The CFRG has not specified a model and how to encode points on that > > for addition to work. When they do I will modify the draft > > accordingly. > > > > However, I don't understand why the above abstraction isn't an > > implementation detail only. All one has to provide to use this draft > > are two generators and how to encode group elements. The algorithms > > for addition, multiplication etc. will be documented in the CFRG > > eventually. It's true that many groups only come with one canonical > > generator, but any sort of hashing method will give you two > > generators. > > It absolutely could be an implementation-only abstraction. If it will > be useful for many implementations though, it'd be useful to write that > up. In particular, adding curves to an implementation will be easy if > there is such an abstraction internally. Many implementations already have such a layer. I don't see how it's useful to write up: it's obvious, and doesn't affect interop. > > (This was in response to an off-list question by an implementor about > how to make it easy to add curves to their implementation given that > they are using OpenSSL, without first having to add them to OpenSSL. > Two simple answers are: don't, or add such an abstraction.) I believe OpenSSL does permit specifying parameters of arbitrary Weierstrass curves. In practice I don't know how useful that is. Or am I misunderstanding the question? Sincerely, Watson Ladd > > Nico > -- From nobody Wed May 13 21:19:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4929E1B3316 for ; Wed, 13 May 2015 21:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wb0Dpy-bwnPg for ; Wed, 13 May 2015 21:19:45 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D161B3314 for ; Wed, 13 May 2015 21:19:44 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-30-5554225feccc Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id ED.BC.03355.F5224555; Thu, 14 May 2015 00:19:43 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4E4Jhei013003; Thu, 14 May 2015 00:19:43 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4E4JeAK002613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2015 00:19:42 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4E4JeGu009318; Thu, 14 May 2015 00:19:40 -0400 (EDT) Date: Thu, 14 May 2015 00:19:40 -0400 (EDT) From: Benjamin Kaduk To: Watson Ladd In-Reply-To: Message-ID: References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42IR4hTV1o1XCgk16PhuYnF08yoWi1PXjrBZ 9HSeZHNg9nh56hyjx85Zd9k9liz5yRTAHMVlk5Kak1mWWqRvl8CVsf7WBNaCVpaKvYvPMTUw TmbuYuTkkBAwkdiytAHKFpO4cG89WxcjF4eQwGImifufGplAEkICGxkl5r9JhbAPMUn8X2cI UdTAKLF3ykZWkASLgLbEoXc97CA2m4CKxMw3G9lAbBEBdYkJyzexgNjMAlYSjb9bweLCAm4S Zz51MYLYnAKBEo+e3gar4RVwlDi9r5kVYtlyJokvt8EWiwroSKzePwWqRlDi5MwnUDO1JJZP 38YygVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYKDV5Jv B+PXg0qHGAU4GJV4eBU2BIUKsSaWFVfmHmKU5GBSEuXl5QsJFeJLyk+pzEgszogvKs1JLT7E KMHBrCTC+/9XcKgQb0piZVVqUT5MSpqDRUmcd9MPvhAhgfTEktTs1NSC1CKYrAwHh5IEb6si 0FDBotT01Iq0zJwShDQTByfIcB6g4VNAaniLCxJzizPTIfKnGHU57kz5v4hJiCUvPy9VSpy3 AaRIAKQoozQPbg4s6bxiFAd6S5j3ggJQFQ8wYcFNegW0hAloiWNcAMiSkkSElFQDo3bmL6db 4lOYNFyveX5ZmVsvfWfez3rzqs8ymTdPHJcry+DhqH2w7HabVMSz47vTWGUumjUnsJ5bu6P1 duS1FS/OfH5yvNEi/E1fmkai9zTTqLAbZb9K8tbM5c6PvrPm/irx01Xby8UnHGJ4ePXq3BUW izWTJ7iEmofx/q/bev1J4qnDqUt+xSuxFGckGmoxFxUnAgCN13X1FQMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 04:19:46 -0000 On Thu, 14 May 2015, Watson Ladd wrote: > On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > > > > > That depends on how its salted. For our purposes, in practice it's not. > > Not true: w comes from a much smaller list of values. If it was > uniformly distributed over a wide range, we could use it as a key > directly. In the scheme kitten is considering, w is an existing kerberos long-term (password-derived) key, so at least 128 bits and with no clear structure. -Ben From nobody Thu May 14 07:39:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2501B2B36 for ; Thu, 14 May 2015 07:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bP6s2-7_8g3F for ; Thu, 14 May 2015 07:39:39 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 262DE1B2B3A for ; Thu, 14 May 2015 07:39:35 -0700 (PDT) X-AuditID: 1209190e-f79a76d000000d1b-38-5554b3a6b620 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.6F.03355.6A3B4555; Thu, 14 May 2015 10:39:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4EEdYpK028981; Thu, 14 May 2015 10:39:34 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4EEdWxf009937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 14 May 2015 10:39:33 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4EEdVtl026900; Thu, 14 May 2015 10:39:31 -0400 (EDT) Date: Thu, 14 May 2015 10:39:31 -0400 (EDT) From: Benjamin Kaduk To: Watson Ladd In-Reply-To: Message-ID: References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPIsWRmVeSWpSXmKPExsUixCmqrbtsc0iowbdXphZHN69isejpPMnm wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGXMufmDtWCpcMWC84fZGxiP8ncxcnJICJhI tGw7wgphi0lcuLeerYuRi0NIYDGTxI9XSxkhnI2MEr/uLmWBcA4xSSz5tYUVwmlglNiy5DxY P4uAtsTTe6tZQGw2ARWJmW82soHYIgLqEhOWbwKLMwsIS6w/N4MZxBYWcJM486mLEcTmFHCS mLL1GhOIzSvgKLFqwzqoO+4ySez6swosISqgI7F6/xQWiCJBiZMzn0AN1ZJYPn0bywRGwVlI UrOQpBYwMq1ilE3JrdLNTczMKU5N1i1OTszLSy3SNdbLzSzRS00p3cQIDldJvh2MXw8qHWIU 4GBU4uF94RASKsSaWFZcmXuIUZKDSUmUt30dUIgvKT+lMiOxOCO+qDQntfgQowQHs5IIb90m oBxvSmJlVWpRPkxKmoNFSZx30w++ECGB9MSS1OzU1ILUIpisDAeHkgTvzo1AjYJFqempFWmZ OSUIaSYOTpDhPEDDi8CGFxck5hZnpkPkTzEqSonzPgVpFgBJZJTmwfXC0skrRnGgV4R5I0Da eYCpCK77FdBgJqDBlmFgg0sSEVJSDYzFgperua2LPU4effk0ekdIi++MqQxTOTlPRjZOZf69 5J60p76UnL2eYNmxZLev7nOCMwR2dLh38e5I+Zf6tNu225DJabfpwy8/lp4oqp1mE5XB5sEy 3+XGywd3RVvKbF6y1rf9OMRyKW95z8msjVtqj/g7fGlWKF528YDmvNRawQdqDNOfnFdiKc5I NNRiLipOBABUIB5MAgMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 14:39:46 -0000 On Thu, 14 May 2015, Benjamin Kaduk wrote: > On Thu, 14 May 2015, Watson Ladd wrote: > > > On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > > > > > > > > That depends on how its salted. For our purposes, in practice it's not. > > > > Not true: w comes from a much smaller list of values. If it was > > uniformly distributed over a wide range, we could use it as a key > > directly. > > In the scheme kitten is considering, w is an existing kerberos long-term > (password-derived) key, so at least 128 bits and with no clear structure. Now that I am awake (i.e., not falling asleep), I should clarify that w is planned to be the output of a KDF or PRF construction keyed on the kerberos long-term key I mentioned, not the key itself. (I don't think this was very clear in the -00, though, and we discussed it on the list a fair amount.) To give something of a summary of the propsal with background from kerberos: In kerberos, we have password-derived keys that are used for initial user authentication; the KDC ends up sending a response with session key, encrypted in the long-term password-derived key. (Sometimes the user sends a timestamp encrypted in that key as "pre-authentication".) Regardless, an attacker can easily get a ciphertext in this password-derived key, and since some users will always pick weak passwords, some of this traffic will succumb to a brute-force guessing attack. The proposal in draft-mccallum-kitten-krb-spake-preauth is to use SPAKE(2) as a zero-knowledge proof, not of the password itself, but rather of the password-derived kerberos key, so that existing kerberos deployments can seamlessly be upgraded to use this new preauthentication scheme which does not expose ciphertexts in the password-derived key to an attacker. As an additional feature, it allows for a second factor to be included in the key exchange in a fashion such that an attacker trying online guessing cannot tell which of the password or second factor was incorrect. So, the "password" input to spake is not the user's actual password, but rather this kerberos long-term password-derived key, which has already been through a salted PBKDF2 (or similar, for older enctypes). As is normal for use of long-term kerberos keys, it will go through a key-derivation step before being used. Hopefully that gives some background to the questions we were asking for input on. -Ben From nobody Thu May 14 08:47:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6851A854D for ; Thu, 14 May 2015 08:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TOsgqPdGIF7j for ; Thu, 14 May 2015 08:47:25 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id ABA941A710C for ; Thu, 14 May 2015 08:47:25 -0700 (PDT) Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 63A07940D0; Thu, 14 May 2015 08:47:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XnxVycGIPGIllU WxoAkO2uZN7Xs=; b=lnhbyojBg8bdmCUeX8QcjXeBOqK3v+A26yvFRXX9Dq0Ib9 hECkO0p1JYM/ipeYIeJOmbxFEVOMZqFBaDFp480KoQu/xmFSsCyCEmJ3fQk0BY8P CdMDFEh4NLmZBezwr7TE+ZlTZLkoBO49c3nQQpntexJNpkOgr1US1nQVd+o9Q= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPA id 2BDC9940C5; Thu, 14 May 2015 08:47:23 -0700 (PDT) Date: Thu, 14 May 2015 10:47:22 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20150514154721.GC7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:47:29 -0000 On Wed, May 13, 2015 at 09:15:19PM -0700, Watson Ladd wrote: > On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > > w is not distributed uniformly: far from it. The question of how far > > > > That depends on how its salted. For our purposes, in practice it's not. > > Not true: w comes from a much smaller list of values. If it was > uniformly distributed over a wide range, we could use it as a key > directly. For Kerberos (the context in which we're discussing SPAKE2) w would be derived from user principal long-term keys, which are basically a PBKDF2() application to the password and salt. The salt can in principle be uniformly distributed and randomly chosen, but it is public, so w has no more entropy than the password, but w can be as uniformly distributed as the salt. In practice the salt is not chosen randomly but derived from the user's principal name. So w does not (will not) be uniformly distributed. In any case, there's a big difference between "uniformly distributed" and "difficult to guess". We want a PAKE precisely because user principal long-term keys are derived from simple passwords and used to encrypt messages which are then subject to off-line dictionary attacks. Nico -- From nobody Thu May 14 08:52:42 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86321A872C for ; Thu, 14 May 2015 08:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I3pwm-ZBcGmQ for ; Thu, 14 May 2015 08:52:40 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 171191A8718 for ; Thu, 14 May 2015 08:52:40 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id DE05920047B88; Thu, 14 May 2015 08:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=HYt146+XEDb+sK NIVjC5a79YUFw=; b=OZ0VZpB9yh9fD1IfsQ75jMSDXWSmfmiGWdJI0tM7tVA1PY gMiukWm8pxePKggTCuTxERE3uWc+TrAdYhDK/UChpDOqajLZg+p2KxY8+wYiCHae B80KWsJ5BAGI8hAq/pglP0FX0Wby49JDFZYdtDmB9UJQBvMOJcAjtotlD6dL0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id 79F2520047B80; Thu, 14 May 2015 08:52:39 -0700 (PDT) Date: Thu, 14 May 2015 10:52:39 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20150514155238.GD7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:52:40 -0000 On Wed, May 13, 2015 at 09:15:19PM -0700, Watson Ladd wrote: > On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > It absolutely could be an implementation-only abstraction. If it will > > be useful for many implementations though, it'd be useful to write that > > up. In particular, adding curves to an implementation will be easy if > > there is such an abstraction internally. > > Many implementations already have such a layer. I don't see how it's > useful to write up: it's obvious, and doesn't affect interop. True. (But we must have a point representation, which per-CFRG is now part of each curve's specification. We have a point representation for Curve25519 for DH, but not yet for point addition.) > > (This was in response to an off-list question by an implementor about > > how to make it easy to add curves to their implementation given that > > they are using OpenSSL, without first having to add them to OpenSSL. > > Two simple answers are: don't, or add such an abstraction.) > > I believe OpenSSL does permit specifying parameters of arbitrary > Weierstrass curves. In practice I don't know how useful that is. Or am > I misunderstanding the question? The context is an implementation of Kerberos that would like such an abstraction so it can use curves not yet supported by OpenSSL, in particular Curve/Ed25519. Nico -- From nobody Thu May 14 08:54:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330B91A872C for ; Thu, 14 May 2015 08:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCVgxUkqAXEX for ; Thu, 14 May 2015 08:54:40 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75D611A872D for ; Thu, 14 May 2015 08:54:40 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so22393642wic.0 for ; Thu, 14 May 2015 08:54:39 -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=u2V/g5rGZ/km+bUout26ywD2OlLjoaABF30Ozkzh9sI=; b=WNiJZ3PzWJHCYJmFKCuVR4yCmbsk+SwyQ6PnhszQK+lH/sgur7xZu06YUel6ZSxmxe P3q+fT9mVsj3rTMYbEyLmXps6mc4AgUb702UCxrsPt0a93If0sLVrviSj68ZJDC8eRuN wFqgBz1r3Y2he5oSZibfhORFnVhIyR0OWpGY900ejWuOgZe3QCxhxTNc4OboFkitjdSZ OWEBtBa+ABEQWNuAwkCTDERbGUZkSjJqSn36s+jvKv3fxlKTVW1DxQSd0Z6Qy3EVWBFe +cPq/yfK4YfEt3hj3kjhMxG7T/znEMsiM3ww9uOpb7iNc3QdbE5/v8xVfmQso0B2KfnG E0kw== MIME-Version: 1.0 X-Received: by 10.194.123.4 with SMTP id lw4mr780000wjb.94.1431618879193; Thu, 14 May 2015 08:54:39 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Thu, 14 May 2015 08:54:39 -0700 (PDT) In-Reply-To: References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> Date: Thu, 14 May 2015 08:54:39 -0700 Message-ID: From: Watson Ladd To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 15:54:42 -0000 On Thu, May 14, 2015 at 7:39 AM, Benjamin Kaduk wrote: > On Thu, 14 May 2015, Benjamin Kaduk wrote: > >> On Thu, 14 May 2015, Watson Ladd wrote: >> >> > On May 13, 2015 9:05 AM, "Nico Williams" wrote: >> > > >> > > >> > > That depends on how its salted. For our purposes, in practice it's not. >> > >> > Not true: w comes from a much smaller list of values. If it was >> > uniformly distributed over a wide range, we could use it as a key >> > directly. >> >> In the scheme kitten is considering, w is an existing kerberos long-term >> (password-derived) key, so at least 128 bits and with no clear structure. > > Now that I am awake (i.e., not falling asleep), I should clarify that w is > planned to be the output of a KDF or PRF construction keyed on the > kerberos long-term key I mentioned, not the key itself. (I don't think > this was very clear in the -00, though, and we discussed it on the list a > fair amount.) > > To give something of a summary of the propsal with background from > kerberos: > > In kerberos, we have password-derived keys that are used for initial user > authentication; the KDC ends up sending a response with session key, > encrypted in the long-term password-derived key. (Sometimes the user > sends a timestamp encrypted in that key as "pre-authentication".) > Regardless, an attacker can easily get a ciphertext in this > password-derived key, and since some users will always pick weak > passwords, some of this traffic will succumb to a brute-force guessing > attack. Yes, which implies that it is not uniformly distributed over the whole domain of strings of the length of w. Uniform distribution means uniform: if it only ever takes on values in some subset, it isn't uniform. The fact that guessing attacks are possible demonstrates, that after conditioning on public values, it isn't uniform over the entire range. > > The proposal in draft-mccallum-kitten-krb-spake-preauth is to use SPAKE(2) > as a zero-knowledge proof, not of the password itself, but rather of the > password-derived kerberos key, so that existing kerberos deployments can > seamlessly be upgraded to use this new preauthentication scheme which does > not expose ciphertexts in the password-derived key to an attacker. As an > additional feature, it allows for a second factor to be included in the > key exchange in a fashion such that an attacker trying online guessing > cannot tell which of the password or second factor was incorrect. So, the > "password" input to spake is not the user's actual password, but rather > this kerberos long-term password-derived key, which has already been > through a salted PBKDF2 (or similar, for older enctypes). As is normal > for use of long-term kerberos keys, it will go through a key-derivation > step before being used. > > Hopefully that gives some background to the questions we were asking for > input on. > > -Ben -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu May 14 09:11:04 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923971A87A4 for ; Thu, 14 May 2015 09:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtMvxGC7sitq for ; Thu, 14 May 2015 09:11:01 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 63D0E1A87A9 for ; Thu, 14 May 2015 09:10:58 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 3F089540A5; Thu, 14 May 2015 09:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=XqZDSKd0aNaMWz OBU//asyf6L78=; b=hGRU3jTQ94ewkGwVUIvSJneogLK17xOA+6Xj65LHpQHsMA Q1JgiaMplO6QZw/o84xMhWN04z+nrJRSHbIJKrLlkMR4q2DjGqUs1DIEMZgSebdx ULh4YhPO4mEPFkD0kRIVLn/IltsfnF/SKAKRhaJUfidGCosLfFW1189iJAFv0= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPA id 9DA345408A; Thu, 14 May 2015 09:10:57 -0700 (PDT) Date: Thu, 14 May 2015 11:10:56 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20150514160556.GE7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:11:02 -0000 On Thu, May 14, 2015 at 08:54:39AM -0700, Watson Ladd wrote: > Yes, which implies that it is not uniformly distributed over the whole > domain of strings of the length of w. Uniform distribution means > uniform: if it only ever takes on values in some subset, it isn't > uniform. The fact that guessing attacks are possible demonstrates, > that after conditioning on public values, it isn't uniform over the > entire range. OK, fair enough, but what about x. How critical is it that it be uniformly distributed? You answered "The question of how far from uniform x may be distributed is a subtle one, but my guess is that even gross deviations from uniformity are fine, so taking a bunch of bytes mod the curve order is ok." Can you refine this answer? My guess is that indeed, x's uniformity is not that important, because if it were a well-known constant then this protocol devolves into one where the attacker still has to mount an off-line dictionary attack in order to recover w and session keys, so as the range of x choices improves, the attacker's position worsens. But if we add in timing side channels then x's "gross deviation" from unifomity might yield more information, no? Nico -- From nobody Thu May 14 09:26:15 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA881A8860 for ; Thu, 14 May 2015 09:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDsTrE5jng3v for ; Thu, 14 May 2015 09:26:13 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D88E41A885A for ; Thu, 14 May 2015 09:26:13 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 985EA20047B8D for ; Thu, 14 May 2015 09:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZNRAvkiVeI1ZgY8UwDvt RgOVgMg=; b=ZvYLzJJulb5qfg1DVCtufP/sYme0RQHK9Sg0sD0e2e6DntBcQ3if uMOIpQ1cKpDuQCKJh+fpWuBmIFOtTJHu5gUKTT8F9OAGx/IwctI9hqSTae1Yv4Um MZeOtYMv7TURMlizlzBsJckwjO642d1qlwqevOm/T0xIqcRewF1Q5Ng= Received: from mail-yh0-f44.google.com (mail-yh0-f44.google.com [209.85.213.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPSA id 7CCE620047B8C for ; Thu, 14 May 2015 09:26:13 -0700 (PDT) Received: by yhom41 with SMTP id m41so23857124yho.1 for ; Thu, 14 May 2015 09:26:11 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.170.144.212 with SMTP id l203mr5795161ykc.128.1431620771644; Thu, 14 May 2015 09:26:11 -0700 (PDT) Received: by 10.13.253.3 with HTTP; Thu, 14 May 2015 09:26:11 -0700 (PDT) In-Reply-To: <20150514160556.GE7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> <20150514160556.GE7287@localhost> Date: Thu, 14 May 2015 11:26:11 -0500 Message-ID: From: Nico Williams To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2015 16:26:14 -0000 OTOH, I think we need timing side-channel-free curve implementations anyways, which means that as long as x is chosen randomly and somewhat uniformly, it will do. From nobody Mon May 18 03:17:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE3D1A887F for ; Mon, 18 May 2015 03:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SN2NHhToWGFs for ; Mon, 18 May 2015 03:17:30 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D08621A887E for ; Mon, 18 May 2015 03:17:30 -0700 (PDT) Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4IAHSGI026380; Mon, 18 May 2015 06:17:28 -0400 Date: Mon, 18 May 2015 06:17:26 -0400 (EDT) From: Simo Sorce To: Nico Williams Message-ID: <1093182203.442448.1431944246604.JavaMail.zimbra@redhat.com> In-Reply-To: <20150514154721.GC7287@localhost> References: <20150512214740.GT7287@localhost> <1431525091.3260.26.camel@redhat.com> <20150513160549.GV7287@localhost> <20150514154721.GC7287@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.4.164.1, 10.5.100.50] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922) Thread-Topic: SPAKE preauth: generation of SPAKE2 secret input Thread-Index: /spYlvA/dkjSrHFqQ7PlKqQi4xSIQA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2015 10:17:32 -0000 ----- Original Message ----- > From: "Nico Williams" > To: "Watson Ladd" > Cc: kitten@ietf.org > Sent: Thursday, May 14, 2015 5:47:22 PM > Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input > > On Wed, May 13, 2015 at 09:15:19PM -0700, Watson Ladd wrote: > > On May 13, 2015 9:05 AM, "Nico Williams" wrote: > > > > w is not distributed uniformly: far from it. The question of how far > > > > > > That depends on how its salted. For our purposes, in practice it's not. > > > > Not true: w comes from a much smaller list of values. If it was > > uniformly distributed over a wide range, we could use it as a key > > directly. > > For Kerberos (the context in which we're discussing SPAKE2) w would be > derived from user principal long-term keys, which are basically a > PBKDF2() application to the password and salt. The salt can in > principle be uniformly distributed and randomly chosen, but it is > public, so w has no more entropy than the password, but w can be as > uniformly distributed as the salt. > > In practice the salt is not chosen randomly but derived from the user's > principal name. So w does not (will not) be uniformly distributed. This is not so clear cut, and depend on deployments. A truly random "special" salt can be used (and in fact we use it in FreeIPA), and there is also the sad situation with the RC4-HMAC key that is not salted at all ... This is just nitpicking, but hows that we have a wide range of different keys we may end up using in deployments and we cannot assume uniformity even if in some cases we may get quite close. Simo. > In any case, there's a big difference between "uniformly distributed" > and "difficult to guess". We want a PAKE precisely because user > principal long-term keys are derived from simple passwords and used to > encrypt messages which are then subject to off-line dictionary attacks. > > Nico > -- > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- -- Simo Sorce * Red Hat, Inc. * New York From nobody Tue May 19 09:16:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAAF1ABD3A for ; Tue, 19 May 2015 09:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.511 X-Spam-Level: X-Spam-Status: No, score=-1.511 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tlZHQ1GesNJ for ; Tue, 19 May 2015 09:16:49 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB34F1AC444 for ; Tue, 19 May 2015 09:14:49 -0700 (PDT) X-AuditID: 1209190d-f79676d000000da0-e2-555b6178df47 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id BB.9E.03488.8716B555; Tue, 19 May 2015 12:14:48 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t4JGEmRg020597; Tue, 19 May 2015 12:14:48 -0400 Received: from [18.101.8.189] (vpn-18-101-8-189.mit.edu [18.101.8.189]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4JGEkhj030585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 12:14:47 -0400 Message-ID: <555B6176.2000906@mit.edu> Date: Tue, 19 May 2015 12:14:46 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6noluRGB1qsHOXicXRzatYLHo6T7I5 MHnsnHWX3WPJkp9MAUxRXDYpqTmZZalF+nYJXBl79zWyFTyRrPh6/xZLA+MH4S5GTg4JAROJ mT9OMULYYhIX7q1n62Lk4hASWMwkcexXBwuEs5FRovfnJUYI5wiTxL8XV5hAWngF1CRmn9nN BmKzCKhKHJrxhBnEZhNQlli/fysLiC0qECYx7fdzVoh6QYmTM5+AxUUEhCV2b30HVs8soC7R PO82WFxYIEJi8aXzYPOFBAwlWo/0g53HKWAksfT7cTaIej2JHdd/sULY8hLNW2czT2AUnIVk xSwkZbOQlC1gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6SXm1mil5pSuokRFMKckrw7GN8d VDrEKMDBqMTDG1kfFSrEmlhWXJl7iFGSg0lJlHdadHSoEF9SfkplRmJxRnxRaU5q8SFGCQ5m JRHeqVFAOd6UxMqq1KJ8mJQ0B4uSOO+mH3whQgLpiSWp2ampBalFMFkZDg4lCd4L8UCNgkWp 6akVaZk5JQhpJg5OkOE8QMPPg9TwFhck5hZnpkPkTzEqSonzWiYAJQRAEhmleXC9sBTzilEc 6BVhXiGQKh5geoLrfgU0mAlosMm2SJDBJYkIKakGxmsKZ9deP7A0THu/xnN9xTf+3MdL19wp 8WG4orVdcn6yRmVi+VkTXUkPxsiDJo2d+pOafeveLBDd0D7F7HrnhYm2h0q/iHV5tDKsMVuk 1z3rTMUC/Yd/9k3bvu3iCbZm3zOaGTrRP/vPHkxqMkzSEjpVxV1yLTr5kxY7r+WejQFbO65u nl04WYmlOCPRUIu5qDgRAJkXbZkMAwAA Archived-At: Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 16:16:50 -0000 Based on the results of this discussion, here is the wording I came up with for my pull request. In the prerequisites section: Both KDCs and clients MUST implement one or more groups for which the discrete logarithm problem is hard, each with an corresponding object identifer. Group object identifiers MUST refer to one of the following: o One of the eight elliptic curves specified in [SEC2] section 2, using the corresponding object identifier from appendix A.2.1. o A group with an unambiguous specification for representing group elements as octet strings, and an unambiguous specification for converting an octet string of a specific length into an integer for use as a scalar multiplier. and then in a new section titled "SPAKE Parameters and Conversions": The SPAKE algorithm requires a shared secret input w to be used as a scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2). This value MUST be produced from the client principal's long-term key as follows: 1. Determine a scalar octet string input length for the chosen group. For SEC 2 curves over a prime field F(p), this is ceil(log2(p)/8). For other groups, this length is specified by the group. 2. Produce an octet string of the above length with PRF+(K, "SPAKEsecret"), where K is the long-term key and PRF+ is defined in [RFC6113] section 5.1. 3. If the chosen group is secp521r1, set the high seven bits of the first byte to 0 so that there are at most 521 significant bits in the octet string. 4. For SEC 2 curves, decode the octet string as a big-endian positive integer as specified in [SEC1] section 2.3.8. For other groups, decode the octet string as specified by the group. Salient points: * SEC 2 curves over Fp (which include NIST P-256/P-384/P-521) get to use existing OIDs with conversions specified in this draft, using SEC 1 encoding primitives. Other groups need to use an OID which unambiguously specifies the needed conversions. I expect the forthcoming CFRG curves to slot in here, although I'm not sure if they plan to designate OIDs for their curves. * Because the eight SEC 2 curves all have cofactor 1, we don't have to worry about cofactors in the conversions we specify. Except for secp521r1, they all use primes close to a power of 2^8. * The w values won't be uniformly distributed even if the long-term key is. But as Watson noted, SPAKE doesn't assume that w is uniformly distributed. * A small proportion of w values will be larger than the group order. Implementations need to be able to handle these values correctly and without side channels. I will try to make a note of this in the security considerations, and will try to make sure that there are test vectors exercising this possibility. OpenSSL contains P-256 and P-521 implementations which are supposed to be constant-time if the input bignum doesn't contain more than 256 or 521 significant bits respectively. * It's possible, though vanishingly unlikely, for w to be equal to 0 or to the group order. I believe all of the computations should work in this case, so there is no need to reject those values. From nobody Tue May 19 12:02:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96C81A9071 for ; Tue, 19 May 2015 12:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4YzRvgqrxfY for ; Tue, 19 May 2015 12:02:22 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 71D6F1AD0A4 for ; Tue, 19 May 2015 12:01:12 -0700 (PDT) Received: from homiemail-a32.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTP id 130C0584078; Tue, 19 May 2015 12:01:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=DPBFowv8YUu8+c 75r53j/TzjDMs=; b=N007dvDBuyMX3pJM5Zt6BmW9+9ROTKdx8iRO1oMKNTu8+K Dz1MEObKB6hPxZM5B81AFbGvzBLu4CLDgJHkOZbqRM+fbS3cnh+5uTjzdPnzZLBJ luan7fJbNNW9xVqRkqQox6s6T2gJ3L7e9Fj+btYcKf17ENEgFnF+iQMSoiB7I= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a32.g.dreamhost.com (Postfix) with ESMTPA id 55C57584075; Tue, 19 May 2015 12:01:11 -0700 (PDT) Date: Tue, 19 May 2015 14:01:09 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20150519190109.GM9922@localhost> References: <555B6176.2000906@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555B6176.2000906@mit.edu> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:02:24 -0000 On Tue, May 19, 2015 at 12:14:46PM -0400, Greg Hudson wrote: > Salient points: > > * SEC 2 curves over Fp (which include NIST P-256/P-384/P-521) get to use > existing OIDs with conversions specified in this draft, using SEC 1 > encoding primitives. Other groups need to use an OID which > unambiguously specifies the needed conversions. I expect the > forthcoming CFRG curves to slot in here, although I'm not sure if they > plan to designate OIDs for their curves. Notionally each curve should have its own conversions. > * Because the eight SEC 2 curves all have cofactor 1, we don't have to > worry about cofactors in the conversions we specify. Except for > secp521r1, they all use primes close to a power of 2^8. Sure. > * A small proportion of w values will be larger than the group order. > Implementations need to be able to handle these values correctly and > without side channels. I will try to make a note of this in the > security considerations, and will try to make sure that there are test > vectors exercising this possibility. OpenSSL contains P-256 and P-521 > implementations which are supposed to be constant-time if the input > bignum doesn't contain more than 256 or 521 significant bits respectively. We do have to specify what this conversion is. We can't merely refer to OpenSSL. If need be use w' = truncate(H(w), floor(log2(group_order / cofactor))). We don't need w or w' to be particularly strong (that's the point of using a PAKE), so this should be just fine. > * It's possible, though vanishingly unlikely, for w to be equal to 0 or > to the group order. I believe all of the computations should work in > this case, so there is no need to reject those values. Agreed. Nico -- From nobody Tue May 19 12:09:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433D01AD0AC for ; Tue, 19 May 2015 12:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIj2uVE6-6pX for ; Tue, 19 May 2015 12:09:22 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C4241AD0A6 for ; Tue, 19 May 2015 12:09:22 -0700 (PDT) Received: by wgjc11 with SMTP id c11so28857694wgj.0 for ; Tue, 19 May 2015 12:09:21 -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=db7V2D7fIpNPc410mAb6LQlIL5r7c13Rb4qFNzdyeWI=; b=feFW1jusWOjigY7wCtkGMjijsi5+lt8sNDDG/MhBRJLyMzavR7BxeMB5ipcwo4gyUJ +L0CYuhe/wA+BJ3CMKgwqHc1T671Qe5j5CLC4TwQTZj2xTIQr4V4QNNxTBz8PeohhbMs nwGShLf26SNWc5YOlaCUTRAejTiNvJKN7LWzBriNo30bUOsqG61SNeurDtZwt4E3hes2 nllcfxhIYrs8ARAXHnIgrcM5qF+QG/f79+xhTvO6qrNH38Go/pePB2/JkA+xFqBHRJWP dz0uXNEijcJJ2RJAbkR5v/cphT4HDE7a2FWeokVlhiX6G2+oHutec7PSModhoOUwddLU PnSQ== MIME-Version: 1.0 X-Received: by 10.180.187.141 with SMTP id fs13mr34729786wic.26.1432062561044; Tue, 19 May 2015 12:09:21 -0700 (PDT) Received: by 10.194.20.97 with HTTP; Tue, 19 May 2015 12:09:20 -0700 (PDT) In-Reply-To: <555B6176.2000906@mit.edu> References: <555B6176.2000906@mit.edu> Date: Tue, 19 May 2015 12:09:20 -0700 Message-ID: From: Watson Ladd To: Greg Hudson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 19:09:24 -0000 On Tue, May 19, 2015 at 9:14 AM, Greg Hudson wrote: > Based on the results of this discussion, here is the wording I came up > with for my pull request. In the prerequisites section: > > Both KDCs and clients MUST implement one or more groups for which the > discrete logarithm problem is hard, each with an corresponding object > identifer. Group object identifiers MUST refer to one of the > following: > > o One of the eight elliptic curves specified in [SEC2] section 2, > using the corresponding object identifier from appendix A.2.1. > > o A group with an unambiguous specification for representing group > elements as octet strings, and an unambiguous specification for > converting an octet string of a specific length into an integer > for use as a scalar multiplier. My draft does not have M and N for binary curves. There are only three curves in my draft IIRC. My draft completely describes each parameter, and gives it a name. > > and then in a new section titled "SPAKE Parameters and Conversions": > > The SPAKE algorithm requires a shared secret input w to be used as a > scalar multiplier (see [I-D.irtf-cfrg-spake2] section 2). This value > MUST be produced from the client principal's long-term key as > follows: > > 1. Determine a scalar octet string input length for the chosen > group. For SEC 2 curves over a prime field F(p), this is > ceil(log2(p)/8). For other groups, this length is specified by > the group. > > 2. Produce an octet string of the above length with PRF+(K, > "SPAKEsecret"), where K is the long-term key and PRF+ is defined > in [RFC6113] section 5.1. > > 3. If the chosen group is secp521r1, set the high seven bits of the > first byte to 0 so that there are at most 521 significant bits in > the octet string. > > 4. For SEC 2 curves, decode the octet string as a big-endian > positive integer as specified in [SEC1] section 2.3.8. For other > groups, decode the octet string as specified by the group. I feel as though I should rework the draft to specify the length of an octet string and how to treat it, but I think this was already done elsewhere. (I.e. step 2 would need to be done, but all others in my draft) > > Salient points: > > * SEC 2 curves over Fp (which include NIST P-256/P-384/P-521) get to use > existing OIDs with conversions specified in this draft, using SEC 1 > encoding primitives. Other groups need to use an OID which > unambiguously specifies the needed conversions. I expect the > forthcoming CFRG curves to slot in here, although I'm not sure if they > plan to designate OIDs for their curves. OIDs are not unique per object. > > * Because the eight SEC 2 curves all have cofactor 1, we don't have to > worry about cofactors in the conversions we specify. Except for > secp521r1, they all use primes close to a power of 2^8. > > * The w values won't be uniformly distributed even if the long-term key > is. But as Watson noted, SPAKE doesn't assume that w is uniformly > distributed. > > * A small proportion of w values will be larger than the group order. > Implementations need to be able to handle these values correctly and > without side channels. I will try to make a note of this in the > security considerations, and will try to make sure that there are test > vectors exercising this possibility. OpenSSL contains P-256 and P-521 > implementations which are supposed to be constant-time if the input > bignum doesn't contain more than 256 or 521 significant bits respectively. The easy fix here is to truncate. > > * It's possible, though vanishingly unlikely, for w to be equal to 0 or > to the group order. I believe all of the computations should work in > this case, so there is no need to reject those values. From nobody Tue May 19 16:51:34 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27F5E1A8724 for ; Tue, 19 May 2015 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnTwyrheQgxX for ; Tue, 19 May 2015 16:51:30 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB9B91A8FD5 for ; Tue, 19 May 2015 16:51:12 -0700 (PDT) X-AuditID: 12074425-f79ca6d000000e5e-2a-555bcc6f68bc Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 84.D1.03678.F6CCB555; Tue, 19 May 2015 19:51:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4JNpB3K024033; Tue, 19 May 2015 19:51:11 -0400 Received: from [18.101.8.169] (vpn-18-101-8-169.mit.edu [18.101.8.169]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4JNp7dh019957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 19 May 2015 19:51:09 -0400 Message-ID: <555BCC6B.9070409@mit.edu> Date: Tue, 19 May 2015 19:51:07 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Watson Ladd References: <555B6176.2000906@mit.edu> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrZt/JjrU4PM/PYujm1exWPR0nmRz YPLYOesuu8eSJT+ZApiiuGxSUnMyy1KL9O0SuDKenfjCXDBNumJ/yz7GBsZlol2MnBwSAiYS W7etZoOwxSQu3FsPZHNxCAksZpLYMqmPEcLZyChxdPNRqMwRJok5dy+ygLTwCqhJfH01l72L kYODRUBV4tqqWpAwm4CyxPr9W8FKRAXCJKb9fs4KUS4ocXLmE7C4iIC6xITlm8BsZgFhiQvb 94LVCAtESCy+dJ4JYtdERonpz14ygyQ4BQIl1j7YxwzRoC7xZ94lKFteonnrbOYJjIKzkOyY haRsFpKyBYzMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3Qt9HIzS/RSU0o3MYJCmN1FdQfjhENK hxgFOBiVeHhPHIoOFWJNLCuuzD3EKMnBpCTKe+M4UIgvKT+lMiOxOCO+qDQntfgQowQHs5II 76yZQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQlet9NAjYJFqemp FWmZOSUIaSYOTpDhPEDDJUBqeIsLEnOLM9Mh8qcYFaXEeXVAEgIgiYzSPLheWIp5xSgO9Iow ryxIFQ8wPcF1vwIazAQ02GRbJMjgkkSElFQDI0/coXMn862DrWRDX1Ru+6Rz/ZfFxV/cv5+c NO4V59TYl7jbW6d38p+EF1rTdb7VNl2KvnSk1DDrhZHfy/PiOTdPHWAr7q2/XRYgaVRjyjXH dI7LjLbiWluj7cIbzM94Cl4Nl+MzLWU/sPqjraPtkS33DordnmjuvTiaz/foz0eNKw6ua19W psRSnJFoqMVcVJwIAGls+34MAwAA Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] SPAKE preauth: generation of SPAKE2 secret input (proposed text) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 May 2015 23:51:32 -0000 On 05/19/2015 03:09 PM, Watson Ladd wrote: >> o One of the eight elliptic curves specified in [SEC2] section 2, >> using the corresponding object identifier from appendix A.2.1. >> >> o A group with an unambiguous specification for representing group >> elements as octet strings, and an unambiguous specification for >> converting an octet string of a specific length into an integer >> for use as a scalar multiplier. > > My draft does not have M and N for binary curves. There are only three > curves in my draft IIRC. My draft completely describes each parameter, > and gives it a name. I've been operating under the assumption that M and N can be computed for other curves as long as they have assigned OIDs. The risk of interoperability failures from people getting it subtly wrong might be kind of high, though. I don't have an objection if we want to limit ourselves to curves explicitly listed in the spake2 document (or follow-on SPAKE2 documents), but it's a greater departure from Nathaniel's intent. F2m curves (I assume that's what you mean by "binary curves") are documented in SEC 2 section 3, not in section 2. I don't think we need to support those. >> 1. Determine a scalar octet string input length [...] >> 2. Produce an octet string of the above length with PRF+ [...] >> 3. If the chosen group is secp521r1, set the high seven bits [...] >> 4. For SEC 2 curves, decode the octet string as a big-endian [...] > I feel as though I should rework the draft to specify the length of an > octet string and how to treat it, but I think this was already done > elsewhere. (I.e. step 2 would need to be done, but all others in my > draft) There's RFC 6979 section 3.2, but it would introduce a significant side channel if applied here. I would be happy to delegate steps 3 and 4 to another document if there is a suitable reference. >> [...] I expect the >> forthcoming CFRG curves to slot in here, although I'm not sure if they >> plan to designate OIDs for their curves. > > OIDs are not unique per object. Can you elaborate on this? >> * A small proportion of w values will be larger than the group order. >> Implementations need to be able to handle these values [...] > The easy fix here is to truncate. You mean lop off the high bit? We could do that, but I'm not sure if it's needed. I think 25519's scalar preprocessing generates scalar values up to eight times the subgroup order, for comparison. (2^254+(2^251-1)*8 / 2^252+27742317777372353535851937790883648493 ~= 8.) Nico wrote: > We do have to specify what this conversion is. We can't merely refer to > OpenSSL. I'm not referring to OpenSSL for semantics. Mathematically, scalar multiplication within a group is defined for any non-negative value of the scalar. If an implementation can't handle values above a certain size, or has side channels for values above a certain size, that is an implementation limit. I just brought up OpenSSL as an example of implementation limits compatible with my proposed method. > If need be use w' = truncate(H(w), floor(log2(group_order / cofactor))). > We don't need w or w' to be particularly strong (that's the point of > using a PAKE), so this should be just fine. I'm not sure why we would want to introduce another hash invocation. w is already the output of a PRF; we can truncate it to any desired size. From nobody Thu May 21 07:52:41 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F141A1BB3; Thu, 21 May 2015 07:52:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.211 X-Spam-Level: X-Spam-Status: No, score=-14.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zypLwmXVsip; Thu, 21 May 2015 07:52:39 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9DC71A1B7F; Thu, 21 May 2015 07:52:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=896; q=dns/txt; s=iport; t=1432219960; x=1433429560; h=message-id:date:from:mime-version:to:cc:subject: content-transfer-encoding; bh=sVMBQ56vs0mTbExdLZxAyOGrPNZBmqoroMAQidSErfk=; b=hTTXI2DoRhEludvjhJ+6fAYDK582pLvYRyINlGSR0hGd3dB9MNMx2C6D XzqBz6MdDyuOzQD4tvsR2NBNG6+jpwCn6MvcW4UXi+5MGkGAD2stzX6SI BT6wMHqhrTDkA9UHAu8DZzqZslMDWb5C7ZjVLdvXzZNYHX8pBGYG5VxvV E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BeCAB18F1V/40NJK1cgxBUXgaDGb9wCYFRhX+BRDgUAQEBAQEBAYEKQQWDXycPAUY1AgUhAhECNhYNAQUCAQGIKK1CpBoBAQEBAQEBAwEBAQEBAQEBFgSBIY8egm+BRQWMOYp0hlSBKINrgl2LVINZI4IJHYFxUIFGgQEBAQE X-IronPort-AV: E=Sophos;i="5.13,469,1427760000"; d="scan'208";a="765982" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP; 21 May 2015 14:52:39 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4LEqblT026335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 May 2015 14:52:38 GMT Received: from [10.129.24.109] (10.129.24.109) by xhc-rcd-x05.cisco.com (173.37.183.79) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 21 May 2015 09:52:37 -0500 Message-ID: <555DF135.50302@cisco.com> Date: Thu, 21 May 2015 08:52:37 -0600 From: =?UTF-8?B?4oyYIE1hdHQgTWlsbGVy?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kitten WG Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.129.24.109] Archived-At: Cc: Kitten WG Chairs Subject: [kitten] Meeting in Prague X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2015 14:52:40 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, IETF 93 is in Prague, from July 19-24. The chairs are requesting a session slot for this Meeting. Please provide any agenda items, either to the list or to < kitten-chairs@ietf.org >, by June 3. Thank you, - - Your kitten chairs \ /\ ) ( ') ( / ) \(__)| -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVXfE1AAoJEDWi+S0W7cO1FHgH/jEPuRBdQCpECMV+CxtMIYjq TNRHNlG1n5JJMiz3KGUIh2TBWimg603vbiti9wRALapP9N11biJBUDeCzoof1zxm 5P7zcMmxd4JO50Jrh+lJ46QxPpx+kfakZ/kD/5rnO7EIBkYCRUECEkvEjSxotODg fXfGdiID+wvXNaA7U88AZ/QCJSc27Cx4cAtPun4wTGbDlHr6MDxe3+7FSJL6aWG9 0cgxpnPKWfaf+gowWBk9PDMF+9ay6+0GCQnqtZOUQ/HEoxGF5yyHqhLkkRcy8FJ8 AMCF7CCqLdSMYaT6R5/R46OwgzBYVj/cDdByFQNDEQBFnv3C6Rbom7uBHW5S/wE= =KfYa -----END PGP SIGNATURE----- From nobody Fri May 22 17:17:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A1EE1A87DF for ; Fri, 22 May 2015 17:17:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omSPnB5tkZZl for ; Fri, 22 May 2015 17:17:43 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3851A82E2 for ; Fri, 22 May 2015 17:17:43 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 427cf555.0.3309587.00-2350.8869247.nbfkord-smmo05.seg.att.com (envelope-from ); Sat, 23 May 2015 00:17:43 +0000 (UTC) X-MXL-Hash: 555fc727590aad44-9e2c28615b837dc9c5d6baf74420ecf2f9eb9f57 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GdqZ027455 for ; Fri, 22 May 2015 20:16:39 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0Ga3c027451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 22 May 2015 20:16:39 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Sat, 23 May 2015 00:16:23 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GOcq009460 for ; Fri, 22 May 2015 20:16:24 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4N0GJmY009322 for ; Fri, 22 May 2015 20:16:19 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.240.65](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150523001618gw1000cebve>; Sat, 23 May 2015 00:16:19 +0000 X-Originating-IP: [135.110.240.65] Message-ID: <555FC6CF.5020306@att.com> Date: Fri, 22 May 2015 20:16:15 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Alexey Melnikov , Simon Josefsson References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> In-Reply-To: <54F4B8B8.8090406@isode.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=b/AFFK6x c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=5hWoPXNsKEoA:10 a=ZXRAoOSSXYMA:10 a=BLceEmwcHowA:10 a=N65] X-AnalysisOut: [9UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=48vgC7mU] X-AnalysisOut: [AAAA:8 a=_EUyUsmAwj7DJXm3ejQA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 00:17:45 -0000 On 3/2/15 2:23 PM, Alexey Melnikov wrote: > > On 25/02/2015 15:25, Simon Josefsson wrote: >> Tony Hansen writes: >> >>> On 2/24/15 6:56 AM, Stephen Farrell wrote: >>>> But in addition, there were two substantive issues that ought be >>>> resolved before IETF LC: >>>> >>>> 1. a new channel binding or requiring tls-session-hash (and I guess >>>> some explanatory text about why that is good/needed) >>> To recap: >>> >>> Simon Josefsson made this comment: >>> >>>> Since SCRAM was published, we have learned that the tls-unique channel >>>> binding is insecure -- it would be nice if we could combine the SHA256 >>>> update with another default channel binding type to resolve that >>>> problem. In my view, the problem with SCRAM today isn't primarily its >>>> use of SHA1 but it's broken channel binding. >>> Martin Thompson responded: >>> >>>> We have a solution for that: >>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash >>> I've read through tls-session-hash and am unsure how to proceed here. >>> >>> One of my goals when proposing SCRAM-SHA-256 was to not change the >>> protocol at all, other than updating the hash algorithm. >>> >>> I'm not sure how to incorporate a recommendation for session hashing >>> here. I'm thinking this would be best handled by adding something to >>> the Security Considerations section. Does that seem right? >>> >>> Would anyone be willing to suggest text changes for these comments? >> I believe the problem is that RFC 5802 is insecure as currently >> specified, and we are bringing this up as a problem with your draft, >> which is unfair to you since the problem was not introduced by you. >> >> If people like the tls-session-hash approach (I'm not in that category, >> but there may be consensus around it), the proper fix is to update RFC >> 5802 and reference tls-session-hash as a normative reference. This will >> take care of the problem, as you could copy that text into your >> document. If you are looking for a text change here, it would be: >> >> To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel >> that >> MUST have [TLS-SESSION-HASH] negotiated. >> >> Personally, I would prefer to change to another mandatory channel >> binding that is secure for all TLS versions. > Before we make the decisions between referencing tls-session-hash > versa a new channel binding, can you sketch out how the new channel > binding is going to be defined? > > (If we choose to define a new channel binding, I think Kitten WG is > the right place for doing this work.) I added the following to the security section: > The strength of this mechanism is dependent in part on the hash-iteration count, as denoted by "i" in > . > As a rule of thumb, the hash-iteration count should be such that a modern machine will take 0.1 seconds > to perform the complete algorithm; however this is unlikely to be practical on mobile devices and > other relatively low-performance systems. > At the time this was written, the rule of thumb gives around 15,000 iterations required; > however an iteration count of 4096 takes around 0.5 seconds on current mobile handsets. > This computational cost can be avoided by caching the ClientKey (assuming the Salt and iteration count is stable). > Therefore the recommendation of this specification is that the iteration count SHOULD be at least 4096, but careful > consideration ought to be given to using a significantly higher value, particularly where mobile use is less important. If anyone has suggestions for additions to this, or changes, please suggest it now. Tony Hansen From nobody Fri May 22 23:07:28 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F81A90E2; Fri, 22 May 2015 23:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.56 X-Spam-Level: X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmAdDZGomZ4W; Fri, 22 May 2015 23:07:22 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A08A1A90D7; Fri, 22 May 2015 23:07:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.13,480,1427752800"; d="asc'?scan'208";a="126053707" Received: from 178.92.69.86.rev.sfr.net (HELO [192.168.1.44]) ([86.69.92.178]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 23 May 2015 08:07:19 +0200 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Karthikeyan Bhargavan In-Reply-To: <20150216115457.3c16fdbf@latte.josefsson.org> Date: Sat, 23 May 2015 08:07:17 +0200 Message-Id: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , Martin Thomson , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 06:07:27 -0000 --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 >> We have a solution for that: >> https://tools.ietf.org/html/draft-ietf-tls-session-hash If a TLS connection uses the tls-session-hash, the tls-unique channel = binding becomes a good channel identifier for use in SCRAM (avoiding Triple = Handshake-style attacks). So either SCRAM could require tls-session-hash, or we could update = RFC5929 to require it (in the same way that it already requires RFC5746). I have a separate question: would there be value in defining a new = session-level channel binding (updating rfc5929) based on tls-session-hash? The advantage would be to obtain authenticated session resumption. That is, once a client has used SCRAM to authenticate on one connection, = it can reuse that credential on all resumed connections, until a new full handshake is performed. I = don=92t know how commonly we use session resumption in non-web scenarios, but the vast majority of = connections initiated by web browsers use abbreviated handshakes. Best, Karthik >=20 > Then SCRAM-SHA256 should normatively references that and require that > it is implemented for secure use of SCRAM with channel bindings. = There > are drawbacks with that approach: it is not widely implemented, not > published as an RFC that updates earlier TLS versions, and difficult > for SCRAM implementers to validate (usually the TLS stack is opaque to > the SCRAM implementer). I could live with that though, as a way of > pushing the current security problem down from the IETF protocol layer > into the implementation layer. >=20 > Alternatively, use a new channel binding type that use the extended > master secret derivation as described by the document above. I could > update draft-josefsson-sasl-tls-cb to describe this approach. >=20 > /Simon > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVYBkWAAoJEB/WSo9veuUKybYH+QGJuJL8kTJBHTobgxiPBN2B DNUq+rNQa1ocNHvFUtVsJ/xiPfBOmCtXYlkk09PO2i03vPhJJCAea4hC1PVB51iB W7KPUELMp0o6EYvNnStGKWlOLQ7oUQcsXUNXZxvlpaVsd0WUg8GcfzgL2wEZQiWM LEQ5Ajcwx4rQYnaK/uFxsg8E1Hb+2xlLema2Vu/IKcR9FrxsP+FkYf5GPzOC9O3v lZi3czoWfEWPqiE9MENpddhPpU3eNkLxV6/C1wHPdqOlGLStYqfclpyBSTR7sepP nNTP2jz1mlAfIQUPiHdt2VU9SVVSwPAvzipheM3p8kF2r8qdbS9kQBRVKi5B6Vo= =xpYT -----END PGP SIGNATURE----- --Apple-Mail=_9B5093EF-E174-4DF9-ADCA-F46F42B365D6-- From nobody Sat May 23 07:31:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD611A1B6B for ; Sat, 23 May 2015 07:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8ZafmU00dEO for ; Sat, 23 May 2015 07:31:08 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E55151A1F02 for ; Sat, 23 May 2015 07:27:54 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NERU0v029392 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 16:27:31 +0200 Date: Sat, 23 May 2015 16:27:28 +0200 From: Simon Josefsson To: Tony Hansen Message-ID: <20150523162728.5b6b63cd@latte.josefsson.org> In-Reply-To: <555FC6CF.5020306@att.com> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/FF2ootm/tXhbLoyTOay+NOP"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:31:10 -0000 --Sig_/FF2ootm/tXhbLoyTOay+NOP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Fri, 22 May 2015 20:16:15 -0400 skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding: > On 3/2/15 2:23 PM, Alexey Melnikov wrote: > > > > On 25/02/2015 15:25, Simon Josefsson wrote: > >> Tony Hansen writes: > >> > >>> On 2/24/15 6:56 AM, Stephen Farrell wrote: > >>>> But in addition, there were two substantive issues that ought be > >>>> resolved before IETF LC: > >>>> > >>>> 1. a new channel binding or requiring tls-session-hash (and I > >>>> guess some explanatory text about why that is good/needed) > >>> To recap: > >>> > >>> Simon Josefsson made this comment: > >>> > >>>> Since SCRAM was published, we have learned that the tls-unique > >>>> channel binding is insecure -- it would be nice if we could > >>>> combine the SHA256 update with another default channel binding > >>>> type to resolve that problem. In my view, the problem with > >>>> SCRAM today isn't primarily its use of SHA1 but it's broken > >>>> channel binding. > >>> Martin Thompson responded: > >>> > >>>> We have a solution for that: > >>>> https://tools.ietf.org/html/draft-ietf-tls-session-hash > >>> I've read through tls-session-hash and am unsure how to proceed > >>> here. > >>> > >>> One of my goals when proposing SCRAM-SHA-256 was to not change the > >>> protocol at all, other than updating the hash algorithm. > >>> > >>> I'm not sure how to incorporate a recommendation for session > >>> hashing here. I'm thinking this would be best handled by adding > >>> something to the Security Considerations section. Does that seem > >>> right? > >>> > >>> Would anyone be willing to suggest text changes for these > >>> comments? > >> I believe the problem is that RFC 5802 is insecure as currently > >> specified, and we are bringing this up as a problem with your > >> draft, which is unfair to you since the problem was not introduced > >> by you. > >> > >> If people like the tls-session-hash approach (I'm not in that > >> category, but there may be consensus around it), the proper fix is > >> to update RFC 5802 and reference tls-session-hash as a normative > >> reference. This will take care of the problem, as you could copy > >> that text into your document. If you are looking for a text > >> change here, it would be: > >> > >> To be secure SCRAM-SHA-256-PLUS has to be used over a TLS > >> channel that > >> MUST have [TLS-SESSION-HASH] negotiated. > >> > >> Personally, I would prefer to change to another mandatory channel > >> binding that is secure for all TLS versions. > > Before we make the decisions between referencing tls-session-hash > > versa a new channel binding, can you sketch out how the new channel > > binding is going to be defined? > > > > (If we choose to define a new channel binding, I think Kitten WG is > > the right place for doing this work.) >=20 > I added the following to the security section: >=20 > > The strength of this mechanism is dependent in part on the > hash-iteration count, as denoted by "i" in > > . > > As a rule of thumb, the hash-iteration count should be such > > that a > modern machine will take 0.1 seconds > > to perform the complete algorithm; however this is unlikely to > > be > practical on mobile devices and > > other relatively low-performance systems. > > At the time this was written, the rule of thumb gives around > 15,000 iterations required; > > however an iteration count of 4096 takes around 0.5 seconds on > current mobile handsets. > > This computational cost can be avoided by caching the ClientKey > (assuming the Salt and iteration count is stable). > > Therefore the recommendation of this specification is that the > iteration count SHOULD be at least 4096, but careful > > consideration ought to be given to using a significantly higher > value, particularly where mobile use is less important. >=20 > If anyone has suggestions for additions to this, or changes, please > suggest it now. This text has nothing to do with the tls-session-hash issue? If you don't want to ship a known insecure protocol, I believe the options are to either include text similar to what I proposed above, or to replace tls-unique with a secure TLS channel binding (e.g., draft-josefsson-sasl-tls-cb). Shipping a known insecure protocol is another option, but then you should add a security consideration explaining that tls-unique is not secure without tls-session-hash and that consistency with (the also insecure) RFC 5802 was deemed more important security. /Simon --Sig_/FF2ootm/tXhbLoyTOay+NOP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYI5QAAoJEIYLf7sy+BGdrQoH/jiXcW4OD6WaHuppXUwSXb7s sK9lMVD72hLRL7pi2bYUfv1bOxHAr08ZdkJG6ZrtbafzoHrwtojwbmiUQCedwJar W+8f+s0W7cqR7Sm6l4nsqlnnEEaPbAQp6sEKWSk+OuUIYw5KTLCx71LofcqCj888 AwFXQ1xovW2YZcFAh8No7RKic+7du9jwhoOFiuYoIRXQVsQFpu3ZRhY/ZcSa4K+A eK3c8qELYoq2PKnrgIEYkZRT1IiCqNc9u8v5KgBRz8yujQYR++IpG+jecFmw2NBn vvR8EN1cUQHZfgMi3IWzRUAg2MTDJJLtcrenqa/ol82+nvnsdAs2pgBItlZXGOk= =YfRj -----END PGP SIGNATURE----- --Sig_/FF2ootm/tXhbLoyTOay+NOP-- From nobody Sat May 23 07:35:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1A1A1B48; Sat, 23 May 2015 07:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TuhBST7vzYxt; Sat, 23 May 2015 07:35:43 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FD51A1B6B; Sat, 23 May 2015 07:35:42 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NEZROp030315 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 16:35:29 +0200 Date: Sat, 23 May 2015 16:35:26 +0200 From: Simon Josefsson To: Karthikeyan Bhargavan Message-ID: <20150523163526.7e7d5e14@latte.josefsson.org> In-Reply-To: References: <54DC00D0.2050900@cs.tcd.ie> <87r3tqqj9y.fsf@latte.josefsson.org> <20150216115457.3c16fdbf@latte.josefsson.org> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/.hvmA=uvI9hcR2USMr=tHVP"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" , "http-auth@ietf.org" , Martin Thomson , "saag@ietf.org" Subject: Re: [kitten] [saag] AD sponsoring draft-hansen-scram-sha256 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 14:35:44 -0000 --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > I have a separate question: would there be value in defining a new > session-level channel binding (updating rfc5929) based on > tls-session-hash? I offered https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 as an alternative to tls-unique back in the days. The issue with using only the client/server-random (a'la TLS Finished) was discussed back then and for -01 in 2008 I fixed the construct to be more secure (credit to Eric Rescorla and Sam Hartman who made me aware of the concern). My draft derives the channel binding in a way similar to tls-session-hash. I would appreciate if you could take a look and tell me if you believe that it would solve the triple-handshake concern. /Simon --Sig_/.hvmA=uvI9hcR2USMr=tHVP Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYJAuAAoJEIYLf7sy+BGdyvoH/jop/Fr3jQP6ceR15F/S6Ac/ bwuPbeNAu8CuRcmTeidjlWKneysggtJQwfun0aNeBgkzYbUXzxZ5PQyKWaLfu+Q5 yrXI9+ZvOeGf3K56E6ztHkr5qsRy1DK+V7ZwwBWbpDQFYeWGtST+vSOQcQ3/bybS 1uDTFBMGW51WL+elo06ype8NOZxKx9rZmPMWICzo19cB0ZvKz0O9twQ3k0IcwDQe cfpxqHhJSPQehu+xCN28iEN+dnTD7YlQgq0K/938zisZY/rtAVh11LuVv9ezfjnb TiYUpcIhEO43gtHcOszeVCTArAbUXIWK7+O+6XmQmvcVd/UwRQAvAQUGdrPIy4c= =PNiz -----END PGP SIGNATURE----- --Sig_/.hvmA=uvI9hcR2USMr=tHVP-- From nobody Sat May 23 13:26:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3DA1A1BEA for ; Sat, 23 May 2015 13:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEfCKW5aNDeF for ; Sat, 23 May 2015 13:26:20 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C6F661A1BDA for ; Sat, 23 May 2015 13:26:20 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 7538D2F4071; Sat, 23 May 2015 13:26:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=/rxiy2Ge9CgC3c Gniiy7m6cWxSY=; b=yC605zdbAKOjwNxmOLjT2zZGR6KWblh0uo7IOkw9hYRISz KcZi4LQsDZwWGn35C+ncVOCF3Y84A5kQ+NZ1hZjkt6+ybYSoidC2/sd4n0B0ipvG 0HhSnoqD6FFHUXzkZF8Sj9hNWcNX8WU5Sf1VzwBUjTWxf3AsCGq2YJSL2hghM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id F2D912F4065; Sat, 23 May 2015 13:26:19 -0700 (PDT) Date: Sat, 23 May 2015 15:26:19 -0500 From: Nico Williams To: Alexey Melnikov Message-ID: <20150523202618.GC2166@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54F4B8B8.8090406@isode.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 20:26:24 -0000 On Mon, Mar 02, 2015 at 07:23:36PM +0000, Alexey Melnikov wrote: > On 25/02/2015 15:25, Simon Josefsson wrote: > >Tony Hansen writes: > >If people like the tls-session-hash approach (I'm not in that category, > >but there may be consensus around it), the proper fix is to update RFC > >5802 and reference tls-session-hash as a normative reference. This will > >take care of the problem, as you could copy that text into your > >document. If you are looking for a text change here, it would be: > > > > To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel that > > MUST have [TLS-SESSION-HASH] negotiated. > > > >Personally, I would prefer to change to another mandatory channel > >binding that is secure for all TLS versions. > Before we make the decisions between referencing tls-session-hash > versa a new channel binding, can you sketch out how the new channel > binding is going to be defined? > > (If we choose to define a new channel binding, I think Kitten WG is > the right place for doing this work.) There is no need to define a new channel binding. Existing TLS implementations need to be fixed regardless. There's nothing GSS- or SASL-mechanism-specific here. Nico -- From nobody Sat May 23 13:40:16 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB441A86F0 for ; Sat, 23 May 2015 13:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOeUWoH64P8D for ; Sat, 23 May 2015 13:40:11 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1772D1A802D for ; Sat, 23 May 2015 13:40:10 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NKdlw4000451 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 23 May 2015 22:39:48 +0200 Date: Sat, 23 May 2015 22:39:46 +0200 From: Simon Josefsson To: Nico Williams Message-ID: <20150523223946.15ae8c11@latte.josefsson.org> In-Reply-To: <20150523202618.GC2166@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/c6CzN8KGdkK2WsV=VSQ308a"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 20:40:15 -0000 --Sig_/c6CzN8KGdkK2WsV=VSQ308a Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Sat, 23 May 2015 15:26:19 -0500 skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding: > On Mon, Mar 02, 2015 at 07:23:36PM +0000, Alexey Melnikov wrote: > > On 25/02/2015 15:25, Simon Josefsson wrote: > > >Tony Hansen writes: > > >If people like the tls-session-hash approach (I'm not in that > > >category, but there may be consensus around it), the proper fix is > > >to update RFC 5802 and reference tls-session-hash as a normative > > >reference. This will take care of the problem, as you could copy > > >that text into your document. If you are looking for a text > > >change here, it would be: > > > > > > To be secure SCRAM-SHA-256-PLUS has to be used over a TLS > > > channel that MUST have [TLS-SESSION-HASH] negotiated. > > > > > >Personally, I would prefer to change to another mandatory channel > > >binding that is secure for all TLS versions. > > Before we make the decisions between referencing tls-session-hash > > versa a new channel binding, can you sketch out how the new channel > > binding is going to be defined? > >=20 > > (If we choose to define a new channel binding, I think Kitten WG is > > the right place for doing this work.) >=20 > There is no need to define a new channel binding. Existing TLS > implementations need to be fixed regardless. There's nothing GSS- or > SASL-mechanism-specific here. There is, since no GS2 mechanism is secure with tls-unique without tls-session-hash. The fault is not GSS/SASL's, but as far as I understand, it is a fact nonetheless. Thus a normative reference to tls-session-hash can be added to documents to resolve the problem, or a new channel binding can be used. I don't see any other solution, but ideas welcome. As far as I see, the tls-session-hash document does not update earlier TLS specs to require that tls-session-hash is implemented. Thus, it is perfectly valid and compliant to implement TLS without tls-session-hash when used for GSS/SASL since there is no normative reference to tls-session-hash anywhere. Finally, I think for the forseeable future there will be widely deployed TLS stacks without support for tls-session-hash. /Simon --Sig_/c6CzN8KGdkK2WsV=VSQ308a Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYOWSAAoJEIYLf7sy+BGdcM4IAJfEpLB+edw9Hzhwf+Kj8j3+ 3Qnl/hw2SqPNnGx4bTFlhoQtoizeX2gJrSfu6BBzcIk8rc3sN0TMXZ+GZWBjX7jp oHsno6tAxb3awzeONRxk7uoTliFAFeYLHVGkr35yMw4oP7Ot+YHu/8yw5yMqunsj NVR3PIV2WJMkdM0M6XjRtPwQa3Q/krAY0ty7ieeG1po3jNk+pAIzbpZPl5QSo+e4 UOai7h1KeeAzcEEzokaOQ9cShs8OIAkroVanIn1CT1YgD3CJbsxaSWNf762RhKuH uCKQhFV94lO7YiYYoKbfKw9dlb7ufAVnvWeeXFsDs9MgNbhggD3/BKkD0Q1UuN0= =HAUE -----END PGP SIGNATURE----- --Sig_/c6CzN8KGdkK2WsV=VSQ308a-- From nobody Sat May 23 14:43:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5803E1A8837 for ; Sat, 23 May 2015 14:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhmyIk8GfLiR for ; Sat, 23 May 2015 14:43:53 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 724A61A8839 for ; Sat, 23 May 2015 14:43:53 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id CCF541612; Sat, 23 May 2015 14:43:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=wCBVG9w+7mohsv PczFQZzpa9ZcQ=; b=whWKOtwyc+azkXcnobsxD8RHWrwXAEfmyF/E4UpvOcFE5i bOf86i/CSO7riLGKkiEPV4QMyop+EfNhTbjFpd+Gjtfvfm/3O39zajL6DVf3ei8T tTIPcxDroCPEKkVbDKsZN/8XgD7JHBu/rQv6aHO7By9hNufWqYHVlAXj9kXt4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id 4DA781610; Sat, 23 May 2015 14:43:52 -0700 (PDT) Date: Sat, 23 May 2015 16:43:51 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150523214351.GD2166@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> <20150523223946.15ae8c11@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150523223946.15ae8c11@latte.josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 21:43:57 -0000 On Sat, May 23, 2015 at 10:39:46PM +0200, Simon Josefsson wrote: > > There is no need to define a new channel binding. Existing TLS > > implementations need to be fixed regardless. There's nothing GSS- or > > SASL-mechanism-specific here. > > There is, since no GS2 mechanism is secure with tls-unique without > tls-session-hash. The fault is not GSS/SASL's, but as far as I TLS needs fixing regardless. tls-unique is perfectly fine when the session hash is used. Nico -- From nobody Sat May 23 15:44:52 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1385A1A88C7 for ; Sat, 23 May 2015 15:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBfqobFKrZXm for ; Sat, 23 May 2015 15:44:50 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0EC1A88C0 for ; Sat, 23 May 2015 15:44:49 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4NMidkb012289 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Sun, 24 May 2015 00:44:40 +0200 Date: Sun, 24 May 2015 00:44:38 +0200 From: Simon Josefsson To: Nico Williams Message-ID: <20150524004438.5121c26b@latte.josefsson.org> In-Reply-To: <20150523214351.GD2166@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> <20150523223946.15ae8c11@latte.josefsson.org> <20150523214351.GD2166@localhost> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/it6f=ObTjNVG/3gi8Y.Oa6i"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 22:44:51 -0000 --Sig_/it6f=ObTjNVG/3gi8Y.Oa6i Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Den Sat, 23 May 2015 16:43:51 -0500 skrev Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding: > On Sat, May 23, 2015 at 10:39:46PM +0200, Simon Josefsson wrote: > > > There is no need to define a new channel binding. Existing TLS > > > implementations need to be fixed regardless. There's nothing > > > GSS- or SASL-mechanism-specific here. > >=20 > > There is, since no GS2 mechanism is secure with tls-unique without > > tls-session-hash. The fault is not GSS/SASL's, but as far as I >=20 > TLS needs fixing regardless. tls-unique is perfectly fine when the > session hash is used. Perhaps this is a question for the TLS WG -- whether they intend tls-session-hash to apply as a mandatory fix to all TLS versions or not. The document does not say anything about updates now, which means "TLS needs fixing" won't necessarily happen. /Simon --Sig_/it6f=ObTjNVG/3gi8Y.Oa6i Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYQLWAAoJEIYLf7sy+BGdxuoIAIgbp3k9cUWmJ3Ulf1gtJ0PS FE8ozwbU+xjE0DG/aDzOl/I8mRrreae6NAz+WoI32FYySBu7v8U4hx55ViYo2hca mIF+i4C+EdzRDz3kLUPA73xvckYB731aaax7l35WxcdOGmux/kTnnDuH9wqU+1IQ l5whmo/RHbPsme7eJ1RF6a38phTwZzAJZf7NHqrPfXSNLO/HMwrMV4G9B5Fk0J9h SGhSsCum+OQYobLVb8duD18Rz+3Uffr97myUhJQnM2q+ARDrSYCrTwHDCG4OmEoB zx+DXwEz7gfzbhhr4NEiw51lWumJWFcJH49gI5UVI/cF3YNec0CUFm2bvXhr7eg= =0IP0 -----END PGP SIGNATURE----- --Sig_/it6f=ObTjNVG/3gi8Y.Oa6i-- From nobody Sat May 23 15:57:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C8D1A88F9 for ; Sat, 23 May 2015 15:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZVBH8pEdjNP for ; Sat, 23 May 2015 15:57:40 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69A9E1A88F6 for ; Sat, 23 May 2015 15:57:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 8DA8FBED8; Sat, 23 May 2015 23:57:14 +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 9WevYdjlt03r; Sat, 23 May 2015 23:57:13 +0100 (IST) Received: from [10.87.48.73] (unknown [86.46.24.221]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 25924BED2; Sat, 23 May 2015 23:57:13 +0100 (IST) Message-ID: <556105C3.8020303@cs.tcd.ie> Date: Sat, 23 May 2015 23:57:07 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Simon Josefsson , Nico Williams References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> <20150523223946.15ae8c11@latte.josefsson.org> <20150523214351.GD2166@localhost> <20150524004438.5121c26b@latte.josefsson.org> In-Reply-To: <20150524004438.5121c26b@latte.josefsson.org> OpenPGP: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="90eht1KvIuwctDSii4xRlGdnNcqh87DUR" Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 22:57:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --90eht1KvIuwctDSii4xRlGdnNcqh87DUR Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/05/15 23:44, Simon Josefsson wrote: > Perhaps this is a question for the TLS WG -- whether they intend > tls-session-hash to apply as a mandatory fix to all TLS versions or > not. The document does not say anything about updates now, which means= > "TLS needs fixing" won't necessarily happen. So this may be helpful or not depending on how much one considers IETF minutae important... During IESG evaluation we agreed to have the session hash document be an update of 5246. The start of that thread is at [1] and the resolution is downthread or maybe in some other thread but was on the TLS list. The update to the draft hasn't yet happened but will shortly. The impact is that our formalities then expect any new TLS code to include session hash. But that of course does not affect already deployed code so make of that what you will. Cheers, S. [1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html --90eht1KvIuwctDSii4xRlGdnNcqh87DUR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVYQXHAAoJEC88hzaAX42iq14IAJa2CxvtDKSC3yeCMl6In6D9 7I7pVWfY/GEMGqBDeglUBt2xxAMjK9USRy0U0VicUVhd4dfj8WO3T+TrJ2Quh2yD WJ7hMzgFZ3560soBk3kxRSmXqaGvkK4h68OHiyvGwMroNMQexoIsZtTTy/LV3ZI5 hLd5xKRNKPLE/vq4HThItR0RhCmh71CAzQ6ZThTm3129mOuDpicGzmrXeWggA4+u YX4oQjHQiIcxvYNnMe1lzcx4m1TRQJHRorJ3Y9Xqw7lilpcjo9B/2lCWgk7dLgVL d5PVda3I/ogvojOH+AV+UKwFeEnKETWAFYxKB6jNhMOIdt88GyVfZJXge/aFtwI= =6KeE -----END PGP SIGNATURE----- --90eht1KvIuwctDSii4xRlGdnNcqh87DUR-- From nobody Mon May 25 08:57:56 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDD81A9250; Mon, 25 May 2015 08:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyDPTdZuNRGI; Mon, 25 May 2015 08:57:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF2731A924B; Mon, 25 May 2015 08:57:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525155753.4748.29014.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 08:57:53 -0700 Archived-At: Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org Subject: [kitten] Joel Jaeggli's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 15:57:55 -0000 Joel Jaeggli has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- SASL mechanisms using this document as their definition do not provide a data security layer; that is, they cannot provide integrity or confidentiality protection for application messages after the initial authentication. If such protection is needed, TLS or some similar solution should be used. Additionally, for the two mechanisms specified in this document, TLS MUST be used for OAUTHBEARER to protect the bearer token; for OAUTH10A the use of TLS is RECOMMENDED. Can someone explain to me situation were intergrity protection is not desirable (possibly rhetorical). it seems like it might be better to clarify what the exception is and use a blanket must for everything else. From nobody Mon May 25 14:50:46 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120CE1AC431; Mon, 25 May 2015 09:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiWJTk_zef3x; Mon, 25 May 2015 09:41:03 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0769.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::769]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1753B1AC42F; Mon, 25 May 2015 09:40:46 -0700 (PDT) Received: from BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) by BLUPR03MB036.namprd03.prod.outlook.com (10.255.209.148) with Microsoft SMTP Server (TLS) id 15.1.166.22; Mon, 25 May 2015 16:40:27 +0000 Received: from BLUPR03MB407.namprd03.prod.outlook.com (10.141.78.24) by BLUPR03MB408.namprd03.prod.outlook.com (10.141.78.25) with Microsoft SMTP Server (TLS) id 15.1.172.17; Mon, 25 May 2015 16:40:26 +0000 Received: from BLUPR03MB407.namprd03.prod.outlook.com ([10.141.78.24]) by BLUPR03MB407.namprd03.prod.outlook.com ([10.141.78.24]) with mapi id 15.01.0172.012; Mon, 25 May 2015 16:40:26 +0000 From: Bill Mills To: Joel Jaeggli , The IESG Thread-Topic: Joel Jaeggli's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) Thread-Index: AQHQlwOSZ64UBZNW6UOweaiSYShQX52M30qg Date: Mon, 25 May 2015 16:40:25 +0000 Message-ID: References: <20150525155753.4748.29014.idtracker@ietfa.amsl.com> In-Reply-To: <20150525155753.4748.29014.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=wimills@microsoft.com; x-originating-ip: [99.31.212.42] x-microsoft-exchange-diagnostics: 1; BLUPR03MB408; 3:UGbLDcYt5XdG9jTd2LajQQJZJReFP6QS5KPcjrwxzFyA6i99BOxXGbMRaKxp9v834AwN3b1MvyVlbmAZ1JgWSS37oVQwGTU4Anc2mJ9HMBzBFc4W/U5vmXSSAKmlh7nA1cqozxH8iDxe7oaqw9ZUhA==; 10:FZehpnHKUZegVECCeYym5byGsyyp7oBWIUb3YwfftHIzSbZ0j5loBEc7eEd9+h3KFwKqxMwRMbEBHU0glO/3PHC37CyhYvBnLPOc003DTMU=; 6:vmQ4Q50s0Wt44VNEWvZk/hd5G1Yo7IYB9ZSWxcz/8HHIy6hzRdLkRMofzAWVxLxj x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB408; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB036; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(520002)(5005006)(3002001); SRVR:BLUPR03MB408; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB408; x-forefront-prvs: 058707456E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(199003)(189002)(52044002)(377454003)(68736005)(77096005)(230783001)(76176999)(50986999)(2950100001)(2900100001)(15975445007)(102836002)(54356999)(86362001)(92566002)(101416001)(33656002)(62966003)(77156002)(86612001)(106356001)(106116001)(66066001)(189998001)(64706001)(40100003)(46102003)(122556002)(5001960100002)(5001830100001)(87936001)(76576001)(5001860100001)(81156007)(99286002)(97736004)(5001770100001)(19580405001)(4001540100001)(19580395003)(2656002)(74316001)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB408; H:BLUPR03MB407.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 May 2015 16:40:25.4728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB408 X-Microsoft-Exchange-Diagnostics: 1; BLUPR03MB036; 2:B9dS4btqm+WiWzV5SH6UqeUqHMYLthm9IlHub2cPMYTWrhH4fhnSsnQiJP/nGnV1; 2:4Lw17preiCxui12ZfR5MhjifCnXnSbUHcGKX4lWgF0LGK+h/lTeukqqukCLBAcNoM981G2uEVXCBNJBIxupQfkQU3jcPn33lAA0QOfBfY5p4hTpn8TZVYmhO6NR8cx9PO//qWE+8iodaSam5qNoCWg==; 9:HRMg07ZJPG/z43UOWkr9PGGB4iP236xYK3Qr0QkHsI2odsPyVfENz8GCCIB5fldB1fhPnULRrSkD4TMxc11r+R+lwLcuGZ9v63nQTZwT51IRnxJeRSkfjz6/2tzVeqSYOU4P+ybIGdps0eMOKuguWw== X-OriginatorOrg: microsoft.com Archived-At: X-Mailman-Approved-At: Mon, 25 May 2015 14:50:45 -0700 Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Joel Jaeggli's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 16:41:05 -0000 IiBDYW4gc29tZW9uZSBleHBsYWluIHRvIG1lIHNpdHVhdGlvbiB3ZXJlIGludGVyZ3JpdHkgcHJv dGVjdGlvbiBpcyBub3QgZGVzaXJhYmxlIChwb3NzaWJseSByaGV0b3JpY2FsKS4gaXQgc2VlbXMg bGlrZSBpdCBtaWdodCBiZSBiZXR0ZXIgdG8gY2xhcmlmeSB3aGF0IHRoZSBleGNlcHRpb24gaXMg YW5kIHVzZSBhIGJsYW5rZXQgbXVzdCBmb3IgZXZlcnl0aGluZyBlbHNlLiINCg0KSW4gT0F1dGgg dGhlcmUncyBubyBndWFyYW50ZWUgb2YgYSBzaGFyZWQgY29udGV4dCB0aGF0IGhhcyBhIHNlY3Jl dCB0aGF0IGNhbiBiZSB1c2VkIHRvIHByb3ZpZGUgaW50ZWdyaXR5IHByb3RlY3Rpb24uICBTb21l IE9BdXRoIG1lY2hhbmlzbXMgbGlrZSB0aGUgImhvbGRlciBvZiBrZXkvcHJvb2Ygb2YgcG9zc2Vz c2lvbiIgdG9rZW5zIGRvIGhhdmUgb25lIGJ1dCBub3QgYWxsLiANCg0KUmVnYXJkcywNCg0KLWJp bGwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEpvZWwgSmFlZ2dsaSBbbWFp bHRvOmpvZWxqYUBib2d1cy5jb21dIA0KU2VudDogTW9uZGF5LCBNYXkgMjUsIDIwMTUgODo1OCBB TQ0KVG86IFRoZSBJRVNHDQpDYzoga2FkdWtAbWl0LmVkdTsga2l0dGVuLWNoYWlyc0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC5zaGVwaGVyZEBpZXRmLm9yZzsgZHJhZnQt aWV0Zi1raXR0ZW4tc2FzbC1vYXV0aEBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1v YXV0aC5hZEBpZXRmLm9yZzsga2l0dGVuQGlldGYub3JnDQpTdWJqZWN0OiBKb2VsIEphZWdnbGkn cyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0yMjogKHdpdGgg Q09NTUVOVCkNCg0KSm9lbCBKYWVnZ2xpIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90 IHBvc2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1raXR0ZW4tc2FzbC1vYXV0aC0yMjogTm8gT2JqZWN0 aW9uDQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRh Y3QgYW5kIHJlcGx5IHRvIGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFu ZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcyBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBo LCBob3dldmVyLikNCg0KDQpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVz Zy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQpmb3IgbW9yZSBpbmZvcm1hdGlvbiBh Ym91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KDQoNClRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYta2l0dGVuLXNhc2wt b2F1dGgvDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpT QVNMIG1lY2hhbmlzbXMgdXNpbmcgdGhpcyBkb2N1bWVudCBhcyB0aGVpciBkZWZpbml0aW9uIGRv IG5vdA0KICAgcHJvdmlkZSBhIGRhdGEgc2VjdXJpdHkgbGF5ZXI7IHRoYXQgaXMsIHRoZXkgY2Fu bm90IHByb3ZpZGUgaW50ZWdyaXR5DQogICBvciBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBm b3IgYXBwbGljYXRpb24gbWVzc2FnZXMgYWZ0ZXIgdGhlDQogICBpbml0aWFsIGF1dGhlbnRpY2F0 aW9uLiAgSWYgc3VjaCBwcm90ZWN0aW9uIGlzIG5lZWRlZCwgVExTIG9yIHNvbWUNCiAgIHNpbWls YXIgc29sdXRpb24gc2hvdWxkIGJlIHVzZWQuICBBZGRpdGlvbmFsbHksIGZvciB0aGUgdHdvDQog ICBtZWNoYW5pc21zIHNwZWNpZmllZCBpbiB0aGlzIGRvY3VtZW50LCBUTFMgTVVTVCBiZSB1c2Vk IGZvcg0KICAgT0FVVEhCRUFSRVIgdG8gcHJvdGVjdCB0aGUgYmVhcmVyIHRva2VuOyBmb3IgT0FV VEgxMEEgdGhlIHVzZSBvZiBUTFMNCiAgIGlzIFJFQ09NTUVOREVELg0KDQpDYW4gc29tZW9uZSBl eHBsYWluIHRvIG1lIHNpdHVhdGlvbiB3ZXJlIGludGVyZ3JpdHkgcHJvdGVjdGlvbiBpcyBub3Qg ZGVzaXJhYmxlIChwb3NzaWJseSByaGV0b3JpY2FsKS4gaXQgc2VlbXMgbGlrZSBpdCBtaWdodCBi ZSBiZXR0ZXIgdG8gY2xhcmlmeSB3aGF0IHRoZSBleGNlcHRpb24gaXMgYW5kIHVzZSBhIGJsYW5r ZXQgbXVzdCBmb3IgZXZlcnl0aGluZyBlbHNlLg0KDQoNCg== From nobody Mon May 25 16:14:30 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDF41ACD77; Mon, 25 May 2015 16:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfUjdmWBGVhH; Mon, 25 May 2015 16:14:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5FA1ACD6D; Mon, 25 May 2015 16:14:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150525231428.32727.74087.idtracker@ietfa.amsl.com> Date: Mon, 25 May 2015 16:14:28 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-rfc4402bis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 23:14:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism Authors : Shawn Emery Cryptonector, LLC Filename : draft-ietf-kitten-rfc4402bis-01.txt Pages : 7 Date : 2015-04-06 Abstract: This document defines the Pseudo-Random Function (PRF) for the Kerberos V mechanism for the Generic Security Service Application Program Interface (GSS-API), based on the PRF defined for the Kerberos V cryptographic framework, for keying application protocols given an established Kerberos V GSS-API security context. This document obsoletes RFC 4402 and reclassifies that document as historic. RFC 4402 starts the PRF+ counter at 1, however a number of implementations starts the counter at 0. As a result, the original specification would not be interoperable with existing implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc4402bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-rfc4402bis-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc4402bis-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 26 08:57:40 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698C41A9054; Tue, 26 May 2015 08:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqkkNLMnu2Vg; Tue, 26 May 2015 08:57:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D011A9048; Tue, 26 May 2015 08:57:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Barry Leiba" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> Date: Tue, 26 May 2015 08:57:34 -0700 Archived-At: Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org Subject: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 15:57:36 -0000 Barry Leiba has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Another excellent, informative shepherd writeup, which helped with my review of the document. (And, I'll say, most of the really useful writeups, as this one, seem to use the "essay" format, rather than the Q&A format.) Thanks, Ben, for the writeup. -- Section 1 -- way to use the Simple Authentication and Security Layer (SASL) [RFC4422] to gain access to resources when using non-HTTP-based protocols, such as the Internet Message Access Protocol (IMAP) [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], which is what this memo uses in the examples. When I first read this, I thought the last phrase was bound to SMTP... but then I see that both IMAP and SMTP are used in the examples. So, a small thing, but I'd end the sentence after the 5321 reference, and make the last phrase into another sentence, like, "This document gives examples of use in IMAP and SMTP." -- Section 2 -- Note that the IMAP SASL specification requires base64 encoding, see Section 4 of [RFC4648], not this memo. Nit: That seems kind of an odd way to put it, in addition to its having a comma splice. Why not this?: NEW Note that the IMAP SASL specification requires base64 encoding, as specified in Section 4 of [RFC4648]. END -- Section 3.2 -- Nit: "vaialble" -> "available" -- Section 3.2.2 -- scope (OPTIONAL): An OAuth scope which is valid to access the service. This may be omitted which implies that unscoped tokens are required. If a scope is specified then a single scope is preferred, use of a space separated list of scopes is NOT RECOMMENDED. Why is it "NOT RECOMMENDED"? What interoperability or security issue is in play here that makes this "SHOULD NOT"? The server MAY return different URLs for users in different domains and the client SHOULD NOT cache a single returned value and assume it applies for all users/domains that the server suports. The returned discovery document SHOULD have all data elements required by the OpenID Connect Discovery specification populated. Similar questions for the SHOULD NOT and SHOULD here. In this case, I don't understand why they aren't "MUST NOT" and "MUST": for the first, I don't understand how a client can interoperate with a server if it violates this, and for the second, if they data elements are "required", why isn't including them a "MUST"? (Nit: The "if available" at the end of the paragraph is unnecessary; if one is not available, it certainly can't be used.) -- Section 4.1 -- The underlying TLS establishment is not shown but is required for using Bearer Tokens per that specification. S: * OK IMAP4rev1 Server Ready C: t0 CAPABILITY S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR S: t0 OK Completed The problem with this is that if the underlying TLS establishment is done through STARTTLS on port 143, that would come between the first line ("S: * OK IMAP4rev1 Server Ready") and the second. And that makes the example a bit odd. The easiest way out of that is simply to remove the first line. Or, better, to replace the first line with something like "[Initial connection and TLS establishment...]". (This applies to the subsequent sections as well.) I wonder why you don't wrap the decoded payload here the same way you do in Section 4.2 (or there the same as here). I suggest that there'd be less room for any confusion if you did them all (4.3 also) the same way (I don't care which way you choose). In the SMTP part, you say this: Note that line breaks are inserted for readability, and that the SMTP protocol terminates lines with CR and LF characters (ASCII values 0x0D and 0x0A), these are not displayed explicitly in the example. The same is true for the IMAP protocol and example, but you don't say this there. Actually, I don't think you need to say it in either place, and suggest simply removing it here (and in Section 4.4). -- Section 4.4 -- In the SMTP protocol, you should have "[Negotiate TLS...]" before the SMTP AUTH command, as you do in Section 4.1. From nobody Tue May 26 13:41:29 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A423D1B3154; Tue, 26 May 2015 13:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2leOvfuyI5f; Tue, 26 May 2015 13:41:21 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B361B3159; Tue, 26 May 2015 13:41:20 -0700 (PDT) X-AuditID: 12074424-f79f56d000000da5-5c-5564da6f754c Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 12.C6.03493.F6AD4655; Tue, 26 May 2015 16:41:19 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t4QKfIEf011604; Tue, 26 May 2015 16:41:18 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4QKfFjx005902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 26 May 2015 16:41:17 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4QKfE3k020487; Tue, 26 May 2015 16:41:14 -0400 (EDT) Date: Tue, 26 May 2015 16:41:14 -0400 (EDT) From: Benjamin Kaduk To: Barry Leiba In-Reply-To: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> Message-ID: References: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnleLIzCtJLcpLzFFi42IRYrdT0c2/lRJq8KJBxeLQ4kusFn+P/Ga2 eDjjIKPF9AdfmCxm/JnIbHFt935Wi6ObV7E4sHu0rOpl9liy5CdTAFMUl01Kak5mWWqRvl0C V8abVy/YCiYaVzw80sXcwHhEvYuRk0NCwETixZJ/7BC2mMSFe+vZQGwhgcVMEn93inQxcgHZ Gxklps1+xAzhHGKS2PZoHxOE08AocfnyFVaQFhYBbYn2/9+ZQWw2ARWJmW82go0SEdCUeP55 ClgDs8BDRqCxvWAJYYEYieXnvzKB2JwCjhIz334Bu4MXyL598wkLxB0OEpduHAKLiwroSKze P4UFokZQ4uRMiBpmAS2J5dO3sUxgFJyFJDULSWoBI9MqRtmU3Crd3MTMnOLUZN3i5MS8vNQi XXO93MwSvdSU0k2M4PB2UdnB2HxI6RCjAAejEg/vgwPJoUKsiWXFlbmHGCU5mJREeavOpIQK 8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHtPw6U401JrKxKLcqHSUlzsCiJ8276wRciJJCeWJKa nZpakFoEk5Xh4FCS4PW6CdQoWJSanlqRlplTgpBm4uAEGc4DNDwLpIa3uCAxtzgzHSJ/ilFR SpzXAyQhAJLIKM2D64Wln1eM4kCvCPM2gVTxAFMXXPcroMFMQIPNjoINLklESEk1MIZZBZ0L OFO67tn+lScnNovfuNtsuWtnzbT/Yvl1UUtnvVl4OW2roY33lMaKKR3bdmxK4/eaXfb+XtjW x2vqJ6oFTZMqj801z4pe3f/j9pNUz/BjKt0TN1Q+Edbu5RYPFVu05PAD6b67O8I77+3nWP3r V8Sd7Dtdzw+dD5+atPGBZcy1u5s/yLMrsRRnJBpqMRcVJwIA22x6oxoDAAA= Archived-At: Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, The IESG , draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:41:23 -0000 Hi Barry, On Tue, 26 May 2015, Barry Leiba wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Another excellent, informative shepherd writeup, which helped with my > review of the document. (And, I'll say, most of the really useful > writeups, as this one, seem to use the "essay" format, rather than the > Q&A format.) Thanks, Ben, for the writeup. You're welcome :) > -- Section 1 -- > > way to use the Simple Authentication and Security Layer (SASL) > [RFC4422] to gain access to resources when using non-HTTP-based > protocols, such as the Internet Message Access Protocol (IMAP) > [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], > which is what this memo uses in the examples. > > When I first read this, I thought the last phrase was bound to SMTP... > but then I see that both IMAP and SMTP are used in the examples. So, a > small thing, but I'd end the sentence after the 5321 reference, and make > the last phrase into another sentence, like, "This document gives > examples of use in IMAP and SMTP." "which is what this memo uses" is certainly wrong, since 'is' is singular but should be plural to apply to both IMAP and SMTP. But I think your version is better, maybe with the addition of "both" before "IMAP and SMTP" in the last sentence. > -- Section 2 -- > > Note that the IMAP SASL specification requires base64 encoding, see > Section 4 of [RFC4648], not this memo. > > Nit: That seems kind of an odd way to put it, in addition to its having a > comma splice. Why not this?: > > NEW > Note that the IMAP SASL specification requires base64 encoding, as > specified in Section 4 of [RFC4648]. > END I think I had noted the comma splice in a previous review but it slipped through the cracks. Your version looks fine. > -- Section 3.2 -- > Nit: "vaialble" -> "available" Thanks. > -- Section 3.2.2 -- > > scope (OPTIONAL): An OAuth scope which is valid to access the > service. This may be omitted which implies that unscoped > tokens are required. If a scope is specified then a single > scope is preferred, use of a space separated list of scopes is > NOT RECOMMENDED. > > Why is it "NOT RECOMMENDED"? What interoperability or security issue is > in play here that makes this "SHOULD NOT"? I am a little hazy on this, but I seem to recall that some deployed software assumes that only a single scope will be used, so this is for interoperability. (Bill, please jump in if I'm confused.) > The server MAY return different URLs for users in > different domains and the client SHOULD NOT cache a single > returned value and assume it applies for all users/domains that > the server suports. The returned discovery document SHOULD > have all data elements required by the OpenID Connect Discovery > specification populated. > > Similar questions for the SHOULD NOT and SHOULD here. In this case, I > don't understand why they aren't "MUST NOT" and "MUST": for the first, I > don't understand how a client can interoperate with a server if it > violates this, and for the second, if they data elements are "required", > why isn't including them a "MUST"? This section was one of the repeated areas of contention over the last calls, so I am somewhat reluctant to bring it back to the WG for discussion. I think there would be somewhat more support for SHOULD NOT --> MUST NOT; the SHOULD for discovery is, IIRC, something of a compromise, since some parties did not want to bring in a hard dependency on OpenID Connect's choices. The only reason I can come up for the SHOULD NOT, off the top of my head, is if some vendor distributed a mail client that was only ever going to talk to that same vendor's server. > (Nit: The "if available" at the end of the paragraph is unnecessary; if > one is not available, it certainly can't be used.) That's true, but I like the flow of the sentence with the extra redundancy better than without it. > -- Section 4.1 -- > > The > underlying TLS establishment is not shown but is required for using > Bearer Tokens per that specification. > > S: * OK IMAP4rev1 Server Ready > C: t0 CAPABILITY > S: * CAPABILITY IMAP4rev1 AUTH=OAUTHBEARER SASL-IR > S: t0 OK Completed > > The problem with this is that if the underlying TLS establishment is done > through STARTTLS on port 143, that would come between the first line ("S: > * OK IMAP4rev1 Server Ready") and the second. And that makes the example > a bit odd. The easiest way out of that is simply to remove the first > line. Or, better, to replace the first line with something like > "[Initial connection and TLS establishment...]". (This applies to the > subsequent sections as well.) I would be fine with "[Initial connection and TLS establishment...]". > I wonder why you don't wrap the decoded payload here the same way you do > in Section 4.2 (or there the same as here). I suggest that there'd be > less room for any confusion if you did them all (4.3 also) the same way > (I don't care which way you choose). The examples were added at different times, so keeping them in sync has been a bit tough. Hopefully we can enlist the help of the RFC Editor in ensuring consistency of formatting. > In the SMTP part, you say this: > > Note > that line breaks are inserted for readability, and that the SMTP > protocol terminates lines with CR and LF characters (ASCII values > 0x0D and 0x0A), these are not displayed explicitly in the example. > > The same is true for the IMAP protocol and example, but you don't say > this there. Actually, I don't think you need to say it in either place, > and suggest simply removing it here (and in Section 4.4). Hmm, it is probably okay to not mention this, as you propose. Anyone implementing SMTP or IMAP will need to be conversant with the relevant specifications... > -- Section 4.4 -- > In the SMTP protocol, you should have "[Negotiate TLS...]" before the > SMTP AUTH command, as you do in Section 4.1. The running text does have "TLS negotiation is not shown but as noted above it is required for the use of Bearer Tokens", but I support making the examples consistent (and explicit about the use of TLS). -Ben From nobody Tue May 26 13:55:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCC11B31B2 for ; Tue, 26 May 2015 13:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id skFxfZKPzqoH for ; Tue, 26 May 2015 13:54:55 -0700 (PDT) Received: from nm49-vm1.bullet.mail.ne1.yahoo.com (nm49-vm1.bullet.mail.ne1.yahoo.com [98.138.121.129]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5408E1B3213 for ; Tue, 26 May 2015 13:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432673508; bh=JOBroanwTK4i8tSh3pXCfvnsCtDizodwmkeAOf6z+Xo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=gVTes8ulOKxQ/eNZ5enaFzMO08kc1f9cGPjrBdoqtaG6a4Hodjki2uzO0m9Wibhf+kgpSONw48t0b0g+v55ucMph/i7n2CTfng0jiR5BnGQRRyfRjnwqEFoCtJnlTGYPdXzAAeYuQH+ZDIwPEv6RPVVuRnpYMmZ4vIbBM/PMbsQLlJ1cYJxxW5NUA/yV10y+SQVovd5e+cYAdflu+/Yyqghk7gmEbr4yr63SpjDpDtlpyiS31iupOUAa40rG5vY3GTmlbQx+42QqSyzjKr/G+7WEJO27zUyqGJiazODV2/HJyi9M0GUvLEoVjvaQaVgArj6axqcH9vKfiTXev5d9Tg== Received: from [127.0.0.1] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2015 20:51:48 -0000 Received: from [98.138.100.117] by nm49.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2015 20:49:08 -0000 Received: from [98.139.170.179] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 26 May 2015 20:49:08 -0000 Received: from [98.139.212.211] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 20:49:07 -0000 Received: from [127.0.0.1] by omp1020.mail.bf1.yahoo.com with NNFMP; 26 May 2015 20:49:07 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 919816.36376.bm@omp1020.mail.bf1.yahoo.com X-YMail-OSG: oYVjzlgVM1mpREoL_ZorTTMkhy.M5kWFYnlnVKpF5ks_P_RFYPUP2jUfjzJIax7 65tZKQ43wpoE5JWpeJb_GrH5xHEcXLitCQ1gz6RqGGW6cuHy4vs5kwtCj7uNdK0eEyjcv4fqP95R HR9.GR4_LB1jM9Sor4Fu398KCvJf4KNLB0Sim5tjQG7FgDE42XI.9Q92aBh0aBcAgo2p_CtutZWK YxJfjucuelL0ZhJeE14PJeQ._D54EuKcH6nyI9IqEgl7W9l4Ve1XKyY.jcU4IxHe1WWvBgAbsD4p m9Zlf2cI44OkLTLooPARpMa5TvhAUilpI4QKLape1xa4U11MV7j9bmkR8C9A12A5JgKHhWPpIopC AYSxdWOCRfwjc8dmnCZMXFlNpqNfkm6XuU1wqLESjwEgnQBSDtUoClZqhU_meo4.pUEn9vOnCsk2 3bMr4wMPAhHsonpuMJj88Y3_.0cfOqJNysdxrBnDxc9S6oNFa.dUh1PnoJhwhjMEy3R1M7FqP2jQ WXoL7xsChEtDB2qXUDYGJ Received: by 76.13.26.136; Tue, 26 May 2015 20:49:07 +0000 Date: Tue, 26 May 2015 20:49:04 +0000 (UTC) From: Bill Mills To: Barry Leiba , The IESG Message-ID: <513132564.2389503.1432673344504.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> References: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2389502_397118509.1432673344489" Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:54:59 -0000 ------=_Part_2389502_397118509.1432673344489 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > ----------------------------------------------------------------------> C= OMMENT:> ------------------------------------------------------------------= ---->=C2=A0> Another excellent, informative shepherd writeup, which helped = with my review of the document. =C2=A0(And, I'll say, most of the really us= eful writeups, as this one, seem to use the "essay" format, rather than the= Q&A format.) =C2=A0Thanks, Ben, for the writeup.>=C2=A0> -- Section 1 -->= =C2=A0> =C2=A0 =C2=A0way to use the Simple Authentication and Security Laye= r (SASL)> =C2=A0 =C2=A0[RFC4422] to gain access to resources when using non= -HTTP-based> =C2=A0 =C2=A0protocols, such as the Internet Message Access Pr= otocol (IMAP)> =C2=A0 =C2=A0[RFC3501] and the Simple Mail Transfer Protocol= (SMTP) [RFC5321],> =C2=A0 =C2=A0which is what this memo uses in the exampl= es.>=C2=A0> When I first read this, I thought the last phrase was bound to = SMTP...> but then I see that both IMAP and SMTP are used in the examples. = =C2=A0So, a small thing, but I'd end the sentence after the 5321 reference,= and make the last phrase into another sentence, like, "This document gives= examples of use in IMAP and SMTP." WFM. =C2=A0Done. >=C2=A0> -- Section 2 -->=C2=A0> =C2=A0 =C2=A0Note that the IMAP SASL speci= fication requires base64 encoding, see> =C2=A0 =C2=A0Section 4 of [RFC4648]= , not this memo.>=C2=A0> Nit: That seems kind of an odd way to put it, in a= ddition to its having a comma splice. =C2=A0Why not this?:>=C2=A0> NEW> =C2= =A0 =C2=A0Note that the IMAP SASL specification requires base64 encoding, a= s> =C2=A0 =C2=A0specified in Section 4 of [RFC4648].> END WFM. Done. >=C2=A0> -- Section 3.2 --> Nit: "vaialble" -> "available" Fixed >=C2=A0> -- Section 3.2.2 -->=C2=A0> =C2=A0 =C2=A0 =C2=A0 scope (OPTIONAL):= =C2=A0An OAuth scope which is valid to access the> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0service. =C2=A0This may be omitted which implies that unscoped= > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0tokens are required. =C2=A0If a scope i= s specified then a single> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0scope is prefe= rred, use of a space separated list of scopes is> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0NOT RECOMMENDED.>=C2=A0> Why is it "NOT RECOMMENDED"? =C2=A0What = interoperability or security issue is in play here that makes this "SHOULD = NOT"? This isn't my preference for language, but some folks have concerns about u= singmultiple scopes and how that all gets resolved and whether the client n= eeds to=C2=A0understand scope strings to determine if they already have the= scope they need. >=C2=A0> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The server MAY return different = URLs for users in> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0different domains and = the client SHOULD NOT cache a single> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ret= urned value and assume it applies for all users/domains that> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0the server suports. =C2=A0The returned discovery docum= ent SHOULD> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0have all data elements requir= ed by the OpenID Connect Discovery> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0speci= fication populated.>=C2=A0> Similar questions for the SHOULD NOT and SHOULD= here. =C2=A0In this case, I don't understand why they aren't "MUST NOT" an= d "MUST": for the first, I don't understand how a client can interoperate w= ith a server if it violates this, and for the second, if they data elements= are "required", why isn't including them a "MUST"? There are implementations now that don't support Dynamic Client Reg. and re= quiring it would make no sense for them. >=C2=A0> (Nit: The "if available" at the end of the paragraph is unnecessar= y; if one is not available, it certainly can't be used.) We were leaving the door open for other discovery mechanisms so that this i= sn't MTI if there are other options. >=C2=A0> -- Section 4.1 -->=C2=A0> =C2=A0 =C2=A0The> =C2=A0 =C2=A0underlyin= g TLS establishment is not shown but is required for using> =C2=A0 =C2=A0Be= arer Tokens per that specification.>=C2=A0> =C2=A0 =C2=A0S: * OK IMAP4rev1 = Server Ready> =C2=A0 =C2=A0C: t0 CAPABILITY> =C2=A0 =C2=A0S: * CAPABILITY I= MAP4rev1 AUTH=3DOAUTHBEARER SASL-IR> =C2=A0 =C2=A0S: t0 OK Completed>=C2=A0= > The problem with this is that if the underlying TLS establishment is done= through STARTTLS on port 143, that would come between the first line ("S:>= * OK IMAP4rev1 Server Ready") and the second. =C2=A0And that makes the exa= mple a bit odd. =C2=A0The easiest way out of that is simply to remove the f= irst line. =C2=A0Or, better, to replace the first line with something like = "[Initial connection and TLS establishment...]". =C2=A0(This applies to the= subsequent sections as well.) WFM. >=C2=A0> I wonder why you don't wrap the decoded payload here the same way = you do in Section 4.2 (or there the same as here). =C2=A0I suggest that the= re'd be less room for any confusion if you did them all (4.3 also) the same= way (I don't care which way you choose). Because the example for SMTP is wrong and I hadn't noticed that. =C2=A0Fixi= ng the port number and including the decoded text. >=C2=A0> In the SMTP part, you say this:>=C2=A0> =C2=A0 =C2=A0Note> =C2=A0 = =C2=A0that line breaks are inserted for readability, and that the SMTP> =C2= =A0 =C2=A0protocol terminates lines with CR and LF characters (ASCII values= > =C2=A0 =C2=A00x0D and 0x0A), these are not displayed explicitly in the ex= ample.>=C2=A0> The same is true for the IMAP protocol and example, but you = don't say this there. =C2=A0Actually, I don't think you need to say it in e= ither place, and suggest simply removing it here (and in Section 4.4). Done >=C2=A0> -- Section 4.4 --> In the SMTP protocol, you should have "[Negotia= te TLS...]" before the SMTP AUTH command, as you do in Section 4.1. Done>=C2=A0 Changes committed to my working copy of the pending -23, which can be found= at https://github.com/sweetums/idrafts/commit/98314659561cdfed59d39ac0e193= f09f93a75da3 Thank you. -bill =20 On Tuesday, May 26, 2015 8:57 AM, Barry Leiba wrote: =20 Barry Leiba has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Another excellent, informative shepherd writeup, which helped with my review of the document.=C2=A0 (And, I'll say, most of the really useful writeups, as this one, seem to use the "essay" format, rather than the Q&A format.)=C2=A0 Thanks, Ben, for the writeup. -- Section 1 -- =C2=A0 way to use the Simple Authentication and Security Layer (SASL) =C2=A0 [RFC4422] to gain access to resources when using non-HTTP-based =C2=A0 protocols, such as the Internet Message Access Protocol (IMAP) =C2=A0 [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5321], =C2=A0 which is what this memo uses in the examples. When I first read this, I thought the last phrase was bound to SMTP... but then I see that both IMAP and SMTP are used in the examples.=C2=A0 So, = a small thing, but I'd end the sentence after the 5321 reference, and make the last phrase into another sentence, like, "This document gives examples of use in IMAP and SMTP." -- Section 2 -- =C2=A0 Note that the IMAP SASL specification requires base64 encoding, see =C2=A0 Section 4 of [RFC4648], not this memo. Nit: That seems kind of an odd way to put it, in addition to its having a comma splice.=C2=A0 Why not this?: NEW =C2=A0 Note that the IMAP SASL specification requires base64 encoding, as =C2=A0 specified in Section 4 of [RFC4648]. END -- Section 3.2 -- Nit: "vaialble" -> "available" -- Section 3.2.2 -- =C2=A0 =C2=A0 =C2=A0 scope (OPTIONAL):=C2=A0 An OAuth scope which is valid = to access the =C2=A0 =C2=A0 =C2=A0 =C2=A0 service.=C2=A0 This may be omitted which implie= s that unscoped =C2=A0 =C2=A0 =C2=A0 =C2=A0 tokens are required.=C2=A0 If a scope is specif= ied then a single =C2=A0 =C2=A0 =C2=A0 =C2=A0 scope is preferred, use of a space separated li= st of scopes is =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECOMMENDED. Why is it "NOT RECOMMENDED"?=C2=A0 What interoperability or security issue = is in play here that makes this "SHOULD NOT"? =C2=A0 =C2=A0 =C2=A0 =C2=A0 The server MAY return different URLs for users = in =C2=A0 =C2=A0 =C2=A0 =C2=A0 different domains and the client SHOULD NOT cac= he a single =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned value and assume it applies for all us= ers/domains that =C2=A0 =C2=A0 =C2=A0 =C2=A0 the server suports.=C2=A0 The returned discover= y document SHOULD =C2=A0 =C2=A0 =C2=A0 =C2=A0 have all data elements required by the OpenID C= onnect Discovery =C2=A0 =C2=A0 =C2=A0 =C2=A0 specification populated. Similar questions for the SHOULD NOT and SHOULD here.=C2=A0 In this case, I don't understand why they aren't "MUST NOT" and "MUST": for the first, I don't understand how a client can interoperate with a server if it violates this, and for the second, if they data elements are "required", why isn't including them a "MUST"? (Nit: The "if available" at the end of the paragraph is unnecessary; if one is not available, it certainly can't be used.) -- Section 4.1 -- =C2=A0 The =C2=A0 underlying TLS establishment is not shown but is required for using =C2=A0 Bearer Tokens per that specification. =C2=A0 S: * OK IMAP4rev1 Server Ready =C2=A0 C: t0 CAPABILITY =C2=A0 S: * CAPABILITY IMAP4rev1 AUTH=3DOAUTHBEARER SASL-IR =C2=A0 S: t0 OK Completed The problem with this is that if the underlying TLS establishment is done through STARTTLS on port 143, that would come between the first line ("S: * OK IMAP4rev1 Server Ready") and the second.=C2=A0 And that makes the exam= ple a bit odd.=C2=A0 The easiest way out of that is simply to remove the first line.=C2=A0 Or, better, to replace the first line with something like "[Initial connection and TLS establishment...]".=C2=A0 (This applies to the subsequent sections as well.) I wonder why you don't wrap the decoded payload here the same way you do in Section 4.2 (or there the same as here).=C2=A0 I suggest that there'd be less room for any confusion if you did them all (4.3 also) the same way (I don't care which way you choose). In the SMTP part, you say this: =C2=A0 Note =C2=A0 that line breaks are inserted for readability, and that the SMTP =C2=A0 protocol terminates lines with CR and LF characters (ASCII values =C2=A0 0x0D and 0x0A), these are not displayed explicitly in the example. The same is true for the IMAP protocol and example, but you don't say this there.=C2=A0 Actually, I don't think you need to say it in either plac= e, and suggest simply removing it here (and in Section 4.4). -- Section 4.4 -- In the SMTP protocol, you should have "[Negotiate TLS...]" before the SMTP AUTH command, as you do in Section 4.1. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_2389502_397118509.1432673344489 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> -----------------------------= -----------------------------------------
&= gt; COMMENT:
> -------------------------= ---------------------------------------------
> 
> Another excellent, infor= mative shepherd writeup, which helped with my review of the document.  = ;(And, I'll say, most of the really useful writeups, as this one, seem to u= se the "essay" format, rather than the Q&A format.)  Thanks, Ben, = for the writeup.
> 
> -- Section 1 --
>&= nbsp;
>    way to use the Simp= le Authentication and Security Layer (SASL)
>    [RFC4422] to gain access to resources when using non-HTT= P-based
>    protocols, such a= s the Internet Message Access Protocol (IMAP)
>    [RFC3501] and the Simple Mail Transfer Protocol (SMTP)= [RFC5321],
>    which is what= this memo uses in the examples.
> =
> When I first read this, I thought the= last phrase was bound to SMTP...
> but = then I see that both IMAP and SMTP are used in the examples.  So, a sm= all thing, but I'd end the sentence after the 5321 reference, and make the = last phrase into another sentence, like, "This document gives examples of u= se in IMAP and SMTP."

WFM.  Done.

>= ; 
> -- Section 2 --
> 
>   &n= bsp;Note that the IMAP SASL specification requires base64 encoding, see
>    Section 4 of [RFC4648], not = this memo.
> 
> Nit: That seems kind of an odd way to put it, in addition t= o its having a comma splice.  Why not this?:
> 
> NEW
>    Note that the IMAP SASL specification re= quires base64 encoding, as
>   &nbs= p;specified in Section 4 of [RFC4648].
>= END

WFM. Done.

> 
> -- Section 3.2 --
&g= t; Nit: "vaialble" -> "available"

Fixed

> 
> -- Section 3.2.2 --
<= div class=3D"" style=3D"">> 
> &= nbsp;     scope (OPTIONAL):  An OAuth scope which is valid t= o access the
>       &nbs= p;  service.  This may be omitted which implies that unscoped
>          tokens = are required.  If a scope is specified then a single
>          scope is preferred,= use of a space separated list of scopes is
>          NOT RECOMMENDED.
> 
> Why is it "NO= T RECOMMENDED"?  What interoperability or security issue is in play he= re that makes this "SHOULD NOT"?

This isn't my preference = for language, but some folks have concerns about using
multiple scopes and how that all gets resolved and whether the = client needs to 
understand scope stri= ngs to determine if they already have the scope they need.


> 
>          The serv= er MAY return different URLs for users in
&= gt;          different domains and the client SHOU= LD NOT cache a single
>     &n= bsp;    returned value and assume it applies for all users/domain= s that
>         &nb= sp;the server suports.  The returned discovery document SHOULD
>          have all da= ta elements required by the OpenID Connect Discovery
>          specification populated.
> 
&= gt; Similar questions for the SHOULD NOT and SHOULD here.  In this cas= e, I don't understand why they aren't "MUST NOT" and "MUST": for the first,= I don't understand how a client can interoperate with a server if it viola= tes this, and for the second, if they data elements are "required", why isn= 't including them a "MUST"?

There are implementations now t= hat don't support Dynamic Client Reg. and requiring it would make no sense = for them.

<= div class=3D"" style=3D"">> 
> (= Nit: The "if available" at the end of the paragraph is unnecessary; if one = is not available, it certainly can't be used.)

We were le= aving the door open for other discovery mechanisms so that this isn't MTI i= f there are other options.

> 
> -- Section 4.1 --
> = ;
>    The
>    underlying TLS establishment is not shown bu= t is required for using
>    B= earer Tokens per that specification.
>&n= bsp;
>    S: * OK IMAP4rev1 Se= rver Ready
>    C: t0 CAPABILI= TY
>    S: * CAPABILITY IMAP4r= ev1 AUTH=3DOAUTHBEARER SASL-IR
>   =  S: t0 OK Completed
> 
> The problem with this is that if the underlyi= ng TLS establishment is done through STARTTLS on port 143, that would come = between the first line ("S:
> * OK IMAP4= rev1 Server Ready") and the second.  And that makes the example a bit = odd.  The easiest way out of that is simply to remove the first line. =  Or, better, to replace the first line with something like "[Initial c= onnection and TLS establishment...]".  (This applies to the subsequent= sections as well.)

WFM.
> 
> I wonder why you don't wrap the decoded paylo= ad here the same way you do in Section 4.2 (or there the same as here). &nb= sp;I suggest that there'd be less room for any confusion if you did them al= l (4.3 also) the same way (I don't care which way you choose).

Because the example for SMTP is wrong and I hadn't noticed that. &nbs= p;Fixing the port number and including the decoded text.

&g= t; 
> In the SMTP part, you say thi= s:
> 
>    Note
>    = ;that line breaks are inserted for readability, and that the SMTP
>    protocol terminates lines with CR = and LF characters (ASCII values
>  =  0x0D and 0x0A), these are not displayed explicitly in the example.
> 
&= gt; The same is true for the IMAP protocol and example, but you don't say t= his there.  Actually, I don't think you need to say it in either place= , and suggest simply removing it here (and in Section 4.4).

Done

> 
> -- Se= ction 4.4 --
> In the SMTP protocol, you= should have "[Negotiate TLS...]" before the SMTP AUTH command, as you do i= n Section 4.1.

Done
>&nb= sp;

Changes committed to my working copy of the pending -23= , which can be found at https://github.com/sweetums/idrafts/commit/98314659= 561cdfed59d39ac0e193f09f93a75da3

Thank you.

-bill





= On Tuesday, May 26, 2015 8:57 AM, Barry Le= iba <barryleiba@computer.org> wrote:


Barry Leiba has entered the following ballot po= sition for
draft-ietf-kitten-sasl-oauth-22: No Objection

When res= ponding, please keep the subject line intact and reply to all
email addr= esses included in the To and CC lines. (Feel free to cut this
introducto= ry paragraph, however.)


Please refer to https://www= .ietf.org/iesg/statement/discuss-criteria.html
for more information = about IESG DISCUSS and COMMENT positions.


The document, along wi= th other ballot positions, can be found here:
https://= datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/



-= ---------------------------------------------------------------------
CO= MMENT:
-----------------------------------------------------------------= -----

Another excellent, informative shepherd writeup, which helped = with my
review of the document.  (And, I'll say, most of the really= useful
writeups, as this one, seem to use the "essay" format, rather th= an the
Q&A format.)  Thanks, Ben, for the writeup.

-- Se= ction 1 --

  way to use the Simple Authentication and Security= Layer (SASL)
  [RFC4422] to gain access to resources when using n= on-HTTP-based
  protocols, such as the Internet Message Access Pro= tocol (IMAP)
  [RFC3501] and the Simple Mail Transfer Protocol (SM= TP) [RFC5321],
  which is what this memo uses in the examples.
=
When I first read this, I thought the last phrase was bound to SMTP...<= br>but then I see that both IMAP and SMTP are used in the examples.  S= o, a
small thing, but I'd end the sentence after the 5321 reference, and= make
the last phrase into another sentence, like, "This document gives<= br>examples of use in IMAP and SMTP."

-- Section 2 --

  = Note that the IMAP SASL specification requires base64 encoding, see
&nb= sp; Section 4 of [RFC4648], not this memo.

Nit: That seems kind of = an odd way to put it, in addition to its having a
comma splice.  Wh= y not this?:

NEW
  Note that the IMAP SASL specification re= quires base64 encoding, as
  specified in Section 4 of [RFC4648].<= br>END

-- Section 3.2 --
Nit: "vaialble" -> "available"
-- Section 3.2.2 --

      scope (OPTIONAL):  An= OAuth scope which is valid to access the
        s= ervice.  This may be omitted which implies that unscoped
  &nb= sp;     tokens are required.  If a scope is specified then = a single
        scope is preferred, use of a space= separated list of scopes is
        NOT RECOMMENDE= D.

Why is it "NOT RECOMMENDED"?  What interoperability or secur= ity issue is
in play here that makes this "SHOULD NOT"?

  &n= bsp;     The server MAY return different URLs for users in
&n= bsp;       different domains and the client SHOULD NOT cach= e a single
        returned value and assume it app= lies for all users/domains that
        the server = suports.  The returned discovery document SHOULD
    &nbs= p;   have all data elements required by the OpenID Connect Discovery<= br>        specification populated.

Similar que= stions for the SHOULD NOT and SHOULD here.  In this case, I
don't u= nderstand why they aren't "MUST NOT" and "MUST": for the first, I
don't = understand how a client can interoperate with a server if it
violates th= is, and for the second, if they data elements are "required",
why isn't = including them a "MUST"?

(Nit: The "if available" at the end of the = paragraph is unnecessary; if
one is not available, it certainly can't be= used.)

-- Section 4.1 --

  The
  underlying T= LS establishment is not shown but is required for using
  Bearer T= okens per that specification.

  S: * OK IMAP4rev1 Server Ready=
  C: t0 CAPABILITY
  S: * CAPABILITY IMAP4rev1 AUTH=3DOA= UTHBEARER SASL-IR
  S: t0 OK Completed

The problem with thi= s is that if the underlying TLS establishment is done
through STARTTLS o= n port 143, that would come between the first line ("S:
* OK IMAP4rev1 S= erver Ready") and the second.  And that makes the example
a bit odd= .  The easiest way out of that is simply to remove the first
line.&= nbsp; Or, better, to replace the first line with something like
"[Initia= l connection and TLS establishment...]".  (This applies to the
subs= equent sections as well.)

I wonder why you don't wrap the decoded pa= yload here the same way you do
in Section 4.2 (or there the same as here= ).  I suggest that there'd be
less room for any confusion if you di= d them all (4.3 also) the same way
(I don't care which way you choose).<= br>
In the SMTP part, you say this:

  Note
  that = line breaks are inserted for readability, and that the SMTP
  prot= ocol terminates lines with CR and LF characters (ASCII values
  0x= 0D and 0x0A), these are not displayed explicitly in the example.

The= same is true for the IMAP protocol and example, but you don't say
this = there.  Actually, I don't think you need to say it in either place,and suggest simply removing it here (and in Section 4.4).

-- Sectio= n 4.4 --
In the SMTP protocol, you should have "[Negotiate TLS...]" befo= re the
SMTP AUTH command, as you do in Section 4.1.


_________= ______________________________________
Kitten mailing list
Kitten@ietf.org=
https://www.ietf.org/mailman/listinfo/kitten


=
------=_Part_2389502_397118509.1432673344489-- From nobody Tue May 26 13:55:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48801ACE70 for ; Tue, 26 May 2015 13:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84nE6xjPtxYC for ; Tue, 26 May 2015 13:55:54 -0700 (PDT) Received: from nm35-vm2.bullet.mail.gq1.yahoo.com (nm35-vm2.bullet.mail.gq1.yahoo.com [98.136.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 583C41B318B for ; Tue, 26 May 2015 13:53:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432673588; bh=tk6cwbTZmLirTvWonPaZMo2NCmmVw3yWK/YkT8r3noM=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=SinB2cXY5RsvtKIw7BVR/xx4wqHI478MnoDvslxY7eWtO3qWpOQGaAIk374BmLZ8UeE6oQDSYQ82y6EOn1jEm2olImFDdLCbNdK8dvpSobVSEHL0GtJxboGNrEfNLEquxMlJ2/H0eRBdqL2zU2Q/eFJLMVom5RA7ESBNWMQDT7DwgqkNsewQPyHDwaOWPiDqwDEZfSEomlf1OMVMrSsLq2O4DjSH8WTbOtfljE2rVkvQADouOjrBADrIBjloOzON8q8BzwifzzQRr1wS0seErO1kwZOMUJLIUwDEhi1ydo5LbeD5bObJeggUMeBCmO2FBwKRgKmk3kmVmNZKXRpGfA== Received: from [127.0.0.1] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 26 May 2015 20:53:08 -0000 Received: from [98.137.12.63] by nm35.bullet.mail.gq1.yahoo.com with NNFMP; 26 May 2015 20:50:23 -0000 Received: from [98.139.215.142] by tm8.bullet.mail.gq1.yahoo.com with NNFMP; 26 May 2015 20:50:23 -0000 Received: from [98.139.212.245] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 26 May 2015 20:50:23 -0000 Received: from [127.0.0.1] by omp1054.mail.bf1.yahoo.com with NNFMP; 26 May 2015 20:50:23 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 181741.8765.bm@omp1054.mail.bf1.yahoo.com X-YMail-OSG: .CWoxzUVM1lygTAnYIrgY_E2n9kQu0O29ojSTuLxr9XDEvi._LHFouE7MwkM9vq ttYLkwN9Hta.qEk7fAROrziFdbMXlUBfkpW4PP4nfWUjxY_dJB_bcWiK8fZVlUNzDBArNHnkT.hn oKy8t5D9iRzhGz10CI0KJnaW9k2Jv2ljULInifc7LOXiLSfLLPfMz7miuJeLWt2GtN4pFCxlSn_7 YNBtFRIrjlBacLpn67zU1fgIRQehC3S_IL4ua_JX9N3Ig6vluSNHdvhQq.f9fL3lgn7rgBQSVKXz ChS3Nk8SF5h.U9sjyJHLCnzFHSblyvVwqJUIVdZcCeXChwIJwJJPABuBoKwwHMQjbRDCMU8v.mY6 XsI7eawaeuKBPdZvIaYmcK36edlWg6czxLj1yCvAXhvwmpMea1Lk5t_zMkIIZGVxFAeMWCGFpRIQ 8GX98QVbatkO.FNqobzcQwhXOX7F_JJpePqoRW9fbrXyd2Wt20ZMx.S0QXGnHMcwPNxzT489P0vG qdM_CZ_E6sfQLcASy Received: by 76.13.26.66; Tue, 26 May 2015 20:50:22 +0000 Date: Tue, 26 May 2015 20:50:22 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk , Barry Leiba Message-ID: <474987828.2397910.1432673422157.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2397909_1524357971.1432673422151" Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:55:56 -0000 ------=_Part_2397909_1524357971.1432673422151 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Replied to Barry's just now, but hadn't seen this yet. =C2=A0I think everyt= hing here is addressed in the other mail. -bill=20 On Tuesday, May 26, 2015 1:41 PM, Benjamin Kaduk wrote= : =20 Hi Barry, On Tue, 26 May 2015, Barry Leiba wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Another excellent, informative shepherd writeup, which helped with my > review of the document.=C2=A0 (And, I'll say, most of the really useful > writeups, as this one, seem to use the "essay" format, rather than the > Q&A format.)=C2=A0 Thanks, Ben, for the writeup. You're welcome :) > -- Section 1 -- > >=C2=A0 =C2=A0 way to use the Simple Authentication and Security Layer (SAS= L) >=C2=A0 =C2=A0 [RFC4422] to gain access to resources when using non-HTTP-ba= sed >=C2=A0 =C2=A0 protocols, such as the Internet Message Access Protocol (IMA= P) >=C2=A0 =C2=A0 [RFC3501] and the Simple Mail Transfer Protocol (SMTP) [RFC5= 321], >=C2=A0 =C2=A0 which is what this memo uses in the examples. > > When I first read this, I thought the last phrase was bound to SMTP... > but then I see that both IMAP and SMTP are used in the examples.=C2=A0 So= , a > small thing, but I'd end the sentence after the 5321 reference, and make > the last phrase into another sentence, like, "This document gives > examples of use in IMAP and SMTP." "which is what this memo uses" is certainly wrong, since 'is' is singular but should be plural to apply to both IMAP and SMTP.=C2=A0 But I think your version is better, maybe with the addition of "both" before "IMAP and SMTP" in the last sentence. > -- Section 2 -- > >=C2=A0 =C2=A0 Note that the IMAP SASL specification requires base64 encodi= ng, see >=C2=A0 =C2=A0 Section 4 of [RFC4648], not this memo. > > Nit: That seems kind of an odd way to put it, in addition to its having a > comma splice.=C2=A0 Why not this?: > > NEW >=C2=A0 =C2=A0 Note that the IMAP SASL specification requires base64 encodi= ng, as >=C2=A0 =C2=A0 specified in Section 4 of [RFC4648]. > END I think I had noted the comma splice in a previous review but it slipped through the cracks.=C2=A0 Your version looks fine. > -- Section 3.2 -- > Nit: "vaialble" -> "available" Thanks. > -- Section 3.2.2 -- > >=C2=A0 =C2=A0 =C2=A0 scope (OPTIONAL):=C2=A0 An OAuth scope which is valid= to access the >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service.=C2=A0 This may be omitted whic= h implies that unscoped >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tokens are required.=C2=A0 If a scope i= s specified then a single >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scope is preferred, use of a space sepa= rated list of scopes is >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECOMMENDED. > > Why is it "NOT RECOMMENDED"?=C2=A0 What interoperability or security issu= e is > in play here that makes this "SHOULD NOT"? I am a little hazy on this, but I seem to recall that some deployed software assumes that only a single scope will be used, so this is for interoperability.=C2=A0 (Bill, please jump in if I'm confused.) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The server MAY return different URLs fo= r users in >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 different domains and the client SHOULD= NOT cache a single >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned value and assume it applies fo= r all users/domains that >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the server suports.=C2=A0 The returned = discovery document SHOULD >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have all data elements required by the = OpenID Connect Discovery >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specification populated. > > Similar questions for the SHOULD NOT and SHOULD here.=C2=A0 In this case,= I > don't understand why they aren't "MUST NOT" and "MUST": for the first, I > don't understand how a client can interoperate with a server if it > violates this, and for the second, if they data elements are "required", > why isn't including them a "MUST"? This section was one of the repeated areas of contention over the last calls, so I am somewhat reluctant to bring it back to the WG for discussion.=C2=A0 I think there would be somewhat more support for SHOULD N= OT --> MUST NOT; the SHOULD for discovery is, IIRC, something of a compromise, since some parties did not want to bring in a hard dependency on OpenID Connect's choices.=C2=A0 The only reason I can come up for the SH= OULD NOT, off the top of my head, is if some vendor distributed a mail client that was only ever going to talk to that same vendor's server. > (Nit: The "if available" at the end of the paragraph is unnecessary; if > one is not available, it certainly can't be used.) That's true, but I like the flow of the sentence with the extra redundancy better than without it. > -- Section 4.1 -- > >=C2=A0 =C2=A0 The >=C2=A0 =C2=A0 underlying TLS establishment is not shown but is required fo= r using >=C2=A0 =C2=A0 Bearer Tokens per that specification. > >=C2=A0 =C2=A0 S: * OK IMAP4rev1 Server Ready >=C2=A0 =C2=A0 C: t0 CAPABILITY >=C2=A0 =C2=A0 S: * CAPABILITY IMAP4rev1 AUTH=3DOAUTHBEARER SASL-IR >=C2=A0 =C2=A0 S: t0 OK Completed > > The problem with this is that if the underlying TLS establishment is done > through STARTTLS on port 143, that would come between the first line ("S: > * OK IMAP4rev1 Server Ready") and the second.=C2=A0 And that makes the ex= ample > a bit odd.=C2=A0 The easiest way out of that is simply to remove the firs= t > line.=C2=A0 Or, better, to replace the first line with something like > "[Initial connection and TLS establishment...]".=C2=A0 (This applies to t= he > subsequent sections as well.) I would be fine with "[Initial connection and TLS establishment...]". > I wonder why you don't wrap the decoded payload here the same way you do > in Section 4.2 (or there the same as here).=C2=A0 I suggest that there'd = be > less room for any confusion if you did them all (4.3 also) the same way > (I don't care which way you choose). The examples were added at different times, so keeping them in sync has been a bit tough.=C2=A0 Hopefully we can enlist the help of the RFC Editor = in ensuring consistency of formatting. > In the SMTP part, you say this: > >=C2=A0 =C2=A0 Note >=C2=A0 =C2=A0 that line breaks are inserted for readability, and that the = SMTP >=C2=A0 =C2=A0 protocol terminates lines with CR and LF characters (ASCII v= alues >=C2=A0 =C2=A0 0x0D and 0x0A), these are not displayed explicitly in the ex= ample. > > The same is true for the IMAP protocol and example, but you don't say > this there.=C2=A0 Actually, I don't think you need to say it in either pl= ace, > and suggest simply removing it here (and in Section 4.4). Hmm, it is probably okay to not mention this, as you propose.=C2=A0 Anyone implementing SMTP or IMAP will need to be conversant with the relevant specifications... > -- Section 4.4 -- > In the SMTP protocol, you should have "[Negotiate TLS...]" before the > SMTP AUTH command, as you do in Section 4.1. The running text does have "TLS negotiation is not shown but as noted above it is required for the use of Bearer Tokens", but I support making the examples consistent (and explicit about the use of TLS). -Ben _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_2397909_1524357971.1432673422151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Replied to Barry's just now, but hadn't seen = this yet.  I think everything here is addressed in the other mail.

-bill


On Tuesday, May 26, 2015 1:41 PM, Benjamin Kaduk <ka= duk@MIT.EDU> wrote:


Hi Barry,

On Tue, 26 May 2015,= Barry Leiba wrote:

> -------------= ---------------------------------------------------------
> COMMENT:
> -------------------------------------= ---------------------------------
>
= > Another excellent, informative shepherd writeup, which helped with my<= br clear=3D"none">> review of the document.  (And, I'll say, most o= f the really useful
> writeups, as this one, seem to u= se the "essay" format, rather than the
> Q&A forma= t.)  Thanks, Ben, for the writeup.

You're welcome :)

> -- Section 1 = --
>
>    way to use th= e Simple Authentication and Security Layer (SASL)
>&nb= sp;   [RFC4422] to gain access to resources when using non-HTTP-based<= br clear=3D"none">>    protocols, such as the Internet Message= Access Protocol (IMAP)
>    [RFC3501] and t= he Simple Mail Transfer Protocol (SMTP) [RFC5321],
>&n= bsp;   which is what this memo uses in the examples.
>
> When I first read this, I thought the last phr= ase was bound to SMTP...
> but then I see that both IM= AP and SMTP are used in the examples.  So, a
> sm= all thing, but I'd end the sentence after the 5321 reference, and make
> the last phrase into another sentence, like, "This docum= ent gives
> examples of use in IMAP and SMTP."

"which is what this memo uses" is certainly w= rong, since 'is' is singular
but should be plural to appl= y to both IMAP and SMTP.  But I think your
version i= s better, maybe with the addition of "both" before "IMAP and
SMTP" in the last sentence.

> -= - Section 2 --
>
>    N= ote that the IMAP SASL specification requires base64 encoding, see
>    Section 4 of [RFC4648], not this memo.
>
> Nit: That seems kind of an odd way to= put it, in addition to its having a
> comma splice.&n= bsp; Why not this?:
>
> NEW
>    Note that the IMAP SASL specification requir= es base64 encoding, as
>    specified in Sec= tion 4 of [RFC4648].
> END

I think I had noted the comma splice in a previous review but it = slipped
through the cracks.  Your version looks fine= .

> -- Section 3.2 --
> Nit: "vaialble" -> "available"

Thanks.

> -- Section 3.2.2 --=
>
>      scope (= OPTIONAL):  An OAuth scope which is valid to access the
>          service.  This may be omitt= ed which implies that unscoped
>      &= nbsp;   tokens are required.  If a scope is specified then a sing= le
>          scope is prefer= red, use of a space separated list of scopes is
> = ;         NOT RECOMMENDED.
>
> Why is it "NOT RECOMMENDED"?  What interoperability = or security issue is
> in play here that makes this "S= HOULD NOT"?

I am a little hazy on this= , but I seem to recall that some deployed
software assume= s that only a single scope will be used, so this is for
i= nteroperability.  (Bill, please jump in if I'm confused.)

>          The server = MAY return different URLs for users in
>    =       different domains and the client SHOULD NOT cache a si= ngle
>          returned valu= e and assume it applies for all users/domains that
>&n= bsp;         the server suports.  The returned dis= covery document SHOULD
>        &n= bsp; have all data elements required by the OpenID Connect Discovery
>          specification populated.=
>
> Similar questions for the SH= OULD NOT and SHOULD here.  In this case, I
> don'= t understand why they aren't "MUST NOT" and "MUST": for the first, I
> don't understand how a client can interoperate with a serv= er if it
> violates this, and for the second, if they = data elements are "required",
> why isn't including th= em a "MUST"?

This section was one of t= he repeated areas of contention over the last
calls, so I= am somewhat reluctant to bring it back to the WG for
dis= cussion.  I think there would be somewhat more support for SHOULD NOT<= br clear=3D"none">--> MUST NOT; the SHOULD for discovery is, IIRC, somet= hing of a
compromise, since some parties did not want to = bring in a hard dependency
on OpenID Connect's choices.&n= bsp; The only reason I can come up for the SHOULD
NOT, of= f the top of my head, is if some vendor distributed a mail client
that was only ever going to talk to that same vendor's server.
> (Nit: The "if available" at the end= of the paragraph is unnecessary; if
> one is not avai= lable, it certainly can't be used.)

Th= at's true, but I like the flow of the sentence with the extra
redundancy better than without it.

> -- Section 4.1 --
>
> = ;   The
>    underlying TLS establishme= nt is not shown but is required for using
>  &nbs= p; Bearer Tokens per that specification.
>
>    S: * OK IMAP4rev1 Server Ready
&= gt;    C: t0 CAPABILITY
>    S: * = CAPABILITY IMAP4rev1 AUTH=3DOAUTHBEARER SASL-IR
> = ;   S: t0 OK Completed
>
> T= he problem with this is that if the underlying TLS establishment is done> through STARTTLS on port 143, that would come between = the first line ("S:
> * OK IMAP4rev1 Server Ready") an= d the second.  And that makes the example
> a bit= odd.  The easiest way out of that is simply to remove the first
> line.  Or, better, to replace the first line with so= mething like
> "[Initial connection and TLS establishm= ent...]".  (This applies to the
> subsequent sect= ions as well.)

I would be fine with "[= Initial connection and TLS establishment...]".

> I wonder why you don't wrap the decoded payload here the sam= e way you do
> in Section 4.2 (or there the same as he= re).  I suggest that there'd be
> less room for a= ny confusion if you did them all (4.3 also) the same way
= > (I don't care which way you choose).

The examples were added at different times, so keeping them in sync has=
been a bit tough.  Hopefully we can enlist the help= of the RFC Editor in
ensuring consistency of formatting.=

> In the SMTP part, you say this:<= br clear=3D"none">>
>    Note
>    that line breaks are inserted for readability, and= that the SMTP
>    protocol terminates line= s with CR and LF characters (ASCII values
>  &nbs= p; 0x0D and 0x0A), these are not displayed explicitly in the example.
>
> The same is true for the IMAP prot= ocol and example, but you don't say
> this there. = ; Actually, I don't think you need to say it in either place,
> and suggest simply removing it here (and in Section 4.4).

Hmm, it is probably okay to not mention this,= as you propose.  Anyone
implementing SMTP or IMAP w= ill need to be conversant with the relevant
specification= s...

> -- Section 4.4 --
> In the SMTP protocol, you should have "[Negotiate TLS...]" b= efore the
> SMTP AUTH command, as you do in Section 4.= 1.

The running text does have "TLS neg= otiation is not shown but as noted
above it is required f= or the use of Bearer Tokens", but I support making
the ex= amples consistent (and explicit about the use of TLS).


-Ben

____________________________________________= ___
Kitten mailing list
Kitte= n@ietf.org
https://www.ietf.org/mailma= n/listinfo/kitten


=
------=_Part_2397909_1524357971.1432673422151-- From nobody Tue May 26 14:26:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 815A11B31ED for ; Tue, 26 May 2015 14:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hql0IPlgvyvw for ; Tue, 26 May 2015 14:26:53 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id CFF521B31E4 for ; Tue, 26 May 2015 14:26:53 -0700 (PDT) Received: from homiemail-a55.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTP id 06885161D; Tue, 26 May 2015 14:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2Gyakdsg88inMu 1p+f0NI+oETYo=; b=SAMa0MkDYYMooTxcc48HQU6yPGXHLEaAU0KJgjkCr/QTQ+ X3GWRcp6VeqptdQZFBkt8AzvDlwTrBgd8ewhVqJ4JbhXRfriilxbPaRYk4YuPU2I eb1knNELf2Zf79XQzwefMU5o/VrECGSpOmsTfU4FXSPSVLhd6lbt7NFKjo2MA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a55.g.dreamhost.com (Postfix) with ESMTPA id EDBB81612; Tue, 26 May 2015 14:26:51 -0700 (PDT) Date: Tue, 26 May 2015 16:26:50 -0500 From: Nico Williams To: Stephen Farrell Message-ID: <20150526212650.GC27628@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <20150523202618.GC2166@localhost> <20150523223946.15ae8c11@latte.josefsson.org> <20150523214351.GD2166@localhost> <20150524004438.5121c26b@latte.josefsson.org> <556105C3.8020303@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556105C3.8020303@cs.tcd.ie> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 21:26:55 -0000 On Sat, May 23, 2015 at 11:57:07PM +0100, Stephen Farrell wrote: > On 23/05/15 23:44, Simon Josefsson wrote: > > Perhaps this is a question for the TLS WG -- whether they intend > > tls-session-hash to apply as a mandatory fix to all TLS versions or > > not. The document does not say anything about updates now, which means > > "TLS needs fixing" won't necessarily happen. > > So this may be helpful or not depending on how much one > considers IETF minutae important... We've discussed this in the TLS WG. There was no consensus call as such, so... I don't know what the status is. Regardless, it's not really appropriate for a SASL/GSS mechanism to introduce a new TLS channel binding. Nor is it necessary assuming that TLS is fixed to use the session hash. It would be appropriate to: a) add security considerations text about the dangers of using tls-unique with an unpatched TLS implementation with resumed sessions; b) separately pursue a new TLS channel binding, though perhaps having an informative references from any new SASL/GSS mech(s) on the new TLS channel binding. Normative references would belong in the _application_ protocols, not the SASL/GSS mechanism. There isn't consensus for (b) yet. I'm not against it, but I note that it shouldn't be necessary. The TLS session hash fix has to get deployed, full stop. > During IESG evaluation we agreed to have the session hash > document be an update of 5246. The start of that thread is It should probably also update RFC5929. I made a comment as to that on the DISCUSS. There was no further discussion. > at [1] and the resolution is downthread or maybe in some > other thread but was on the TLS list. The update to the > draft hasn't yet happened but will shortly. > > The impact is that our formalities then expect any new TLS > code to include session hash. But that of course does not > affect already deployed code so make of that what you will. The same is true for adding new TLS channel bindings, and adding security considerations text to new SASL/GSS mechanisms about that: existing TLS stacks and applications won't be using the new TLS CB. But fixing TLS stacks to use the session hash can be done in a backwards-compatible way at the API level, and so fixing TLS *is* the right thing to do, and the only thing that will fix existing apps without having to change them. That's why I much prefer focusing on getting the TLS session hash deployed. > Cheers, > S. > > [1] https://www.ietf.org/mail-archive/web/tls/current/msg16231.html My reply is at https://www.ietf.org/mail-archive/web/tls/current/msg16335.html Nico -- From nobody Tue May 26 15:24:25 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB61B323A for ; Tue, 26 May 2015 15:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfGcAQzop6a3 for ; Tue, 26 May 2015 15:24:23 -0700 (PDT) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAD5A1B3221 for ; Tue, 26 May 2015 15:24:22 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo06.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 692f4655.0.4899610.00-2056.13106110.nbfkord-smmo06.seg.att.com (envelope-from ); Tue, 26 May 2015 22:24:22 +0000 (UTC) X-MXL-Hash: 5564f2961f38413f-de34fe8819b7d9374ce746de2f28665ef83b1f9b Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMOLRj013398 for ; Tue, 26 May 2015 18:24:21 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMOG6g013353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 26 May 2015 18:24:18 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Tue, 26 May 2015 22:24:04 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMO4EV021783 for ; Tue, 26 May 2015 18:24:04 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4QMNwhj021526 for ; Tue, 26 May 2015 18:24:00 -0400 Received: from flcdtd01bk9538.itservices.sbc.com (flcdtd01bk9538.itservices.sbc.com?[135.110.240.72](misconfigured sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150526222358gw1000cec7e>; Tue, 26 May 2015 22:23:58 +0000 X-Originating-IP: [135.110.240.72] Message-ID: <5564F27D.70109@att.com> Date: Tue, 26 May 2015 18:23:57 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> In-Reply-To: <20150523162728.5b6b63cd@latte.josefsson.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="euk3u1TEbFRVwKhe8VIQvsjJLw2MmPBvX" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=DLg4FVxb c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=tHvJy1wsfNMA:10 a=Canz06MUmCAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=jwRGozL_] X-AnalysisOut: [yhds8iGoRyoA:9 a=pILNOxqGKmIA:10 a=j4nzMFrpAAAA:8 a=ksZ6Tr] X-AnalysisOut: [X1T2DVG6tTqZUA:9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:24:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --euk3u1TEbFRVwKhe8VIQvsjJLw2MmPBvX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 5/23/15 10:27 AM, Simon Josefsson wrote: > ... > This text has nothing to do with the tls-session-hash issue?=20 Sorry, it has the text I added because of earlier issues brought up within this thread. No, it doesn't address tls-session-hash. > If you don't want to ship a known insecure protocol, I believe the > options are to either include text similar to what I proposed above, > or to replace tls-unique with a secure TLS channel binding (e.g., > draft-josefsson-sasl-tls-cb). Shipping a known insecure protocol is > another option, but then you should add a security consideration > explaining that tls-unique is not secure without tls-session-hash and > that consistency with (the also insecure) RFC 5802 was deemed more > important security. Your suggested text is: "To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel that MUST have [TLS-SESSION-HASH] negotiated." You then go on to say: "Personally, I would prefer to change to another mandatory channel binding that is secure for all TLS versions." Given the other comments in this thread, I'm not sure the suggested text is the right thing to add. Tony Hansen --euk3u1TEbFRVwKhe8VIQvsjJLw2MmPBvX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVZPJ9AAoJEKd93u989/UtOTUQAJwQZRqpuS7IZFqDNbAWzfWP AqV3brH34zwPaPTsrLOzcPkfKuq8szNCDw04her4JJPaUslyCY58od2tBTjvH890 tAhYtvV7lG1Hkq8yj08bMylAlsWaFC+8PCV0OliaSTgKnB7yq/WzzZycDo6+Sf4H oNa85iC6UAOWZoXieV4djfh0YVBOEDqSvAvKCnT9KZV/JXWtBqcogjfHLDAEBZBf Ud8ad+u7jXsw1gPssumUGtGDZhXJPllAo8L2nnTpGJsaVN0ufdJn5RsgFWeHHWDw qpV2YS72nggtixdvIqAN2QTrsm5SmdVdi5Kpg6MN/m4vK5w79TcDboPTcrheUTKG SZeJVym8QAZwccfRflBKgxAZ1REcc+zJonki/8KPY+8GOsfTVca/U70+UyyIbS4m CWK68i5CDmSTZ1oZbIJcxGTjcaQcaEYmk95WPMJFqn8FqlMyL+uQqyVY/1+5bTMm LMrRVIXCsX1TjCDkXQhfzbaYxQYimWRQ51+5G2z+BSiFUNk8R7/3iGFLxOzYbMPV gQLE5p93uo87ngKdpLCUoO764HYxmYWiuIYN/jO3hCb/wNu8E3qS/1Kn9po3Opea av/TQLm94dm2AE6fYMvriSi/tjIF/1YPtb3bC5tNFPhx19g3pt1iqn82IrEjGMxl dCrMzZwzCa69Z+8Dn+Zp =8U/z -----END PGP SIGNATURE----- --euk3u1TEbFRVwKhe8VIQvsjJLw2MmPBvX-- From nobody Tue May 26 15:32:10 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED911B32C2 for ; Tue, 26 May 2015 15:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ACOGlnKdFxZ for ; Tue, 26 May 2015 15:32:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B52171B32B2 for ; Tue, 26 May 2015 15:32:08 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 7BF033B8072; Tue, 26 May 2015 15:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5VzTWIUiT6TELb P7cjs89V6lYJ4=; b=wLjiH5WGrvkLFHongsLB/vCIY4Ev3ZYEpN5Leyye/kUVHv BbdoipYPMDRf6CBO1qDSh/P0W8VGqpQNlSgJnjghVJSgJUoRN8XhbeL/32emDzjM 289VA8S3cz1XJPT6SqOsd1xAxTSST11hEAgb9RwIsv+rmZ1jg2n4XLUacUj1s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 104433B8076; Tue, 26 May 2015 15:32:07 -0700 (PDT) Date: Tue, 26 May 2015 17:32:07 -0500 From: Nico Williams To: Tony Hansen Message-ID: <20150526223206.GE27628@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5564F27D.70109@att.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 22:32:09 -0000 On Tue, May 26, 2015 at 06:23:57PM -0400, Tony Hansen wrote: > On 5/23/15 10:27 AM, Simon Josefsson wrote: > > ... > > This text has nothing to do with the tls-session-hash issue? > > Sorry, it has the text I added because of earlier issues brought up > within this thread. No, it doesn't address tls-session-hash. > > > If you don't want to ship a known insecure protocol, I believe the > > options are to either include text similar to what I proposed above, > > or to replace tls-unique with a secure TLS channel binding (e.g., > > draft-josefsson-sasl-tls-cb). Shipping a known insecure protocol is > > another option, but then you should add a security consideration > > explaining that tls-unique is not secure without tls-session-hash and > > that consistency with (the also insecure) RFC 5802 was deemed more > > important security. > > Your suggested text is: > > "To be secure SCRAM-SHA-256-PLUS has to be used over a TLS channel > that MUST have [TLS-SESSION-HASH] negotiated." That is fine, though I'd add "or session resumption MUST NOT have been used". > You then go on to say: "Personally, I would prefer to change to another > mandatory channel binding that is secure for all TLS versions." This is not really appropriate here because it's the applications that need to do this, and we can't say anything here about this that will force them to. But we can repeat what should be security considerations elsewhere, especially since there's currently no RFC providing this particular security consideration. A reference to TLS-SESSION-HASH of the same level (i.e., normative or informative) as RFCs 5246 and 5929 would be nice. Nico -- From nobody Wed May 27 11:20:27 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EACF41A8A3F for ; Wed, 27 May 2015 11:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHCyuxrHDy2L for ; Wed, 27 May 2015 11:20:23 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3C7F1A8A58 for ; Wed, 27 May 2015 11:18:07 -0700 (PDT) X-AuditID: 12074423-f79536d000000e74-64-55660a5e4186 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id C7.2D.03700.E5A06655; Wed, 27 May 2015 14:18:06 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4RII562014621; Wed, 27 May 2015 14:18:06 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4RII3tb001266 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 May 2015 14:18:05 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4RII3F4015974; Wed, 27 May 2015 14:18:03 -0400 (EDT) Date: Wed, 27 May 2015 14:18:03 -0400 (EDT) From: Benjamin Kaduk To: shawn.emery@oracle.com In-Reply-To: <20150525231428.32727.74087.idtracker@ietfa.amsl.com> Message-ID: References: <20150525231428.32727.74087.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrhvHlRZqcOugrMXRzatYLPpeH2J3 YPJYsuQnk8fHp7dYApiiuGxSUnMyy1KL9O0SuDKe3/jGVHCBreLlPs8GxhcsXYycHBICJhJv J75ggrDFJC7cW8/WxcjFISSwmEmiYclBKGcjo8TU1xvYIZxDTBJtzefZQVqEBBoYJdb0G4PY LALaEuf7F7KB2GwCKhIz32wEs0UEpCTWX34FZjMLCEusPzeDGcQWFnCVuLeyGyzOKeAk8X7z ClYQm1fAUWL7tbdMEPMdJR51fAWzRQV0JFbvn8ICUSMocXLmExaImVoSy6dvY5nAKDgLSWoW ktQCRqZVjLIpuVW6uYmZOcWpybrFyYl5ealFumZ6uZkleqkppZsYwYHqoryD8c9BpUOMAhyM Sjy8B6RTQ4VYE8uKK3MPMUpyMCmJ8v5kSAsV4kvKT6nMSCzOiC8qzUktPsQowcGsJMLr9hGo nDclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgleFE2ioYFFqempFWmZO CUKaiYMTZDgP0HBvkBre4oLE3OLMdIj8KUZdjjtT/i9iEmLJy89LlRLn7QYpEgApyijNg5sD SzCvGMWB3hLmrQep4gEmJ7hJr4CWMAEtMTuaArKkJBEhJdXAeNDwg8SlDdZiTTOmnvbb0HU4 ecXzp6cnXWJ69inAQ4qrJrl/ZVbWyVa+9j8GpoJbnz7YOeeR1N7zl8UOfP7R1jZp5+rcqicz jaZ9YjbI6XltUJJQOX3x8Uxfo603o9Tb0/mmHz0n7S7+zl336m/2Zzc6xW+d/jI75n16FBf7 9mfGoVtV7q2wSlViKc5INNRiLipOBAD+93MdCwMAAA== Archived-At: Cc: kitten@ietf.org Subject: Re: [kitten] I-D Action: draft-ietf-kitten-rfc4402bis-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 18:20:25 -0000 On Mon, 25 May 2015, 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 Common Authentication Technology Next Generation Working Group of the IETF. > > Title : A Pseudo-Random Function (PRF) for the Kerberos V Generic Security Service Application Program Interface (GSS-API) Mechanism > Authors : Shawn Emery > Cryptonector, LLC > Filename : draft-ietf-kitten-rfc4402bis-01.txt > Pages : 7 > Date : 2015-04-06 Thanks for these updates, Shawn. I believe that they reflect the changes discussed during the WGLC, and represent the WG consensus. As such, the chairs should go ahead and shepherd this document forward to the IESG. -Ben From nobody Wed May 27 14:20:39 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEF21AC3E9; Wed, 27 May 2015 14:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id guQgonG7VoDC; Wed, 27 May 2015 14:19:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD6A61A90B6; Wed, 27 May 2015 14:19:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150527211918.9536.15611.idtracker@ietfa.amsl.com> Date: Wed, 27 May 2015 14:19:18 -0700 Archived-At: X-Mailman-Approved-At: Wed, 27 May 2015 14:20:28 -0700 Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org Subject: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 21:19:21 -0000 Ben Campbell has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- section 1, description of step A: if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place? -- 1, 2nd to last paragraph The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative. -- 3: "Such a new SASL OAuth mechanism can be added by simply registering the new name(s)" Register them where? -- 3.2, 2nd paragraph : "... known to the application." Known to the "resource server"? Editorial Stuff: -- 3.1, "Port": I assume that means the destination port to which the client connected? (similar to Host?) -- 3.1.1 "Post": default value is "". Does "" represent an empty string? -- 3.2, first sentence" s/" ... according the specification..." / "... according to the specification..." - 5: "Lifetime of the appliation sessions" s/appliation/application "It is possible that SASL will be authenticating..." s/"... be authenticating..." / "... be used to authenticate..." From nobody Wed May 27 15:52:11 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 308D51B2A91 for ; Wed, 27 May 2015 15:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5HSTRc1sBlmf for ; Wed, 27 May 2015 15:52:07 -0700 (PDT) Received: from nm44-vm2.bullet.mail.gq1.yahoo.com (nm44-vm2.bullet.mail.gq1.yahoo.com [67.195.87.25]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 514411B2A97 for ; Wed, 27 May 2015 15:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432767126; bh=U1NBrOapMk+3aA/E65oepdS5jz0QS0FVeYzb84Z/lfk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=cZDj3VSDRr03NtapmhemHXHyCFrCZLofki8lvGfCqTcvlitFhlwfXrclp4CWnZo73IiL/U36JzDlQV3Z3DR6CORH1fZz5B/BichcM7Dw0XhBWvLKee4HVFJBvjJaq4IAWDCYPDC7G42obz9z7R8NcRiSPuEhuCxyOIN9a4JJpqzlLEzgrW2ubxoHn12Ll9Wz2iMiD0YNre2NJOLRTnlKK1YvAbdXn0WDViAx1+b+G4wU3kvZEHpdWLR+GSILMqFU/QhrKO7t8ABKo4AqKcBsaH9RuHJRySxQfjLAcPT4MYqI6JzeKvUWHD2MjCD1AaByDuLythzGfTkvyeHIh50g6Q== Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:52:06 -0000 Received: from [98.137.12.62] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000 Received: from [98.139.170.179] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000 Received: from [98.139.212.219] by tm22.bullet.mail.bf1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000 Received: from [127.0.0.1] by omp1028.mail.bf1.yahoo.com with NNFMP; 27 May 2015 22:49:05 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 67432.5896.bm@omp1028.mail.bf1.yahoo.com X-YMail-OSG: nIQv4OkVRDuCKSnbc1dMqpCNA81yDMFbDujdvQ0rZRMCcEVqYA-- Received: by 66.196.81.105; Wed, 27 May 2015 22:49:04 +0000 Date: Wed, 27 May 2015 22:49:03 +0000 (UTC) From: Bill Mills To: Ben Campbell , The IESG Message-ID: <1717038366.5795.1432766943755.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150527211918.9536.15611.idtracker@ietfa.amsl.com> References: <20150527211918.9536.15611.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5794_1598924530.1432766943740" Archived-At: Cc: "kitten@ietf.org" , "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2015 22:52:09 -0000 ------=_Part_5794_1598924530.1432766943740 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the good feedback. =C2=A0My replies inline below, and this will = be checked in to my working copy on GitHub at https://github.com/sweetums/i= drafts 2+ possible follow-ons/questions. Regards, -bill > ----------------------------------------------------------------------> C= OMMENT:> ------------------------------------------------------------------= ---->=C2=A0> -- section 1, description of step A:>=C2=A0> if the preferred = way is different than the diagram, why not show it the preferred way in the= diagram in the first place?>=C2=A0 Struck "preferrably". =C2=A0This was based in the desire to prefer web base= d flows over the password grant type, but in the end both are valid and we'= re putting no normative language around it. > -- 1, 2nd to last paragraph>=C2=A0> The "SHOULD" means the reference to I= -D.ietf-oauth-dyn-reg needs to be be normative. done >=C2=A0> -- 3: "Such a new SASL OAuth mechanism can be added by simply> =C2= =A0 =C2=A0registering the new name(s)">=C2=A0> Register them where? s/by simply registering the new name(s)/by registering the new name(s) with= IANA/ change made in my working copy. >=C2=A0> -- 3.2, 2nd paragraph : "... known to the application.">=C2=A0> Kn= own to the "resource server"? this is server config and in protocol data that the app could have, so I'd = rather leave this as "application" but if there's strong desire for "resour= ce server" I'll make the change. >=C2=A0> Editorial Stuff:>=C2=A0> -- 3.1, "Port":>=C2=A0> I assume that mea= ns the destination port to which the client connected?> (similar to Host?)>= =C2=A0> -- 3.1.1 "Post": default value is "".=C2=A0>=C2=A0> Does "" represe= nt an empty string? Yes, does this need to be spelled out? >=C2=A0> -- 3.2, first sentence">=C2=A0> s/" ... according the specificatio= n..." / "... according to the specification..." done >=C2=A0> - 5: "Lifetime of the appliation sessions">=C2=A0> s/appliation/ap= plication done >=C2=A0> "It is possible that SASL will be authenticating...">=C2=A0> s/"..= . be authenticating..." / "... be used to authenticate...">=C2=A0 Done. >=C2=A0>=C2=A0=20 On Wednesday, May 27, 2015 2:59 PM, Ben Campbell wro= te: =20 Ben Campbell has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -- section 1, description of step A: if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place? -- 1, 2nd to last paragraph The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative. -- 3: "Such a new SASL OAuth mechanism can be added by simply =C2=A0 registering the new name(s)" Register them where? -- 3.2, 2nd paragraph : "... known to the application." Known to the "resource server"? Editorial Stuff: -- 3.1, "Port": I assume that means the destination port to which the client connected? (similar to Host?) -- 3.1.1 "Post": default value is "".=20 Does "" represent an empty string? -- 3.2, first sentence" s/" ... according the specification..." / "... according to the specification..." - 5: "Lifetime of the appliation sessions" s/appliation/application "It is possible that SASL will be authenticating..." s/"... be authenticating..." / "... be used to authenticate..." _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_5794_1598924530.1432766943740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the good fe= edback.  My replies inline below, and this will be checked in to my wo= rking copy on GitHub at https://github.com/sweetums/idrafts
2+ possible follow-ons/questions.

Regards,

-bill

> ----------------= ------------------------------------------------------
> COMME= NT:
> --------------------------------------------------------= --------------
> 
> -- section 1, descripti= on of step A:
> 
> if the preferred way is= different than the diagram, why not show it the preferred way in the diagr= am in the first place?
> 

Struck "preferrably".  This was based in the desire to prefer= web based flows over the password grant type, but in the end both are vali= d and we're putting no normative language around it.


> -- 1, 2nd to last paragraph
> 
>= ; The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be= normative.

done

> 
> -- 3: "Such a new SASL OAuth mechanism can be added by simply
<= div dir=3D"ltr" class=3D"" style=3D"">>    registering the new= name(s)"
> 
> Register them where?

s/by simply registering the new name(s)/by regis= tering the new name(s) with IANA/

c= hange made in my working copy.
=
>=  
> -- 3.2, 2nd paragraph : "... known to the application= ."
> 
> Kn= own to the "resource server"?
<= br class=3D"" style=3D"">
this = is server config and in protocol data that the app could have, so I'd rathe= r leave this as "application" but if there's strong desire for "resource se= rver" I'll make the change.
> 
> Editorial Stuff:
> 
> -- 3.1, "Port":
> 
<= div dir=3D"ltr" class=3D"" style=3D"">> I assume that means the destinat= ion port to which the client connected?
> (similar to Host?)
> 
> -- 3.1= .1 "Post": default value is "". 
> 
> Does "" = represent an empty string?

Yes, doe= s this need to be spelled out?
=
>=  
> -- 3.2, first sente= nce"
> 
> s/" ... according the specificatio= n..." / "... according to the specification..."

done

> 
<= div dir=3D"ltr" class=3D"" style=3D"" id=3D"yui_3_16_0_1_1432680216536_1305= 37">> - 5: "Lifetime of the appliation sessions"
> 
> s/appliation/application
=
done=

> 
> "It is possible that SASL will be authenticating.= .."
> 
> s/"... be authenticating..." / "... be use= d to authenticate..."
> = ;

Done.

> 
> <= /div>




On Wednesday, May 27, 2015 = 2:59 PM, Ben Campbell <ben@nostrum.com> wrote:

Ben Campbell has entered the followin= g ballot position for
draft-ietf-kitten-sasl-oauth-22: No Objection
<= br>When responding, please keep the subject line intact and reply to allemail addresses included in the To and CC lines. (Feel free to cut thisintroductory paragraph, however.)


Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html
for more i= nformation about IESG DISCUSS and COMMENT positions.


The documen= t, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/


-----------------------------------------------------------------= -----
COMMENT:
------------------------------------------------------= ----------------

-- section 1, description of step A:

if the = preferred way is different than the diagram, why not show it the
preferr= ed way in the diagram in the first place?

-- 1, 2nd to last paragrap= h

The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs t= o be be
normative.

-- 3: "Such a new SASL OAuth mechanism can be = added by simply
  registering the new name(s)"

Register the= m where?

-- 3.2, 2nd paragraph : "... known to the application."
=
Known to the "resource server"?

Editorial Stuff:

-- 3.1, = "Port":

I assume that means the destination port to which the client= connected?
(similar to Host?)

-- 3.1.1 "Post": default value is = "".

Does "" represent an empty string?

-- 3.2, first sentenc= e"

s/" ... according the specification..." / "... according to thespecification..."

- 5: "Lifetime of the appliation sessions"
s/appliation/application

"It is possible that SASL will be authent= icating..."

s/"... be authenticating..." / "... be used to authentic= ate..."


_______________________________________________
Kitte= n mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/k= itten


------=_Part_5794_1598924530.1432766943740-- From nobody Wed May 27 20:20:48 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D80CA1A1AB5; Wed, 27 May 2015 20:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaH8ydCAo7TK; Wed, 27 May 2015 20:20:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82E871A1A87; Wed, 27 May 2015 20:20:39 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4S3KSAH078375 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 22:20:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Bill Mills" Date: Wed, 27 May 2015 22:20:28 -0500 Message-ID: <7F67E244-0ED2-473E-9E5A-B8E2B382563B@nostrum.com> In-Reply-To: <1717038366.5795.1432766943755.JavaMail.yahoo@mail.yahoo.com> References: <20150527211918.9536.15611.idtracker@ietfa.amsl.com> <1717038366.5795.1432766943755.JavaMail.yahoo@mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 03:20:43 -0000 Hi, thanks for the response. A few comments below. I removed sections that do not seem to need further discussion. On 27 May 2015, at 17:49, Bill Mills wrote: [...] >>  > -- 3: "Such a new SASL OAuth mechanism can be added by simply>   >>  registering the new name(s)"> > Register them where? > s/by simply registering the new name(s)/by registering the new name(s) > with IANA/ > change made in my working copy. Sorry, I guess I was asking for which registry at IANA. >>  > -- 3.2, 2nd paragraph : "... known to the application."> > Known >> to the "resource server"? > this is server config and in protocol data that the app could have, so > I'd rather leave this as "application" but if there's strong desire > for "resource server" I'll make the change. Do I understand correctly that we are talking about matching things like host and port sent by the client to things the server "knows" through other channels? It seems like "application" could mean application at the client as well as the server, or even the combination of both. Maybe "application server"? (Or maybe I've missed the intent?) >>  > Editorial Stuff:> > -- 3.1, "Port":> > I assume that means the >> destination port to which the client connected?> (similar to >> Host?)> > -- 3.1.1 "Post": default value is "". > > Does "" >> represent an empty string? > Yes, does this need to be spelled out? "Need" might be too strong a word, but I think a description like "empty" would be more clear than '""'. >>  > -- 3.2, first sentence"> > s/" ... according the >> specification..." / "... according to the specification..." [...] From nobody Wed May 27 20:56:31 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864961A1B8F; Wed, 27 May 2015 20:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyKGmJxwZsYe; Wed, 27 May 2015 20:56:24 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7EB1A1A72; Wed, 27 May 2015 20:56:24 -0700 (PDT) X-AuditID: 12074424-f79b06d000000cfd-40-556691e68254 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id FD.F4.03325.7E196655; Wed, 27 May 2015 23:56:23 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t4S3uLO1021100; Wed, 27 May 2015 23:56:22 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4S3uHCH002849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 27 May 2015 23:56:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4S3uGVo028803; Wed, 27 May 2015 23:56:16 -0400 (EDT) Date: Wed, 27 May 2015 23:56:16 -0400 (EDT) From: Benjamin Kaduk To: Ben Campbell In-Reply-To: <7F67E244-0ED2-473E-9E5A-B8E2B382563B@nostrum.com> Message-ID: References: <20150527211918.9536.15611.idtracker@ietfa.amsl.com> <1717038366.5795.1432766943755.JavaMail.yahoo@mail.yahoo.com> <7F67E244-0ED2-473E-9E5A-B8E2B382563B@nostrum.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-402023201-1432785376=:22210" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFKsWRmVeSWpSXmKPExsUixCmqrft8YlqowZ757BbzO0+zW/w98pvZ 4uGMg4wW0x98YbKY8Wcis8W13ftZLY5uXsVi8a3rOrMDh8eSJT+ZPGbtfMLiMWvWYaYA5igu m5TUnMyy1CJ9uwSujH1TVzEWfBapmPD0CFsD42WBLkZODgkBE4l5j7axQNhiEhfurWfrYuTi EBJYzCRx4sx2FghnI6PEjtnLWCGcQ0wSmx9NZYRwGhglPl5dywjSzyKgLXH50hw2EJtNQEVi 5puNYLaIgJLE8+atYKOYBS4yS2zZuQXI4eAQFkiTaHuQBlLDKWAv8fh7MzuIzSvgKPH/SgMr 3Oq3nTdZQRKiAjoSq/dPYYEoEpQ4OfMJmM0sECAxa+1R1gmMgrOQpGYhSUHY6hKND86yQdja EvdvtrEtYGRZxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERQl7C4qOxibDykd YhTgYFTi4X0hnxYqxJpYVlyZe4hRkoNJSZTXrg8oxJeUn1KZkVicEV9UmpNafIhRgoNZSYT3 iydQjjclsbIqtSgfJiXNwaIkzrvpB1+IkEB6YklqdmpqQWoRTFaGg0NJgtdqAlCjYFFqempF WmZOCUKaiYMTZDgP0PA2kBre4oLE3OLMdIj8KUZFKXHeRJCEAEgiozQPrheWxF4xigO9Isyb DVLFA0yAcN2vgAYzAQ02O5oCMrgkESEl1cAYF/ni4ZYXMmr3bTsPHZqj9IZzu9IyJ/6n/1lX p8X373o2WXvSq98nnhlEqAhtPNl0Rp7X6+PHiPC9W75rzLMXYpfpjdH0vpl72rNeZvGrRy6T lJc1R31i4tG/tzx03+cHDZlHpLefFJr69Mr8zzU72g9nF7JXrTyY0cjxuELLqGvTlSOcPSc5 lViKMxINtZiLihMBk3LUnT0DAAA= Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 03:56:26 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-402023201-1432785376=:22210 Content-Type: TEXT/PLAIN; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Hi Ben, On Wed, 27 May 2015, Ben Campbell wrote: > Hi, thanks for the response. A few comments below. I removed sections tha= t do > not seem to need further discussion. > > On 27 May 2015, at 17:49, Bill Mills wrote: > > [...] > > > > =C2=A0> -- 3: "Such a new SASL OAuth mechanism can be added by simply= > =C2=A0 > > > =C2=A0registering the new name(s)">=C2=A0> Register them where? > > s/by simply registering the new name(s)/by registering the new name(s) = with > > IANA/ > > change made in my working copy. > > Sorry, I guess I was asking for which registry at IANA. The SASL Mechanisms registry; the only one affected by this document. > > > =C2=A0> -- 3.2, 2nd paragraph : "... known to the application.">=C2= =A0> Known to the > > > "resource server"? > > this is server config and in protocol data that the app could have, so = I'd > > rather leave this as "application" but if there's strong desire for > > "resource server" I'll make the change. > > Do I understand correctly that we are talking about matching things like = host > and port sent by the client to things the server "knows" through other > channels? It seems like "application" could mean application at the clie= nt as > well as the server, or even the combination of both. Maybe "application > server"? (Or maybe I've missed the intent?) Things like host and port that could be extracted from the OS or http stack or similar, yes. I don't particularly care for "resource server" here, but "application server" seems unobjectionable. > > > =C2=A0> Editorial Stuff:>=C2=A0> -- 3.1, "Port":>=C2=A0> I assume tha= t means the > > > destination port to which the client connected?> (similar to Host?)>= =C2=A0> -- > > > 3.1.1 "Post": default value is "".=C2=A0>=C2=A0> Does "" represent an= empty string? > > Yes, does this need to be spelled out? > > "Need" might be too strong a word, but I think a description like "empty" > would be more clear than '""'. I agree that it's probably worth doing "destination port to which the client connected". I have no strong feelings regarding the way in which the empty string is described. > > > =C2=A0> -- 3.2, first sentence">=C2=A0> s/" ... according the specifi= cation..." / > > > "... according to the specification..." > > [...] Indeed. -Ben ---559023410-402023201-1432785376=:22210-- From nobody Thu May 28 08:11:45 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D871AD352 for ; Thu, 28 May 2015 08:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfo13fTUTvMA for ; Thu, 28 May 2015 08:11:40 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AF51AD0B3 for ; Thu, 28 May 2015 08:11:39 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4SFBO2k003893 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 28 May 2015 17:11:25 +0200 Date: Thu, 28 May 2015 17:11:22 +0200 From: Simon Josefsson To: Nico Williams Message-ID: <20150528171122.2bceebb6@latte.josefsson.org> In-Reply-To: <20150526223206.GE27628@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/foslGX3Kg4n1v6H.vzZQ+m6"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:11:41 -0000 --Sig_/foslGX3Kg4n1v6H.vzZQ+m6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > > You then go on to say: "Personally, I would prefer to change to > > another mandatory channel binding that is secure for all TLS > > versions." >=20 > This is not really appropriate here because it's the applications that > need to do this, and we can't say anything here about this that will > force them to. > A reference to TLS-SESSION-HASH of the same level (i.e., normative > or informative) as RFCs 5246 and 5929 would be nice. I believe that what is required is 1) scram-sha256 has a normative reference to tls-session-hash; or 2) tls-session-hash uses an Update: that makes it applicapable to all TLS versions, and that it is clarified (if not already the case) that tls-session-hash must be used; or 3) scram-sha256 uses a new channel binding that is secure with or without tls-session-hash. I believe 1) and 2) would be worse than 3) for the next ~5 years or so, and things being equal after that. SASL libraries/applications rarely have any influence over TLS internals, but they directly influence the channel binding used. Using another channel binding for hansen-scram-sha256 should not be difficult, as far as I can tell -- SCRAM implementations needs to be changed to support the other stuff for SCRAM-SHA256 so they could just as well be modified to support a new channel binding too. But I would not object to 1) or 2), if people prefer that. /Simon --Sig_/foslGX3Kg4n1v6H.vzZQ+m6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZzAaAAoJEIYLf7sy+BGd2E4IAIZazBKd8Lxz6R/hZ57METHh /MmRoZMm8s90XGeytI7RsfaLFSBw69SOeeM73KkDm5a+nJ5lYLC5NMNKYWUIRTq+ NIt6x6arCQS6nCS//dRo2F4a+DovFfIh3WgNxKREiplrFV69TYVeTIazhyUSbbNZ JdDJNzCCmojyIUD+eoerjPMkCxHhbhER8AYkGYfmEplnoTB8Dd8IuqxMArnHFMr5 biKWZh12a2aDKWe8OFGBfGdPIZ6xw+iypxDJTQEjbqnQEayiI0y9a8y/tI557A/U rphnWeU0wLNv0uVN8w1TknespAWcoDnpc6Z+G4/GvMwATU8xS7zv4DBWYQYGChk= =K3eH -----END PGP SIGNATURE----- --Sig_/foslGX3Kg4n1v6H.vzZQ+m6-- From nobody Thu May 28 08:26:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8EE71B2B80 for ; Thu, 28 May 2015 08:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE2QK-u5LhlI for ; Thu, 28 May 2015 08:26:29 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D361B2B4B for ; Thu, 28 May 2015 08:26:29 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id 2a337655.0.6038705.00-2307.16356702.nbfkord-smmo05.seg.att.com (envelope-from ); Thu, 28 May 2015 15:26:29 +0000 (UTC) X-MXL-Hash: 556733a50b37e4f1-f1e7965acb2dc6cb3fd55f88b77298fd70d18e1e Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFQPEo000788 for ; Thu, 28 May 2015 11:26:26 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFQNGR000761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 May 2015 11:26:24 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi131.aldc.att.com (RSA Interceptor) for ; Thu, 28 May 2015 15:26:03 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFQ3nj006469 for ; Thu, 28 May 2015 11:26:03 -0400 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SFPxli006195 for ; Thu, 28 May 2015 11:25:59 -0400 Received: from tonys-macbook-pro.local (unknown[135.110.241.230](untrusted sender)) by maillennium.att.com (mailgw1) with ESMTP id <20150528152558gw1000cecqe>; Thu, 28 May 2015 15:25:59 +0000 X-Originating-IP: [135.110.241.230] Message-ID: <55673385.6080006@att.com> Date: Thu, 28 May 2015 11:25:57 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> In-Reply-To: <20150528171122.2bceebb6@latte.josefsson.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=b/AFFK6x c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=tHvJy1wsfNMA:10 a=grKcJhx5cuYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=N659UExz7-8A:10 a=zQP7CpKOAAAA:8 a=h1Pgugrv] X-AnalysisOut: [aO0A:10 a=31Yo1cYTXzT7QG4VKnkA:9 a=pILNOxqGKmIA:10] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 15:26:32 -0000 On 5/28/15 11:11 AM, Simon Josefsson wrote: >>> You then go on to say: "Personally, I would prefer to change to >>> another mandatory channel binding that is secure for all TLS >>> versions." >> This is not really appropriate here because it's the applications that >> need to do this, and we can't say anything here about this that will >> force them to. >> A reference to TLS-SESSION-HASH of the same level (i.e., normative >> or informative) as RFCs 5246 and 5929 would be nice. > I believe that what is required is > > 1) scram-sha256 has a normative reference to tls-session-hash; or > > 2) tls-session-hash uses an Update: that makes it applicapable to all > TLS versions, and that it is clarified (if not already the case) that > tls-session-hash must be used; or > > 3) scram-sha256 uses a new channel binding that is secure with or > without tls-session-hash. > > I believe 1) and 2) would be worse than 3) for the next ~5 years or > so, and things being equal after that. SASL libraries/applications > rarely have any influence over TLS internals, but they directly > influence the channel binding used. Using another channel binding for > hansen-scram-sha256 should not be difficult, as far as I can tell -- > SCRAM implementations needs to be changed to support the other stuff > for SCRAM-SHA256 so they could just as well be modified to support a > new channel binding too. But I would not object to 1) or 2), if people > prefer that. Simon, right now scram-sha256 does not change anything in the SCRAM base spec other than setting the hash mechanism to SHA256. I *think* what you are asking for would actually be a change to the SCRAM base spec, which so far has been out of scope for this document. Tony Hansen From nobody Thu May 28 09:40:33 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD1291B2C5E for ; Thu, 28 May 2015 09:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MHuP9deEKg6 for ; Thu, 28 May 2015 09:40:24 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B9C7E1B2C62 for ; Thu, 28 May 2015 09:40:05 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 5B73B594084; Thu, 28 May 2015 09:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=n8IjU7eejr6/aB EPBcIT9Zk784g=; b=cqlTrkp+X9P/li2JSgPp40yLk275/7UvC0ZtrgFDZCeu/A s2znHGD1l5pvvfKYtpGyECjyeYKV5QxRrjvn5tw6ESTur7N/NN9b3OwDp9VXCBPm f+jGSL0OKipr0GKkxRqO1/0gHf+py2PVxayhimKwaGb8gJD+tC2Vjhq7YiUJs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id E202D59407D; Thu, 28 May 2015 09:40:03 -0700 (PDT) Date: Thu, 28 May 2015 11:40:02 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150528164000.GF1733@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150528171122.2bceebb6@latte.josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 16:40:25 -0000 On Thu, May 28, 2015 at 05:11:22PM +0200, Simon Josefsson wrote: > > > You then go on to say: "Personally, I would prefer to change to > > > another mandatory channel binding that is secure for all TLS > > > versions." > > > > This is not really appropriate here because it's the applications that > > need to do this, and we can't say anything here about this that will > > force them to. > > > A reference to TLS-SESSION-HASH of the same level (i.e., normative > > or informative) as RFCs 5246 and 5929 would be nice. > > I believe that what is required is > > 1) scram-sha256 has a normative reference to tls-session-hash; or > > 2) tls-session-hash uses an Update: that makes it applicapable to all > TLS versions, and that it is clarified (if not already the case) that > tls-session-hash must be used; or And RFC5929. My vote is for (2). I don't mind (1) in addition, but I want (2). > 3) scram-sha256 uses a new channel binding that is secure with or > without tls-session-hash. We disagree as to (3). This is advice we can give to apps in the security considerations section, not something we can force a SASL or GSS mechanism to do because API-wise the mechanism doesn't get a choice. > I believe 1) and 2) would be worse than 3) for the next ~5 years or > so, and things being equal after that. SASL libraries/applications > rarely have any influence over TLS internals, but they directly > influence the channel binding used. Using another channel binding for > [...] No, they don't. Certainly not GSS ones, and the SASL implementations I'm familiar with don't either. E.g., GSS_Init_sec_context() doesn't get a handle to a channel to bind to, it only gets the channel binding as already extracted by the app. Worse, GSS_Init_sec_context() doesn't even get the channel binding type. (3) is unworkable. Nico -- From nobody Thu May 28 11:23:24 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E54641A006D for ; Thu, 28 May 2015 11:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.175 X-Spam-Level: X-Spam-Status: No, score=-1.175 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZR3_yIaZgVnF for ; Thu, 28 May 2015 11:23:21 -0700 (PDT) Received: from nm44-vm9.bullet.mail.gq1.yahoo.com (nm44-vm9.bullet.mail.gq1.yahoo.com [67.195.87.214]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D72851A011B for ; Thu, 28 May 2015 11:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432837398; bh=BFNQhKv8+I8xcQfdm5Ip8hA4Lh+cuCA95shdVTY0yLA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=khBIGzUwRKeuy/mv0Kow0pPX7BTIDDieEJHfZD7ru0B9HBBx++hgNpOM2T+DvaRoCgQPefT2HbLAJA7nqMalRzrGJwCAa4cD7WePdCiyleCmLCXf1ejXsW3oZ53r9nd5MiikFSYL/s8y63/F4gHuDub4vfs95F/oFkMEMPiFUGkCYpBWcT7zC7FzP73wKyEbCcs08Pwg1bPLCwdmPa3MtrLhzjp6hfaRqnzm0scCJrCaYGSE2X0sxBc1RHhNTXN4uYjk1VAx2NCjj7BFykqHLC9mPkkgJ8rqS1eLT3ZT4rD/RcJ3q4wit7i27MAm+BDvasG7tBcaiI7dqxy+JxuxZQ== Received: from [127.0.0.1] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:23:18 -0000 Received: from [98.137.12.191] by nm44.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:20:27 -0000 Received: from [66.196.81.173] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:20:27 -0000 Received: from [98.139.212.240] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2015 18:20:27 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 28 May 2015 18:20:27 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 461654.79261.bm@omp1049.mail.bf1.yahoo.com X-YMail-OSG: VpggOq8VM1mHQ4nksq1Ev56RmKE5f._gnNhlyQWTMmHug5zlDndwCCpbCO.lniS xX8b_R.nyS6m96FzcxXwj.HvljjiILz.kJbYeY5S4JmEZdJH_mFLnidR1wPb5XyjicL2zYuzj_Gp FI_0J9QjhL0RAKQJLcEdsCTSEh_pC165.hns7rxi4NJG4RNXExpAZkCz4cVpF9hugzO1e8ikToew eeSs4mMT9O7LYtAdPycHm8qj.EA7azNPIedgy_POmEPWxJQ3bKnEHziHf4THe7SPccNrCxTKn.iK mlfnqPTt3fbRx479UNFkdaHJyWDxzRcVGpnur0Nf88k_fW5a6.nE8jRNGAULKh6_OUYj395ep5K4 0vjzqwRVuGr28lpl1M.xAZfv4meTR65W6VfQjghrWpzI0JHchR0vG5ZXyGM2GFNopOzGCLzrgpYC lh7xebB.E7LC6qiB8RdyB1TURw6kjz91RkNzlXfCV9QRvbegod67e1yavAUfd8cePfTwTcPkSeO_ OtzKOSrqKmUI1OWdN Received: by 66.196.80.120; Thu, 28 May 2015 18:20:27 +0000 Date: Thu, 28 May 2015 18:17:37 +0000 (UTC) From: Bill Mills To: Benjamin Kaduk , Ben Campbell Message-ID: <1076402811.687497.1432837057605.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_687496_66331018.1432837057601" Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:23:23 -0000 ------=_Part_687496_66331018.1432837057601 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responses inline below tagged with [[WMILLS]] On Wednesday, May 27, 2015 8:56 PM, Benjamin Kaduk wro= te: =20 Hi Ben, On Wed, 27 May 2015, Ben Campbell wrote: > Hi, thanks for the response. A few comments below. I removed sections tha= t do > not seem to need further discussion. > > On 27 May 2015, at 17:49, Bill Mills wrote: > > [...] > > > > =C2=A0> -- 3: "Such a new SASL OAuth mechanism can be added by simply= > =C2=A0 > > > =C2=A0registering the new name(s)">=C2=A0> Register them where? > > s/by simply registering the new name(s)/by registering the new name(s) = with > > IANA/ > > change made in my working copy. > > Sorry, I guess I was asking for which registry at IANA. The SASL Mechanisms registry; the only one affected by this document. [[WMILLS]] changed wording to "registering the new name(s) with IANA in the= SASL Mechanisms registry" > > > =C2=A0> -- 3.2, 2nd paragraph : "... known to the application.">=C2= =A0> Known to the > > > "resource server"? > > this is server config and in protocol data that the app could have, so = I'd > > rather leave this as "application" but if there's strong desire for > > "resource server" I'll make the change. > > Do I understand correctly that we are talking about matching things like = host > and port sent by the client to things the server "knows" through other > channels?=C2=A0 It seems like "application" could mean application at the= client as > well as the server, or even the combination of both. Maybe "application > server"? (Or maybe I've missed the intent?) Things like host and port that could be extracted from the OS or http stack or similar, yes.=C2=A0 I don't particularly care for "resource server= " here, but "application server" seems unobjectionable. [[wmills]] WFM "application server" it is. > > > =C2=A0> Editorial Stuff:>=C2=A0> -- 3.1, "Port":>=C2=A0> I assume tha= t means the > > > destination port to which the client connected?> (similar to Host?)>= =C2=A0> -- > > > 3.1.1 "Post": default value is "".=C2=A0>=C2=A0> Does "" represent an= empty string? > > Yes, does this need to be spelled out? > > "Need" might be too strong a word, but I think a description like "empty" > would be more clear than '""'. [[WMILLS]] changed those to "the default value is the empty string ("")." I agree that it's probably worth doing "destination port to which the client connected".=C2=A0 I have no strong feelings regarding the way in whi= ch the empty string is described. [[WMILLS]] WFM now "Contains the destination port that the client connected= to, represented as a=C2=A0 decimal positive integer string without leading= zeros." > > > =C2=A0> -- 3.2, first sentence">=C2=A0> s/" ... according the specifi= cation..." / > > > "... according to the specification..." > > [...] Indeed. -Ben =C2=A0 ------=_Part_687496_66331018.1432837057601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responses inline below tagged with = [[WMILLS]]


On Wednesday, May 27, 2015 8:56 PM, Benjamin Kaduk <kaduk@MIT.EDU> = wrote:


Hi Ben,

On Wed, 27 May 2015, Ben Campbell wrote:

> Hi, thanks for the response. A few comments below. I removed sect= ions that do
> not seem to need further discussion.>
> On 27 May 2015, at 17:49, Bill = Mills wrote:
>
> [...]
>
> > >  > -- 3: "Such a ne= w SASL OAuth mechanism can be added by simply>  
= > > >  registering the new name(s)"> > Register th= em where?
> > s/by simply registering the new name(= s)/by registering the new name(s) with
> > IANA/> > change made in my working copy.
>
> Sorry, I guess I was asking for which registry= at IANA.

The SASL Mechanisms registry= ; the only one affected by this document.

[[WMILLS]] cha= nged wording to "registering the new name(s) with IANA in the SASL Mechanis= ms registry"

> > >  >= -- 3.2, 2nd paragraph : "... known to the application."> > Know= n to the
> > > "resource server"?
> > this is server config and in protocol data that the app could= have, so I'd
> > rather leave this as "application= " but if there's strong desire for
> > "resource se= rver" I'll make the change.
>
> D= o I understand correctly that we are talking about matching things like hos= t
> and port sent by the client to things the server "= knows" through other
> channels?  It seems like "= application" could mean application at the client as
>= well as the server, or even the combination of both. Maybe "application> server"? (Or maybe I've missed the intent?)

Things like host and port that could be extrac= ted from the OS or http
stack or similar, yes.  I do= n't particularly care for "resource server"
here, but "ap= plication server" seems unobjectionable.

[[wmills]] W= FM "application server" it is.

> > >  &= gt; Editorial Stuff:> > -- 3.1, "Port":> > I assume t= hat means the
> > > destination port to which th= e client connected?> (similar to Host?)> > --
> > > 3.1.1 "Post": default value is "". > > Do= es "" represent an empty string?
> > Yes, does this= need to be spelled out?
>
> "Nee= d" might be too strong a word, but I think a description like "empty"
> would be more clear than '""'.

[[WM= ILLS]] changed those to "the default value is the empty string ("")."
I agree that it's probably worth doing "destination port t= o which the
client connected".  I have no strong fee= lings regarding the way in which
the empty string is desc= ribed.

[[WMILLS]] WFM now "Contains the destination port that the client= connected to, represented as a =09=09=09decimal positive integer string without leading zero= s."


> > > &nb= sp;> -- 3.2, first sentence"> > s/" ... according the specifi= cation..." /
> > > "... according to the specifi= cation..."

>
> [...]

Indeed.

-Ben

 
------=_Part_687496_66331018.1432837057601-- From nobody Thu May 28 11:27:22 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE8E1A00F5; Thu, 28 May 2015 11:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14x6Lh-VTgtu; Thu, 28 May 2015 11:27:16 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C1A21A009E; Thu, 28 May 2015 11:27:16 -0700 (PDT) Received: by iesa3 with SMTP id a3so45211292ies.2; Thu, 28 May 2015 11:27:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=6niOMkI/vQiff7iZ27HhlqQacNTy6HymYy9LwzuOZzE=; b=EQEYVrh9PiLa3XNPy8a2gkvcWeW0DQal3dY+Ltw8rJqlDIFh5dKmnmqGpvfkWRONNK 00aNuyVdxgCXH7hgbucLKF52r0IfAjByi8gBujkID8bzivkGijoAovJGKM+u3/smO6rv ElG1zWe0lok5Y+RHpM36yy1O4kNVIt1gCnAomOQucpR/n0bwZ7D2m/0zngClorzNnEtX WEDuoNA8UQ5agj/jutgO58l9ks2p/WaSIF3olhH8VSzR0KRBszYKgTc/NnpQQe1nav5K tQ/mUQxwbqd/Hvmf2JhiXojTRQEmbFr29KI0+d/iLbGceZw9lFNgQRbiIKHzRS+x+Z2d zZxg== MIME-Version: 1.0 X-Received: by 10.43.171.202 with SMTP id nv10mr10894459icc.30.1432837635877; Thu, 28 May 2015 11:27:15 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 11:27:15 -0700 (PDT) In-Reply-To: <513132564.2389503.1432673344504.JavaMail.yahoo@mail.yahoo.com> References: <20150526155734.22570.6165.idtracker@ietfa.amsl.com> <513132564.2389503.1432673344504.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 28 May 2015 14:27:15 -0400 X-Google-Sender-Auth: tXRy8kZSV2mbZnsySTsMgY0ehVk Message-ID: From: Barry Leiba To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:27:18 -0000 Bill and Ben, thanks for the reply. Mixing my replies to the two of you here, since it's mostly the same. And I've eliminated anything that there's complete agreement on. >> -- Section 3.2.2 -- >> >> scope (OPTIONAL): An OAuth scope which is valid to access the >> service. This may be omitted which implies that unscoped >> tokens are required. If a scope is specified then a single >> scope is preferred, use of a space separated list of scopes is >> NOT RECOMMENDED. >> >> Why is it "NOT RECOMMENDED"? What interoperability or security issue is >> in play here that makes this "SHOULD NOT"? > > This isn't my preference for language, but some folks have concerns about > using multiple scopes and how that all gets resolved and whether the client > needs to understand scope strings to determine if they already have the > scope they need. Ben's response: > I am a little hazy on this, but I seem to recall that some deployed > software assumes that only a single scope will be used, so this is for > interoperability. (Bill, please jump in if I'm confused.) OK, both wrinkles are fine. If you don't mind, please put a sentence or so of explanation, then. Maybe making it something like "is NOT RECOMMENDED because multiple scopes are problematic for currently deployed software," or whatever makes sense to say here. >> The server MAY return different URLs for users in >> different domains and the client SHOULD NOT cache a single >> returned value and assume it applies for all users/domains that >> the server suports. The returned discovery document SHOULD >> have all data elements required by the OpenID Connect Discovery >> specification populated. >> >> Similar questions for the SHOULD NOT and SHOULD here. In this case, I >> don't understand why they aren't "MUST NOT" and "MUST": for the first, I >> don't understand how a client can interoperate with a server if it violates >> this, and for the second, if they data elements are "required", why isn't >> including them a "MUST"? > > There are implementations now that don't support Dynamic Client Reg. and > requiring it would make no sense for them. Ben's response: > This section was one of the repeated areas of contention over the last > calls, so I am somewhat reluctant to bring it back to the WG for > discussion. I think there would be somewhat more support for SHOULD NOT > --> MUST NOT; the SHOULD for discovery is, IIRC, something of a > compromise, since some parties did not want to bring in a hard dependency > on OpenID Connect's choices. The only reason I can come up for the SHOULD > NOT, off the top of my head, is if some vendor distributed a mail client > that was only ever going to talk to that same vendor's server. Given that it's been discussed and decided, you guys should do the right thing, noting that my comment is non-blocking. I'll just add my further comment that I'm not a fan of using "SHOULD" (or its negative) as a sort of compromise. I very much prefer specifying the protocol the way we think it should be specified, and accepting that not all implementations will meet every aspect of the spec. For Ben's explanation (at the end), for example, I think we should not aim at those sorts of implementations, but at the normal, open-Internet, multi-vendor scenario, which is what the protocol is meant for. And, of course, if a vendor wants to tailor their implementation to a closed scenario, they're always free to do so. But, again: resolve this however you think is right to make the protocol right and to represent the consensus of the working group. No need to further explain to me. >> (Nit: The "if available" at the end of the paragraph is unnecessary; if >> one is not available, it certainly can't be used.) > > We were leaving the door open for other discovery mechanisms so that this > isn't MTI if there are other options. Ben's response: > That's true, but I like the flow of the sentence with the extra > redundancy better than without it. Cool. Let it remain as written. Barry From nobody Thu May 28 11:50:32 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D251A1AE3 for ; Thu, 28 May 2015 11:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.724 X-Spam-Level: X-Spam-Status: No, score=0.724 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW9tfS9qLRKV for ; Thu, 28 May 2015 11:50:28 -0700 (PDT) Received: from nm46-vm9.bullet.mail.gq1.yahoo.com (nm46-vm9.bullet.mail.gq1.yahoo.com [67.195.87.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC291A1AFB for ; Thu, 28 May 2015 11:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432839027; bh=srSPz3z76ieaNiwk0+5Bu8bR8q5kCqpqDkyYFIUVM2A=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From:Subject; b=VrsCVllBDTbPHPUeAHVAYSgaX1JOlQVFNWAtjfxKMev4sOxjnN0rD50Xl2jfZkPlv5Nt5nI/9vo0xvmb1+R0eyf6KUKOVwFy6oZ1uAPiSBMyzpoT/Rx5Ar8TkRCXNx9ux7agHhruWXEmR2606FsU1Jr2uqZgvz8EPhXZENXCcHbzsw5F+rMeF/hvklISq44o5km4abzQ+1qAua81pEWWRq+2SEMlhPY0dr4GvDeLrro8S59UnTOCacPdvNmolnBapLA58YP10LDiAdkSxueCRCQ8cg7T7phlOo0wawByhjTsCozNFpa+pCpqbcqaiZUNioxXwq52kXQtTwv9b0/k8w== Received: from [127.0.0.1] by nm46.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:50:27 -0000 Received: from [98.137.12.55] by nm46.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:47:38 -0000 Received: from [98.139.170.178] by tm15.bullet.mail.gq1.yahoo.com with NNFMP; 28 May 2015 18:47:37 -0000 Received: from [98.139.215.251] by tm21.bullet.mail.bf1.yahoo.com with NNFMP; 28 May 2015 18:47:37 -0000 Received: from [127.0.0.1] by omp1064.mail.bf1.yahoo.com with NNFMP; 28 May 2015 18:47:37 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 672659.95874.bm@omp1064.mail.bf1.yahoo.com X-YMail-OSG: Ai2f1iUVM1mo_WJkeoLgBvhsZTZ_ISECfwcHfZp0syiYNZuDlNidkgGOyXlx1Vs 6qi7EWSl.D8FRApOJX3YA6xBXezb7v2sb3kypkbPhTJmeDFFdldodNEEjtWID2NlgRE7n231dywf 5oPzF4LyQWcRGg1btpily0kpC__Rt26_FHmT5n43J2.v2s2.WAHqq8Z6uGerL30YSa80VlcEPxlR YeBuUtyXLrn7Pu_Tp14bJogKpZFsZsyujX_77Jk1qJqiPFosHlnwibZ6aJE4nNmkBSIwgVp0i3NU RQ45AH951LTNm7SAA9n9E5DaJxivllTmSW7ngYbLT9o08lfE2z2ysU6ZEPZMUM2nYLpdJXZY_BH4 R_Kjbw5zYDpgKFud9pJoVxWcUQEr8jEwQ1tFimMVgpWPaNbYIkXykK4q_iepeLD6z3kb5QxIM6jf XziQpLeFRPVoRklO_N8JYHi_8287JnCnOMtHZlT4ZrukjkU3CAfGLlcZG_u5qsduu2Qy_JS0a.GZ bGETeYy1qaRsUhJTrKf7Hrko- Received: by 66.196.80.120; Thu, 28 May 2015 18:47:37 +0000 Date: Thu, 28 May 2015 18:47:33 +0000 (UTC) From: Bill Mills To: Barry Leiba Message-ID: <68487883.760411.1432838853604.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_760410_1042265162.1432838853598" Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:50:30 -0000 ------=_Part_760410_1042265162.1432838853598 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable OK. =C2=A0Modified the scope language to say=C2=A0 "If a scope is specified then a single scope is preferred. At the time=C2= =A0 this document was written there were several implementations that do=C2= =A0 not properly support space separated lists of scopes, so the use of=C2= =A0 a space separated list of scopes is NOT RECOMMENDED."=C2=A0 -bill On Thursday, May 28, 2015 11:27 AM, Barry Leiba wrote: =20 Bill and Ben, thanks for the reply.=C2=A0 Mixing my replies to the two of you here, since it's mostly the same.=C2=A0 And I've eliminated anything that there's complete agreement on. >> -- Section 3.2.2 -- >> >>=C2=A0 =C2=A0 =C2=A0 scope (OPTIONAL):=C2=A0 An OAuth scope which is vali= d to access the >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 service.=C2=A0 This may be omitted whi= ch implies that unscoped >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 tokens are required.=C2=A0 If a scope = is specified then a single >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 scope is preferred, use of a space sep= arated list of scopes is >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 NOT RECOMMENDED. >> >> Why is it "NOT RECOMMENDED"?=C2=A0 What interoperability or security iss= ue is >> in play here that makes this "SHOULD NOT"? > > This isn't my preference for language, but some folks have concerns about > using multiple scopes and how that all gets resolved and whether the clie= nt > needs to understand scope strings to determine if they already have the > scope they need. Ben's response: > I am a little hazy on this, but I seem to recall that some deployed > software assumes that only a single scope will be used, so this is for > interoperability.=C2=A0 (Bill, please jump in if I'm confused.) OK, both wrinkles are fine.=C2=A0 If you don't mind, please put a sentence or so of explanation, then.=C2=A0 Maybe making it something like "is NOT RECOMMENDED because multiple scopes are problematic for currently deployed software," or whatever makes sense to say here. >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The server MAY return different URLs f= or users in >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 different domains and the client SHOUL= D NOT cache a single >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 returned value and assume it applies f= or all users/domains that >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the server suports.=C2=A0 The returned= discovery document SHOULD >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 have all data elements required by the= OpenID Connect Discovery >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specification populated. >> >> Similar questions for the SHOULD NOT and SHOULD here.=C2=A0 In this case= , I >> don't understand why they aren't "MUST NOT" and "MUST": for the first, I >> don't understand how a client can interoperate with a server if it viola= tes >> this, and for the second, if they data elements are "required", why isn'= t >> including them a "MUST"? > > There are implementations now that don't support Dynamic Client Reg. and > requiring it would make no sense for them. Ben's response: > This section was one of the repeated areas of contention over the last > calls, so I am somewhat reluctant to bring it back to the WG for > discussion.=C2=A0 I think there would be somewhat more support for SHOULD= NOT > --> MUST NOT; the SHOULD for discovery is, IIRC, something of a > compromise, since some parties did not want to bring in a hard dependency > on OpenID Connect's choices.=C2=A0 The only reason I can come up for the = SHOULD > NOT, off the top of my head, is if some vendor distributed a mail client > that was only ever going to talk to that same vendor's server. Given that it's been discussed and decided, you guys should do the right thing, noting that my comment is non-blocking.=C2=A0 I'll just add my further comment that I'm not a fan of using "SHOULD" (or its negative) as a sort of compromise.=C2=A0 I very much prefer specifying the protocol the way we think it should be specified, and accepting that not all implementations will meet every aspect of the spec. For Ben's explanation (at the end), for example, I think we should not aim at those sorts of implementations, but at the normal, open-Internet, multi-vendor scenario, which is what the protocol is meant for.=C2=A0 And, of course, if a vendor wants to tailor their implementation to a closed scenario, they're always free to do so. But, again: resolve this however you think is right to make the protocol right and to represent the consensus of the working group. No need to further explain to me. >> (Nit: The "if available" at the end of the paragraph is unnecessary; if >> one is not available, it certainly can't be used.) > > We were leaving the door open for other discovery mechanisms so that this > isn't MTI if there are other options. Ben's response: > That's true, but I like the flow of the sentence with the extra > redundancy better than without it. Cool.=C2=A0 Let it remain as written. Barry ------=_Part_760410_1042265162.1432838853598 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
OK.  = Modified the scope language to say 

"If a scope is specified then a single scope i= s preferred. At the time 
=09= =09=09=09this document was written there were several implementation= s that do 
=09=09=09=09= not properly support space separated lists of scopes, so the use of 
=09=09=09=09a spa= ce separated list of scopes is NOT RECOMMENDED." 

<= div dir=3D"ltr" class=3D"" style=3D"" id=3D"yui_3_16_0_1_1432834710957_6895= 8">-bill



On Thursday, May 28, 2015 11:27 AM, Bar= ry Leiba <barryleiba@computer.org> wrote:

Bill and Ben, thanks for the reply.  = Mixing my replies to the two of
you here, since it's most= ly the same.  And I've eliminated anything
that ther= e's complete agreement on.

>> --= Section 3.2.2 --
>>
>>&nbs= p;     scope (OPTIONAL):  An OAuth scope which is valid to = access the
>>          ser= vice.  This may be omitted which implies that unscoped
>>          tokens are required.  If= a scope is specified then a single
>>   =       scope is preferred, use of a space separated list of = scopes is
>>          NOT = RECOMMENDED.
>>
>> Why is i= t "NOT RECOMMENDED"?  What interoperability or security issue is
>> in play here that makes this "SHOULD NOT"?
>
> This isn't my preference for language= , but some folks have concerns about
> using multiple = scopes and how that all gets resolved and whether the client
> needs to understand scope strings to determine if they already hav= e the
> scope they need.

Ben's response:
> I am a little hazy on this= , but I seem to recall that some deployed
> software a= ssumes that only a single scope will be used, so this is for
> interoperability.  (Bill, please jump in if I'm confused.)
OK, both wrinkles are fine.  If you= don't mind, please put a sentence
or so of explanation, = then.  Maybe making it something like "is NOT
RECOMM= ENDED because multiple scopes are problematic for currently
deployed software," or whatever makes sense to say here.

>>          The server= MAY return different URLs for users in
>>  &n= bsp;       different domains and the client SHOULD NOT cache= a single
>>          retu= rned value and assume it applies for all users/domains that
>>          the server suports.  The= returned discovery document SHOULD
>>   =       have all data elements required by the OpenID Connect= Discovery
>>          spe= cification populated.
>>
>>= Similar questions for the SHOULD NOT and SHOULD here.  In this case, = I
>> don't understand why they aren't "MUST NOT" an= d "MUST": for the first, I
>> don't understand how = a client can interoperate with a server if it violates
&g= t;> this, and for the second, if they data elements are "required", why = isn't
>> including them a "MUST"?
>
> There are implementations now that don't suppo= rt Dynamic Client Reg. and
> requiring it would make n= o sense for them.

Ben's response:
> This section was one of the repeated areas of contention= over the last
> calls, so I am somewhat reluctant to = bring it back to the WG for
> discussion.  I thin= k there would be somewhat more support for SHOULD NOT
>= ; --> MUST NOT; the SHOULD for discovery is, IIRC, something of a
> compromise, since some parties did not want to bring in a = hard dependency
> on OpenID Connect's choices.  T= he only reason I can come up for the SHOULD
> NOT, off= the top of my head, is if some vendor distributed a mail client
> that was only ever going to talk to that same vendor's serve= r.

Given that it's been discussed and = decided, you guys should do the
right thing, noting that = my comment is non-blocking.  I'll just add my
furthe= r comment that I'm not a fan of using "SHOULD" (or its negative)
as a sort of compromise.  I very much prefer specifying the = protocol
the way we think it should be specified, and acc= epting that not all
implementations will meet every aspec= t of the spec.

For Ben's explanation (= at the end), for example, I think we should not
aim at th= ose sorts of implementations, but at the normal,
open-Int= ernet, multi-vendor scenario, which is what the protocol is
meant for.  And, of course, if a vendor wants to tailor their
implementation to a closed scenario, they're always free to do= so.

But, again: resolve this however = you think is right to make the
protocol right and to repr= esent the consensus of the working group.
No need to furt= her explain to me.

>> (Nit: The = "if available" at the end of the paragraph is unnecessary; if
>> one is not available, it certainly can't be used.)
>
> We were leaving the door open for oth= er discovery mechanisms so that this
> isn't MTI if th= ere are other options.

Ben's response:=
> That's true, but I like the flow of the sentence wi= th the extra
> redundancy better than without it.

Cool.  Let it remain as written.


Barry


------=_Part_760410_1042265162.1432838853598-- From nobody Thu May 28 11:55:12 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749AC1A1B2E; Thu, 28 May 2015 11:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QxiUII3bWax; Thu, 28 May 2015 11:55:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 305311A1B22; Thu, 28 May 2015 11:55:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150528185510.29430.64418.idtracker@ietfa.amsl.com> Date: Thu, 28 May 2015 11:55:10 -0700 Archived-At: Cc: kitten-chairs@ietf.org, draft-ietf-kitten-sasl-oauth.shepherd@ietf.org, kitten@ietf.org, draft-ietf-kitten-sasl-oauth@ietf.org, draft-ietf-kitten-sasl-oauth.ad@ietf.org Subject: [kitten] Ben Campbell's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 18:55:11 -0000 Ben Campbell has entered the following ballot position for draft-ietf-kitten-sasl-oauth-22: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- [All of the comments below have been addressed by the authors] -- section 1, description of step A: if the preferred way is different than the diagram, why not show it the preferred way in the diagram in the first place? -- 1, 2nd to last paragraph The "SHOULD" means the reference to I-D.ietf-oauth-dyn-reg needs to be be normative. -- 3: "Such a new SASL OAuth mechanism can be added by simply registering the new name(s)" Register them where? -- 3.2, 2nd paragraph : "... known to the application." Known to the "resource server"? Editorial Stuff: -- 3.1, "Port": I assume that means the destination port to which the client connected? (similar to Host?) -- 3.1.1 "Post": default value is "". Does "" represent an empty string? -- 3.2, first sentence" s/" ... according the specification..." / "... according to the specification..." - 5: "Lifetime of the appliation sessions" s/appliation/application "It is possible that SASL will be authenticating..." s/"... be authenticating..." / "... be used to authenticate..." From nobody Thu May 28 12:16:58 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EA21A6FFC; Thu, 28 May 2015 12:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnPyUciEL9rV; Thu, 28 May 2015 12:16:51 -0700 (PDT) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA201A1AFB; Thu, 28 May 2015 12:16:51 -0700 (PDT) Received: by igbyr2 with SMTP id yr2so120878602igb.0; Thu, 28 May 2015 12:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tuvFffb7mhOxjQxU7omrRgRFcGfQVdh/E862Z73hEP0=; b=Ouuf/ZUzG4r87XfCwc4yLnjqmnMJnKgIpoqQzq0Pqr/Ssjv9rhD9VESGeBaoJjpixk ttqPIxVEAt2ItpykjXGF9fWL0NxFEXi5ypE1sA44OKHe/M28uP+0p6cJBUIbwdL69aNR ZbDMvacWDdbQEGyjPI6hBlM0TP3PSYlEolN7FKAzrAXQvNFx/Y++1bQEK6n+SdI3Aj+I /+PATXIDYUCkcfQZRkYp8cbxOEHaczr3IZTa7LoLzHncfeHu/ochrc0emmIZQ7+Slyd3 fHZMn6R96S07RDMbSD4YnI0ibQ0IWJorggmh9kOrXDWvHgMFSPVV9LVh3pG5V+KTDg2G 5Xqg== MIME-Version: 1.0 X-Received: by 10.50.4.66 with SMTP id i2mr40646284igi.40.1432840611074; Thu, 28 May 2015 12:16:51 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.107.3.195 with HTTP; Thu, 28 May 2015 12:16:50 -0700 (PDT) In-Reply-To: <68487883.760411.1432838853604.JavaMail.yahoo@mail.yahoo.com> References: <68487883.760411.1432838853604.JavaMail.yahoo@mail.yahoo.com> Date: Thu, 28 May 2015 15:16:50 -0400 X-Google-Sender-Auth: ezVRYM84KR8N4krsK4VUcnr8QpY Message-ID: From: Barry Leiba To: Bill Mills Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "kitten-chairs@ietf.org" , "draft-ietf-kitten-sasl-oauth.shepherd@ietf.org" , "kitten@ietf.org" , The IESG , "draft-ietf-kitten-sasl-oauth@ietf.org" , "draft-ietf-kitten-sasl-oauth.ad@ietf.org" Subject: Re: [kitten] Barry Leiba's No Objection on draft-ietf-kitten-sasl-oauth-22: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 19:16:52 -0000 > OK. Modified the scope language to say > > "If a scope is specified then a single scope is preferred. At the time > this document was written there were several implementations that do > not properly support space separated lists of scopes, so the use of > a space separated list of scopes is NOT RECOMMENDED." Thanks! Barry From nobody Thu May 28 12:53:49 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762681A8877 for ; Thu, 28 May 2015 12:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2k_u4p8BlMzT for ; Thu, 28 May 2015 12:53:47 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146F01A8871 for ; Thu, 28 May 2015 12:53:46 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4SJrbhV030772 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 28 May 2015 21:53:38 +0200 From: Simon Josefsson To: Tony Hansen References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> <55673385.6080006@att.com> OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt X-Hashcash: 1:22:150528:kitten@ietf.org::hydvHbNhub2m0K0P:9nV X-Hashcash: 1:22:150528:tony@att.com::I5jGZeTpOB7w/nKh:7cCJ Date: Thu, 28 May 2015 21:53:36 +0200 In-Reply-To: <55673385.6080006@att.com> (Tony Hansen's message of "Thu, 28 May 2015 11:25:57 -0400") Message-ID: <87iobczdfj.fsf@latte.josefsson.org> User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/24.4 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 19:53:48 -0000 --=-=-= Content-Type: text/plain Tony Hansen writes: > Simon, right now scram-sha256 does not change anything in the SCRAM base > spec other than setting the hash mechanism to SHA256. Right. > I *think* what you are asking for would actually be a change to the > SCRAM base spec, which so far has been out of scope for this document. You are right -- the SCRAM base spec has the same issue. Depending on which RFCs the tls-session-hash document will end up Update:'ing, it may be necessary to revise SCRAM. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEbBAEBCAAGBQJVZ3JAAAoJEIYLf7sy+BGdT2oH9i/pLlkpHs2N3QjXn4BMktCC mRTLAM6bRHFdH981PzifmBllvDnWqGPy+4H5mYB+JI7A5ludAwohq9maaz3JR70E puHsimT1sdkEY9L900II9Xw3J4p6b0ROh9lBr4RPcLkpMeF5m5yaChIofL9rftud VLcpbZqiieoApioTBFYKySeC0u+awQA/iu8SOXLEJdvvxmy/QH77SyZv2zo6LwHU gg916F6hguFcmnjaOQhly90XzFtq/DIzrqAhnKs97Le+9uD0vGGPXe7S8D3OH9z2 Is2gAkshpYArW7HZEUwdEuCP4GXlhe+XJRlOHJ96pS3NrrPqM9Iwp1vMB4O27w== =Ty1Z -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 28 13:01:57 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E1A1A88C1 for ; Thu, 28 May 2015 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha3oYtSEiM5l for ; Thu, 28 May 2015 13:01:55 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6B01A88C0 for ; Thu, 28 May 2015 13:01:54 -0700 (PDT) Received: from latte.josefsson.org ([155.4.17.3]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id t4SK1heM031719 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 28 May 2015 22:01:45 +0200 Date: Thu, 28 May 2015 22:01:42 +0200 From: Simon Josefsson To: Nico Williams Message-ID: <20150528220142.374f2626@latte.josefsson.org> In-Reply-To: <20150528164000.GF1733@localhost> References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> <20150528164000.GF1733@localhost> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/pQsHjr1bw6dS1Z.Fj8H3b6k"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.7 at duva.sjd.se X-Virus-Status: Clean Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:01:56 -0000 --Sig_/pQsHjr1bw6dS1Z.Fj8H3b6k Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable > On Thu, May 28, 2015 at 05:11:22PM +0200, Simon Josefsson wrote: > > > > You then go on to say: "Personally, I would prefer to change to > > > > another mandatory channel binding that is secure for all TLS > > > > versions." > > >=20 > > > This is not really appropriate here because it's the applications > > > that need to do this, and we can't say anything here about this > > > that will force them to. > >=20 > > > A reference to TLS-SESSION-HASH of the same level (i.e., normative > > > or informative) as RFCs 5246 and 5929 would be nice. > >=20 > > I believe that what is required is > >=20 > > 1) scram-sha256 has a normative reference to tls-session-hash; or > >=20 > > 2) tls-session-hash uses an Update: that makes it applicapable to > > all TLS versions, and that it is clarified (if not already the > > case) that tls-session-hash must be used; or >=20 > And RFC5929. That's not strictly necessary, is it? 5929 refer to TLS, so if tls-session-hash update TLS specs, 5929 indirectly refer too tls-session-hash. At least that is how I would interprete it. But I'm all for making things explicit. > My vote is for (2). I don't mind (1) in addition, but I want (2). There is precedent for that for TLS, several of the security fixes Update:'s all TLS RFCs. =20 > > 3) scram-sha256 uses a new channel binding that is secure with or > > without tls-session-hash. >=20 > We disagree as to (3). This is advice we can give to apps in the > security considerations section, not something we can force a SASL or > GSS mechanism to do because API-wise the mechanism doesn't get a > choice. I don't understand this... > > I believe 1) and 2) would be worse than 3) for the next ~5 years or > > so, and things being equal after that. SASL libraries/applications > > rarely have any influence over TLS internals, but they directly > > influence the channel binding used. Using another channel binding > > for [...] >=20 > No, they don't. Certainly not GSS ones, and the SASL implementations > I'm familiar with don't either. >=20 > E.g., GSS_Init_sec_context() doesn't get a handle to a channel to bind > to, it only gets the channel binding as already extracted by the app. > Worse, GSS_Init_sec_context() doesn't even get the channel binding > type. ...and I don't understand any of this. A new channel binding in SCRAM-SHA256 would work exactly the same way as tls-unique works in SCRAM-SHA1 today. In my SASL library, the app has to provide the tls-unique channel binding (either upfront or in a callback) when SCRAM-SHA1 is used. If I would implement SCRAM-SHA256, and assuming that document referred directly to tls-unique-prf, the app would need to supply the tls-unique-prf data upfront or in a callback when SCRAM-SHA256 is used. I don't see any problem with this. The channel binding type is hardcoded with the SASL mechanism name. > (3) is unworkable. We disagree. /Simon --Sig_/pQsHjr1bw6dS1Z.Fj8H3b6k Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVZ3QmAAoJEIYLf7sy+BGdYd4H/0I8Y9A5I74tJtsKWSGPVFSr bW+6wYS7LBkWD+S4o2QrsymV7W7gRp/p6j74z4cuoS0NNlMvlfPNWMIOVi6EMV5J hQp0H/VrDzePYLsrC2vWMIezZ+PsqBcS5Lt5GA+XvkssbE9zC/pb5uHfSjAG2gAr 0JRefTPjfeBuO+mOdR2QxvZQ3Ltj6zrYrdeUgPxDj6CLXp4EXk2/ZSYJM4oe48DN gJnAzaGokH3jQPE59mBRRJ/gjiHCylTRFfrfoLUJ67OpR6DeoyhrzLKfdhFSeNHs P7/jLnKr0ajU+ZfdRENwC+FXWK38XsEbU55xa/KhtyNk4tVOROvF4PCu0YRZRgc= =8kGQ -----END PGP SIGNATURE----- --Sig_/pQsHjr1bw6dS1Z.Fj8H3b6k-- From nobody Thu May 28 13:37:03 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4EA1A8937 for ; Thu, 28 May 2015 13:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6V6eCEoQmYHu for ; Thu, 28 May 2015 13:37:00 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id B8D391A8932 for ; Thu, 28 May 2015 13:36:58 -0700 (PDT) Received: from homiemail-a63.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTP id 850B92F407A; Thu, 28 May 2015 13:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=xYkjfrGlYV3HNZ guXkpHN7Lp9Bw=; b=xj5pBiLM8iPf0GpJjPKaE8pYx6dwyH3MikEUC7eyHdp7Zc 3UKkmC6JuUMxbJCyYujQzl2wES9xRy5CD7nxkdbeT4mX+HxqI2qhAs/sUSJZHsjN ZUDc/lXUVmtqtMv1IL8AbOYgbqI0Fn4sJ0qaAWgkIy9hnAabn8QH3YNDMYZ2M= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a63.g.dreamhost.com (Postfix) with ESMTPA id 3A1492F4076; Thu, 28 May 2015 13:36:57 -0700 (PDT) Date: Thu, 28 May 2015 15:36:56 -0500 From: Nico Williams To: Simon Josefsson Message-ID: <20150528203654.GI1733@localhost> References: <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> <20150528164000.GF1733@localhost> <20150528220142.374f2626@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150528220142.374f2626@latte.josefsson.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:37:01 -0000 On Thu, May 28, 2015 at 10:01:42PM +0200, Simon Josefsson wrote: > > On Thu, May 28, 2015 at 05:11:22PM +0200, Simon Josefsson wrote: > > > > > You then go on to say: "Personally, I would prefer to change to > > > > > another mandatory channel binding that is secure for all TLS > > > > > versions." > > > > > > > > This is not really appropriate here because it's the applications > > > > that need to do this, and we can't say anything here about this > > > > that will force them to. > > > > > > > A reference to TLS-SESSION-HASH of the same level (i.e., normative > > > > or informative) as RFCs 5246 and 5929 would be nice. > > > > > > I believe that what is required is > > > > > > 1) scram-sha256 has a normative reference to tls-session-hash; or > > > > > > 2) tls-session-hash uses an Update: that makes it applicapable to > > > all TLS versions, and that it is clarified (if not already the > > > case) that tls-session-hash must be used; or > > > > And RFC5929. > > That's not strictly necessary, is it? 5929 refer to TLS, so if > tls-session-hash update TLS specs, 5929 indirectly refer too > tls-session-hash. At least that is how I would interprete it. But > I'm all for making things explicit. Less not-strictly-necessary than the change you're proposing to SCRAM... After all, it'd be useful if anyone reading RFC5929 saw that there's a security consideration when using TLS w/o the session hash (namely: that tls-unique is insecure when used with connections made by resuming sessions). > > My vote is for (2). I don't mind (1) in addition, but I want (2). > > There is precedent for that for TLS, several of the security fixes > Update:'s all TLS RFCs. Yes. > > > 3) scram-sha256 uses a new channel binding that is secure with or > > > without tls-session-hash. > > > > We disagree as to (3). This is advice we can give to apps in the > > security considerations section, not something we can force a SASL or > > GSS mechanism to do because API-wise the mechanism doesn't get a > > choice. > > I don't understand this... The mechanism is not in a position to use any one CB type or other. The application chooses the CB type. > > > I believe 1) and 2) would be worse than 3) for the next ~5 years or > > > so, and things being equal after that. SASL libraries/applications > > > rarely have any influence over TLS internals, but they directly > > > influence the channel binding used. Using another channel binding > > > for [...] > > > > No, they don't. Certainly not GSS ones, and the SASL implementations > > I'm familiar with don't either. > > > > E.g., GSS_Init_sec_context() doesn't get a handle to a channel to bind > > to, it only gets the channel binding as already extracted by the app. > > Worse, GSS_Init_sec_context() doesn't even get the channel binding > > type. > > ...and I don't understand any of this. I don't understand how you can't understand it. GSS_Init_sec_context() doesn't have access to the TLS (or whatever) channel, and therefore the mechanism can't be involved in getting the channel binding. > A new channel binding in SCRAM-SHA256 would work exactly the same way > as tls-unique works in SCRAM-SHA1 today. > > In my SASL library, the app has to provide the tls-unique channel > binding (either upfront or in a callback) when SCRAM-SHA1 is used. If > I would implement SCRAM-SHA256, and assuming that document referred > directly to tls-unique-prf, the app would need to supply the > tls-unique-prf data upfront or in a callback when SCRAM-SHA256 is > used. I don't see any problem with this. The channel binding type is > hardcoded with the SASL mechanism name. The CB type is NOT a part of the mechanism name. The CB type name is prefixed to the CB data in the SASL/GS2 case (but not in the non-SASL GSS case). The best SCRAM-SHA256 could do is detect that tls-unique is used in the SASL/GS2 case and fail. Nico -- From nobody Thu May 28 13:47:43 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FDAC1A8902 for ; Thu, 28 May 2015 13:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nhy97mWvTdAn for ; Thu, 28 May 2015 13:47:40 -0700 (PDT) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD1381A892A for ; Thu, 28 May 2015 13:47:39 -0700 (PDT) Received: from unknown [144.160.229.23] (EHLO alpi154.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-7.2.4-5) over TLS secured channel with ESMTP id bee77655.0.5505289.00-2011.14737132.nbfkord-smmo07.seg.att.com (envelope-from ); Thu, 28 May 2015 20:47:39 +0000 (UTC) X-MXL-Hash: 55677eeb4894f454-dc637a7fa37a28212337832ee01b751e9235e53d Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SKlcAm009496 for ; Thu, 28 May 2015 16:47:39 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SKlV9p009406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 28 May 2015 16:47:31 -0400 Received: from alpi153.aldc.att.com (alpi153.aldc.att.com [130.8.42.31]) by alpi133.aldc.att.com (RSA Interceptor) for ; Thu, 28 May 2015 20:47:13 GMT Received: from aldc.att.com (localhost [127.0.0.1]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SKlDBH015487 for ; Thu, 28 May 2015 16:47:14 -0400 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpi153.aldc.att.com (8.14.5/8.14.5) with ESMTP id t4SKl8UP015147 for ; Thu, 28 May 2015 16:47:08 -0400 Received: from gacdtl01nh2976.itservices.sbc.com ([135.110.240.187]) by maillennium.att.com (mailgw1) with ESMTP id <20150528204705gw1000cecve>; Thu, 28 May 2015 20:47:08 +0000 X-Originating-IP: [135.110.240.187] Message-ID: <55677EC8.4040405@att.com> Date: Thu, 28 May 2015 16:47:04 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 CC: "kitten@ietf.org" References: <54DC00D0.2050900@cs.tcd.ie> <54EC66FF.50603@cs.tcd.ie> <54ECABD8.3090902@att.com> <87zj82f1yj.fsf@latte.josefsson.org> <54F4B8B8.8090406@isode.com> <555FC6CF.5020306@att.com> <20150523162728.5b6b63cd@latte.josefsson.org> <5564F27D.70109@att.com> <20150526223206.GE27628@localhost> <20150528171122.2bceebb6@latte.josefsson.org> <55673385.6080006@att.com> <87iobczdfj.fsf@latte.josefsson.org> In-Reply-To: <87iobczdfj.fsf@latte.josefsson.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fv9u9vtearD8ftvwnMNqd4DH8WitBXD86" X-RSA-Inspected: yes X-RSA-Classifications: public X-AnalysisOut: [v=2.0 cv=RJUE6fe+ c=1 sm=1 a=VXHOiMMwGAwA+y4G3/O+aw==:17 a] X-AnalysisOut: [=9cW_t1CCXrUA:10 a=tHvJy1wsfNMA:10 a=dzjzQdhL4rYA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=zQP7CpKOAAAA:8 a=h1PgugrvaO0A:10 a=1rDwWAva] X-AnalysisOut: [a-M8UfumqTgA:9 a=QEXdDO2ut3YA:10 a=j4nzMFrpAAAA:8 a=AX4UgD] X-AnalysisOut: [V_oVNjRtAcSR0A:9] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.23] Archived-At: Subject: Re: [kitten] draft-hansen-scram-sha256 and incorporating session hashing for channel binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 20:47:41 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fv9u9vtearD8ftvwnMNqd4DH8WitBXD86 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 5/28/15 3:53 PM, Simon Josefsson wrote: > Tony Hansen writes: > >> Simon, right now scram-sha256 does not change anything in the SCRAM ba= se >> spec other than setting the hash mechanism to SHA256. > Right. > >> I *think* what you are asking for would actually be a change to the >> SCRAM base spec, which so far has been out of scope for this document.= > You are right -- the SCRAM base spec has the same issue. Depending on > which RFCs the tls-session-hash document will end up Update:'ing, it ma= y > be necessary to revise SCRAM. One slight modification to my previous statement: I *am* updating the SCRAM registration mechanism for SCRAM, which is turning out to be more involved than I had originally expected. Nonetheless, I already have the "updating RFC5802" mark on this draft. If we can agree on a (hopefully upwards-compatible) change for the channel binding issue, it could be done now. However, doing so would probably also reset the IETF Last Call on it. Tony --fv9u9vtearD8ftvwnMNqd4DH8WitBXD86 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVZ37IAAoJEKd93u989/UtZloP/jNrgscP05o8nq9xemnm0aEY mrGUGuBlbZ+7ecqQRgW3mD9VmEpQ9sTEv3t8Q2d/YQS6S6+zfMNLBQ91bDNIOqSU mYgJ4OWiiWYTRAfw7MwlsBKqC/AgNTADsG0a9h6O0z6L/Ww1Mam0dO0ZXfmVP8xQ NufVUJcsBeWl+Khy3pi0L/g3ZHljsqQwsAi8ncuNK/pIsuv8aEtBqEIhkktlvp5c xTSSTCDnDt4eXCoZwah4n+K+nekh0vB8y3ffE78ugQTblAxUkuQyi7VHHqUQzz+P jdihsXt+12Hnz2wYbGhZdUIYa33wHM5a40bpWDnUwFXN394j55ZsOUPJg88L0kdH zTf6naDIEwKjsZMqPCyM/KFMHvVN8/noipMm37UcMEwkm2DkTDj/DtyznxrjsvM9 /7UuesgZ8bSGZPTWOZCWIXIqATbtlhAIb+cEK1r2HooEzpnINR2JFVGcrjt2pi6L STUMOskTpHmuHCpIDVrp2YMRqIHBmzEf3SQ8VEYfyImUyztiWxE+/T9ZmTJoTB0/ qLFAlPAcFBKoUf3lPOZX+WYfKZKQ1cIccGk5dvOv9/+TqSDttUadG7pvx0/ci0LG 3VpR6aP5FQZ4asQu0l85Bs1Yn5GGMpVu4txwAlu5mcSpE0gEJELA6btxKAYkuZ1F Q3GkF+SKh0N1mpAhXIpw =fNWv -----END PGP SIGNATURE----- --fv9u9vtearD8ftvwnMNqd4DH8WitBXD86-- From nobody Fri May 29 09:50:07 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2B1ACDC8; Fri, 29 May 2015 09:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tYcgDJ043YB4; Fri, 29 May 2015 09:50:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB91ACDBB; Fri, 29 May 2015 09:50:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150529165004.2217.7049.idtracker@ietfa.amsl.com> Date: Fri, 29 May 2015 09:50:04 -0700 Archived-At: Cc: kitten@ietf.org Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-23.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 16:50:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF. Title : A set of SASL Mechanisms for OAuth Authors : William Mills Tim Showalter Hannes Tschofenig Filename : draft-ietf-kitten-sasl-oauth-23.txt Pages : 24 Date : 2015-05-29 Abstract: OAuth enables a third-party application to obtain limited access to a protected resource, either on behalf of a resource owner by orchestrating an approval interaction, or by allowing the third-party application to obtain access on its own behalf. This document defines how an application client uses credentials obtained via OAuth over the Simple Authentication and Security Layer (SASL) to access a protected resource at a resource serve. Thereby, it enables schemes defined within the OAuth framework for non-HTTP- based application protocols. Clients typically store the user's long-term credential. This does, however, lead to significant security vulnerabilities, for example, when such a credential leaks. A significant benefit of OAuth for usage in those clients is that the password is replaced by a shared secret with higher entropy, i.e., the token. Tokens typically provide limited access rights and can be managed and revoked separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-sasl-oauth-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 29 09:57:47 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7086E1ACE45 for ; Fri, 29 May 2015 09:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDpytVAB-yy3 for ; Fri, 29 May 2015 09:57:45 -0700 (PDT) Received: from nm48-vm1.bullet.mail.ne1.yahoo.com (nm48-vm1.bullet.mail.ne1.yahoo.com [98.138.121.113]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24AE41ACE03 for ; Fri, 29 May 2015 09:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1432918639; bh=sGTWYoig8CXWY6H/3WnOrxHix49oWJ77dNKmTY+b/kY=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject; b=BrNNARRpZ2p+QyEBwI/w0npv6RZzE2HAsyL0aGbrRtIortv+FTH48azRTehqsv7A+mqyqSE9jSKMLckIXUsVxdKwVYqnxlcE+DQjXP0bTyUovaKdQTegv/+wkHdwi3DByenzRjEbN9GNnHmUKUq8Ukgcr6xUIaOFJmWBzS7aPHsdf8AavOv8n6+jP0uJKPSkNjD3Mv57Hmj3dTi+3pugKfwW0MpRBHrebvqQrppDgTTtZCbEQkDDgoru3+PU0AzU/L2HRySBtEuo6yaHqRDsSrYMlu+Yrxlo58rusGNdSayTTnm9bDEBKq2qk9nnjjeruC1wbIUG1p7y0RH8ueneIA== Received: from [127.0.0.1] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2015 16:57:19 -0000 Received: from [98.138.226.176] by nm48.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2015 16:54:18 -0000 Received: from [66.196.81.170] by tm11.bullet.mail.ne1.yahoo.com with NNFMP; 29 May 2015 16:54:18 -0000 Received: from [98.139.215.229] by tm16.bullet.mail.bf1.yahoo.com with NNFMP; 29 May 2015 16:54:18 -0000 Received: from [127.0.0.1] by omp1069.mail.bf1.yahoo.com with NNFMP; 29 May 2015 16:54:18 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 531439.31983.bm@omp1069.mail.bf1.yahoo.com X-YMail-OSG: yeEu2osVM1kDttFH0__gn.g.XOhl56bulP.wvSXLvWICTzugfjMwYP.joGzKJTR RnBNAeu2Po8Wk08gXNlsZuHw8KJ_9w5wbDCKEAoOTB_5V2jF8zXeIeadbtxQ.WsngBjudiFgV.hE rSAzxdy._cdEUE.2SBYpAs1bs9dzoQ45sC9586X7FyXYqCicBNrQZhYy_2HtQlwzZ2tx.ankzgc_ KSkJnwjn_k78dhu1xg5tvoUtXfiO7HpS93mau6UzZBbsMqhldebM.f7V86K3CnDwmgFJ9gzdl3tY u9yz1KBSlc92fN21Ep4pvsCBw2iUxaNS0B4Ncef72A_3leoVPXOPo53GVjgTSZWB73LAuRNPHJJI nKQBc_m81io2Il5E54Oi6wmkmzd20xdq0rmWsF8uXrEMY7e9OsK3wL32wudFuWusy3bP74qG0PKR eDyb.pfqYKHZXpOdmSARzEMR1Rp7Gt4Dflp11EKiqKXXT2Drhp6vtZUg3A3LMjSECMBsb6eAsl3w JxniOOQtdxteXJ.h_3e3c Received: by 76.13.27.134; Fri, 29 May 2015 16:54:18 +0000 Date: Fri, 29 May 2015 16:54:17 +0000 (UTC) From: Bill Mills To: "kitten@ietf.org" , Stephen Farrell Message-ID: <1158268268.1500683.1432918457535.JavaMail.yahoo@mail.yahoo.com> In-Reply-To: <20150529165004.2217.7049.idtracker@ietfa.amsl.com> References: <20150529165004.2217.7049.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1500681_1641460419.1432918457532" Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-sasl-oauth-23.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 16:57:46 -0000 ------=_Part_1500681_1641460419.1432918457532 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Incorporates IESG all pending review feedback.=C2=A0 -bill=20 On Friday, May 29, 2015 9:50 AM, "internet-drafts@ietf.org" wrote: =20 =20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Authentication Technology Next Gen= eration Working Group of the IETF. =C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A set= of SASL Mechanisms for OAuth =C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 : William Mi= lls =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Tim Showalter =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Hannes Tschofenig =C2=A0=C2=A0=C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ietf-kitten-= sasl-oauth-23.txt =C2=A0=C2=A0=C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 24 =C2=A0=C2=A0=C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 2015-05-= 29 Abstract: =C2=A0 OAuth enables a third-party application to obtain limited access to = a =C2=A0 protected resource, either on behalf of a resource owner by =C2=A0 orchestrating an approval interaction, or by allowing the third-part= y =C2=A0 application to obtain access on its own behalf. =C2=A0 This document defines how an application client uses credentials =C2=A0 obtained via OAuth over the Simple Authentication and Security Layer =C2=A0 (SASL) to access a protected resource at a resource serve.=C2=A0 The= reby, =C2=A0 it enables schemes defined within the OAuth framework for non-HTTP- =C2=A0 based application protocols. =C2=A0 Clients typically store the user's long-term credential.=C2=A0 This = does, =C2=A0 however, lead to significant security vulnerabilities, for example, =C2=A0 when such a credential leaks.=C2=A0 A significant benefit of OAuth f= or =C2=A0 usage in those clients is that the password is replaced by a shared =C2=A0 secret with higher entropy, i.e., the token.=C2=A0 Tokens typically =C2=A0 provide limited access rights and can be managed and revoked =C2=A0 separately from the user's long-term password. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-oauth/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-kitten-sasl-oauth-23 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten ------=_Part_1500681_1641460419.1432918457532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Inco= rporates IESG all pending review feedback. 

-bill

<= br>
On Friday, M= ay 29, 2015 9:50 AM, "internet-drafts@ietf.org" <internet-drafts@ietf.or= g> wrote:


A New Internet-Draft is available from the on-line Internet-Drafts direct= ories.
This draft is a work item of the Common Authentication Technolog= y Next Generation Working Group of the IETF.

      &n= bsp; Title          : A set of SASL Mechanisms fo= r OAuth
        Authors        = : William Mills
                =           Tim Showalter
      &n= bsp;                   Hannes = Tschofenig
    Filename        : draf= t-ietf-kitten-sasl-oauth-23.txt
    Pages    &n= bsp;     : 24
    Date      &nb= sp;     : 2015-05-29

Abstract:
  OAuth enables a = third-party application to obtain limited access to a
  protected = resource, either on behalf of a resource owner by
  orchestrating = an approval interaction, or by allowing the third-party
  applicat= ion to obtain access on its own behalf.

  This document define= s how an application client uses credentials
  obtained via OAuth = over the Simple Authentication and Security Layer
  (SASL) to acce= ss a protected resource at a resource serve.  Thereby,
  it e= nables schemes defined within the OAuth framework for non-HTTP-
  = based application protocols.

  Clients typically store the use= r's long-term credential.  This does,
  however, lead to sign= ificant security vulnerabilities, for example,
  when such a crede= ntial leaks.  A significant benefit of OAuth for
  usage in t= hose clients is that the password is replaced by a shared
  secret= with higher entropy, i.e., the token.  Tokens typically
  pr= ovide limited access rights and can be managed and revoked
  separ= ately from the user's long-term password.


The IETF datatracker s= tatus page for this draft is:
https://datatracker.ietf= .org/doc/draft-ietf-kitten-sasl-oauth/

There's also a htmlized v= ersion available at:
https://tools.ietf.org/html/draft-ie= tf-kitten-sasl-oauth-23

A diff from the previous version is avai= lable at:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-kitten-sasl-oauth-23


Please note that it may take a = couple of minutes from the time of submission
until the htmlized version= and diff are available at tools.ietf.org.

Internet-Drafts are also = available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___= ____________________________________________
Kitten mailing list
Kitten@ie= tf.org
https://www.ietf.org/mailman/listinfo/kitten


<= /div>
------=_Part_1500681_1641460419.1432918457532-- From nobody Fri May 29 15:36:01 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763A31A1ADC for ; Fri, 29 May 2015 15:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQCrm4fQdqSC for ; Fri, 29 May 2015 15:35:55 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0095.outbound.protection.outlook.com [65.55.169.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAC001A8A80 for ; Fri, 29 May 2015 15:35:54 -0700 (PDT) Received: from CO2PR06CA033.namprd06.prod.outlook.com (10.141.242.33) by CY1PR0601MB1564.namprd06.prod.outlook.com (25.163.232.142) with Microsoft SMTP Server (TLS) id 15.1.172.22; Fri, 29 May 2015 22:35:52 +0000 Received: from BN1AFFO11FD007.protection.gbl (2a01:111:f400:7c10::185) by CO2PR06CA033.outlook.office365.com (2a01:111:e400:142a::33) with Microsoft SMTP Server (TLS) id 15.1.172.22 via Frontend Transport; Fri, 29 May 2015 22:35:52 +0000 Authentication-Results: spf=pass (sender IP is 199.135.140.13) smtp.mailfrom=fs.fed.us; ietf.org; dkim=none (message not signed) header.d=none; Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.13 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.13; helo=mail.usda.gov; Received: from mail.usda.gov (199.135.140.13) by BN1AFFO11FD007.mail.protection.outlook.com (10.58.52.67) with Microsoft SMTP Server (TLS) id 15.1.184.11 via Frontend Transport; Fri, 29 May 2015 22:35:51 +0000 Received: from 001FSN2MPN1-046.001f.mgd2.msft.net ([169.254.6.131]) by 001FSN2MMR1-003.001f.mgd2.msft.net ([199.135.140.13]) with mapi id 14.03.0224.003; Fri, 29 May 2015 22:35:49 +0000 From: "Nordgren, Bryce L -FS" To: "kitten@ietf.org" Thread-Topic: Group/Enterprise encrypted email Thread-Index: AdCaU4EBKI9vXfbmSrKplnpcKmT5cg== Date: Fri, 29 May 2015 22:35:49 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.27.143] Content-Type: multipart/alternative; boundary="_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3001FSN2MPN1046001_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD007; 1:iO9A4rYp5IyCP2EMDvqIFvasFAjl0RcfLx/FkR7VHzW0XwUnvr0BDQ9qjpGduzhrJovRczDHJVar+BpVDTFRfWbNbH8NB3CNhJ6sqNRo4uQYb1Iayglgc/bQz3z9+R0Ldga7EVNBARUSFWGr5uh8NDdM3/87w1fCu4W2vyMYHM0XOVHBYxNNpYEsWdu4eF0MUDiNWMHYT3vRTXnqOMa+SNhNutp/syIvBK+NfFfw6rdGMC8NG/hQfS3TDfPjMcV2IUVl8d5RwoZFVMjVD8yCjg== X-Forefront-Antispam-Report: CIP:199.135.140.13; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(76104003)(199003)(450100001)(229853001)(19300405004)(22756005)(22746005)(2930100002)(6806004)(81156007)(4001540100001)(54356999)(189998001)(33656002)(2501003)(55846006)(104016003)(69596002)(46102003)(86146001)(97736004)(5890100001)(26826002)(87936001)(2920100001)(86362001)(19625215002)(102836002)(16236675004)(66066001)(19580395003)(84326002)(62966003)(2351001)(512954002)(110136002)(77156002)(74482002)(107886002)(2900100001)(64706001)(15975445007)(5001960100002)(50986999)(68736005)(2656002)(5001830100001)(106466001)(5001860100001)(92566002)(80862005)(79686002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR0601MB1564; H:mail.usda.gov; FPR:; SPF:Pass; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0601MB1564; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(520003)(5005006)(3002001); SRVR:CY1PR0601MB1564; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0601MB1564; X-Forefront-PRVS: 059185FE08 X-OriginatorOrg: fs.fed.us X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 May 2015 22:35:51.6362 (UTC) X-MS-Exchange-CrossTenant-Id: 49808c08-7df8-4c41-af62-7a0827de9408 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=49808c08-7df8-4c41-af62-7a0827de9408; Ip=[199.135.140.13]; Helo=[mail.usda.gov] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0601MB1564 Archived-At: Subject: [kitten] Group/Enterprise encrypted email X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 22:35:59 -0000 --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3001FSN2MPN1046001_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is a "what if" message, centered around trying to make email encryptio= n as painless as email signing. I want to be able to encrypt an email messa= ge once, no matter how many recipients there are. An enterprise should be a= ble to decrypt employees' email to ensure there's no misbehavior. I want as= little "extra" supporting infrastructure as possible. I also want to minim= ize the amount of inter-organizational coordination required. What if sending an encrypted email required clients to contact an email key= gatekeeper (EKG)? The EKG issues one-time-use encryption keys to authorize= d senders, and releases the decryption key once (only) to each recipient. Detailed flow: When encryption is desired, the sender's email client formats a key request= to the EKG and signs it using the sender's email signing key. The key requ= est includes the recipient's email addresses, but not their public keys, wh= ich are unknown. If the EKG is configured to recognize the sender, it repli= es with: 1] an encryption key, encrypted with the sender's public email sig= ning key; and 2] a plaintext copy of the key request, signed by the EKG its= elf. The sender then decrypts the encryption key, encrypts the message and = attachments, and attaches the signed key request. Poof. The message is sent= . If the sender's client stores outgoing mail in a "sent mail" folder, the = stored copy must be encrypted using some other means. The EKG-signed key request includes: 1] a unique identifier for the encrypt= ion key; 2] contact info, so recipients can locate the EKG; and 3] of cours= e, the list of recipients (part of the original key request). The Sender's organization can decrypt the outbound email at a gateway by co= ntacting the EKG and retrieving the decryption key (which could be the same= as the encryption key if symmetric, or the other half of an asymmetric key= pair if not.) The recipient's organization (assuming different than sender's organization= ) cannot decrypt the inbound email at a gateway. The recipient's email client detects the EKG's signed key request attached = to the email. The EKG's signature is verified. The recipient's client uses = the recipient's email signing cert to sign the EKG-signed key request, and = sends to the EKG using the contact information provided. The EKG verifies the recipients' signature. The EKG verifies that the recip= ient's certificate contains an email address that is included as a recipien= t in the original key request. The EKG verifies its own signature. The EKG = encrypts the email's decryption key using the recipient's public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments. If the message is to be stored, it must be re-encrypted in a locally recove= rable fashion, likely with the recipient's credentials. If the recipient's = organization is concerned about decrypting inbound email, the "locally reco= verable fashion" should allow authorized individuals/services access. The o= riginal ciphertext should not be stored after decryption, and the decryptio= n key must not be stored. Probably best not to get too psycho over this: th= e recipient can always cut and paste to some cleartext medium like word, or= take a screenshot. Reasonable assurance that clients keep things encrypted= when they're received encrypted is what we're after. The EKG keeps track of which recipients have requested the decryption key. = Recipients are allowed to request the key once and only once. When all reci= pients have requested the decryption key, that key must never be served out= again. The EKG should not re-use encryption keys for subsequent messages. Clearly, the EKG needs to be just as publicly available as the organization= 's mailserver. I do not believe there would need to be anything special in = DNS (no "EKG" records, etc.) To summarize: The EKG knows nothing about sen= ders or recipients other than what the certificates tell it. Encryption key= s for email messages are one-time-use, and shared among sender and all reci= pients. Recipients get decryption keys by having a certificate with a match= ing email address. No extra coordination is involved over and above the con= figuration necessary to verify email signatures. What do you think? Is there an obvious reason this hasn't been done before? Bryce --_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3001FSN2MPN1046001_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is a “what if” message, centered ar= ound trying to make email encryption as painless as email signing. I want t= o be able to encrypt an email message once, no matter how many recipients t= here are. An enterprise should be able to decrypt employees’ email to ensure there’s no misbehavior. I want as l= ittle “extra” supporting infrastructure as possible. I also wan= t to minimize the amount of inter-organizational coordination required.

 

What if sending an encrypted email required clients = to contact an email key gatekeeper (EKG)? The EKG issues one-time-use encry= ption keys to authorized senders, and releases the decryption key once (onl= y) to each recipient.

 

Detailed flow:

 

When encryption is desired, the sender’s email= client formats a key request to the EKG and signs it using the sender̵= 7;s email signing key. The key request includes the recipient’s email= addresses, but not their public keys, which are unknown. If the EKG is configured to recognize the sender, it replies with: 1] an e= ncryption key, encrypted with the sender’s public email signing key; = and 2] a plaintext copy of the key request, signed by the EKG itself. The s= ender then decrypts the encryption key, encrypts the message and attachments, and attaches the signed key request.= Poof. The message is sent. If the sender’s client stores outgoing ma= il in a “sent mail” folder, the stored copy must be encrypted u= sing some other means.

 

The EKG-signed key request includes: 1] a unique ide= ntifier for the encryption key; 2] contact info, so recipients can locate t= he EKG; and 3] of course, the list of recipients (part of the original key = request).

 

The Sender’s organization can decrypt the outb= ound email at a gateway by contacting the EKG and retrieving the decryption= key (which could be the same as the encryption key if symmetric, or the ot= her half of an asymmetric keypair if not.)

 

The recipient’s organization (assuming differe= nt than sender’s organization) cannot decrypt the inbound email at a = gateway.

 

The recipient’s email client detects the EKG&#= 8217;s signed key request attached to the email. The EKG’s signature = is verified. The recipient’s client uses the recipient’s email = signing cert to sign the EKG-signed key request, and sends to the EKG using the contact information provided.

 

The EKG verifies the recipients’ signature. Th= e EKG verifies that the recipient’s certificate contains an email add= ress that is included as a recipient in the original key request. The EKG v= erifies its own signature. The EKG encrypts the email’s decryption key using the recipient’s public email sign= ing key, and signs the response. The recipient verifies the signature (ensu= ring same EKG signed key request and decryption key request) and decrypts t= he message/attachments.

 

If the message is to be stored, it must be re-encryp= ted in a locally recoverable fashion, likely with the recipient’s cre= dentials. If the recipient’s organization is concerned about decrypti= ng inbound email, the “locally recoverable fashion” should allow authorized individuals/services access. The original cipherte= xt should not be stored after decryption, and the decryption key must not b= e stored. Probably best not to get too psycho over this: the recipient can = always cut and paste to some cleartext medium like word, or take a screenshot. Reasonable assurance that clients = keep things encrypted when they’re received encrypted is what we̵= 7;re after.

 

The EKG keeps track of which recipients have request= ed the decryption key. Recipients are allowed to request the key once and o= nly once. When all recipients have requested the decryption key, that key m= ust never be served out again. The EKG should not re-use encryption keys for subsequent messages.<= /p>

 

Clearly, the EKG needs to be just as publicly availa= ble as the organization’s mailserver. I do not believe there would ne= ed to be anything special in DNS (no “EKG” records, etc.) To su= mmarize:  The EKG knows nothing about senders or recipients other than what the certificates tell it. Encryption keys for email messag= es are one-time-use, and shared among sender and all recipients. Recipients= get decryption keys by having a certificate with a matching email address.= No extra coordination is involved over and above the configuration necessary to verify email signatures.

 

What do you think? Is there an obvious reason this h= asn’t been done before?

 

Bryce

--_000_82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3001FSN2MPN1046001_-- From nobody Fri May 29 17:17:06 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 809F51AC3AB for ; Fri, 29 May 2015 17:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZqH2MGb1FFM for ; Fri, 29 May 2015 17:17:03 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4531AC3A7 for ; Fri, 29 May 2015 17:17:03 -0700 (PDT) X-AuditID: 12074423-f79496d000000d43-16-5569017e1514 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id F3.B0.03395.E7109655; Fri, 29 May 2015 20:17:02 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t4U0H1TB029516; Fri, 29 May 2015 20:17:02 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t4U0Gx7o024162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 29 May 2015 20:17:01 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t4U0GxnY023055; Fri, 29 May 2015 20:16:59 -0400 (EDT) Date: Fri, 29 May 2015 20:16:59 -0400 (EDT) From: Benjamin Kaduk To: "Nordgren, Bryce L -FS" In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> Message-ID: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrlvHmBlqcPG7lsXVNz9ZLY5uXsXi wORx+81ZFo8lS34yBTBFcdmkpOZklqUW6dslcGXs2dLKXrCVveLKH94Gxha2LkZODgkBE4mO V43sELaYxIV764HiXBxCAouZJNYtf8oIkhAS2MgoMfWMJUTiEJPEogUtTBBOA6PEpb5HQO0c HCwC2hI/mzNBGtgEVCRmvtkItkFEwFCie+kxsEHMAuoS3868AbOFBcwkXj9rAqvhFIiQ2P2i jxnE5hVwlFjbfYoNYnG4xN+tS5lAbFEBHYnV+6ewQNQISpyc+YQFYqaWxPLp21gmMArOQpKa hSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6ZXm5miV5qSukmRnCYuijvYPxzUOkQowAH oxIPr8G19FAh1sSy4srcQ4ySHExKory7v2WECvEl5adUZiQWZ8QXleakFh9ilOBgVhLh9X8E lONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuDlZsgMFRIsSk1PrUjL zClBSDNxcIIM5wEaPhOkhre4IDG3ODMdIn+KUZfjzpT/i5iEWPLy81KlxHlzQYoEQIoySvPg 5sDSyytGcaC3hHmtQap4gKkJbtIroCVMQEu+K4J8UFySiJCSamA0rpu3rf6q9tZfuz75Rc+u YChdtLLf/sV9lht1Vyf61dYGcRa1hFcGrVjp/szaNpM5ozzuR+vuNd9//X3uGerZs+uHcHJI iOuZiiCuINuNtW+PS3EsS943SdnFJOL7NMuXj7ItChfW3bykepn/7vXPzj/2zW/kDDmlWcer +2uvufk8k0tiWT5KLMUZiYZazEXFiQD1rKF4CgMAAA== Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Group/Enterprise encrypted email X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 00:17:05 -0000 Hi Bryce, On Fri, 29 May 2015, Nordgren, Bryce L -FS wrote: > This is a "what if" message, centered around trying to make email > encryption as painless as email signing. I want to be able to encrypt an > email message once, no matter how many recipients there are. An > enterprise should be able to decrypt employees' email to ensure there's > no misbehavior. I want as little "extra" supporting infrastructure as > possible. I also want to minimize the amount of inter-organizational > coordination required. You might have better luck on the endymail list, which is considering ways to improve email privacy. I don't recall whether a scheme substantially similar to your proposal has been discussed there, but there should be a good crop of people interested in improving the state of email to comment there. The endymail list was kicked off at http://www.ietf.org/mail-archive/web/endymail/current/msg00000.html -Ben From nobody Fri May 29 18:51:37 2015 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7161ACC86 for ; Fri, 29 May 2015 18:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.357 X-Spam-Level: X-Spam-Status: No, score=0.357 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sP7210rQPgfi for ; Fri, 29 May 2015 18:51:35 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E11A8AB1 for ; Fri, 29 May 2015 18:51:35 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 838D82005D82E for ; Fri, 29 May 2015 18:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=8T7fa7dQadST6zRtn9un H9fXKKA=; b=LT/ieUdTNr39oqxnEwA+BPFOv3J7qVmf2y/nycVSW0nH2dP5RseR BZCcJyFXMwP7Ex3oJp+t1VS72HP6QWpYYJUzkyVSy/jgdJsswpnJl9zM/VOPpDkm v0PEgXpWyM5JkmLQjfg2pi29fLH+BNGEv+sOlBSE6JMnctXoNGMCPuk= Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id 742BC2005D82D for ; Fri, 29 May 2015 18:51:35 -0700 (PDT) Received: by yked142 with SMTP id d142so27531085yke.3 for ; Fri, 29 May 2015 18:51:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.53.8 with SMTP id f8mr11433214yhc.99.1432950695128; Fri, 29 May 2015 18:51:35 -0700 (PDT) Received: by 10.13.253.3 with HTTP; Fri, 29 May 2015 18:51:35 -0700 (PDT) In-Reply-To: References: <82E7C9A01FD0764CACDD35D10F5DFB6E7DF8C3@001FSN2MPN1-046.001f.mgd2.msft.net> Date: Fri, 29 May 2015 20:51:35 -0500 Message-ID: From: Nico Williams To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=089e0122f0d229f7ae051742d534 Archived-At: Cc: "kitten@ietf.org" Subject: Re: [kitten] Group/Enterprise encrypted email X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 May 2015 01:51:36 -0000 --089e0122f0d229f7ae051742d534 Content-Type: text/plain; charset=UTF-8 Identity-based encryption (IBE) comes to mind. --089e0122f0d229f7ae051742d534 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Identity-based encryption (IBE) comes=C2=A0to mind. --089e0122f0d229f7ae051742d534--