From nobody Thu Feb 1 05:59:06 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 781F712EADA for ; Thu, 1 Feb 2018 05:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 QQUGhsTbweiK for ; Thu, 1 Feb 2018 05:59:04 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A810112EAC6 for ; Thu, 1 Feb 2018 05:59:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 506C829A4A; Thu, 1 Feb 2018 08:59:03 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoJW5Rdt1z0C; Thu, 1 Feb 2018 08:59:01 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-174-63-85-75.hsd1.ma.comcast.net [174.63.85.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA; Thu, 1 Feb 2018 08:59:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E1ACBC4A0F; Thu, 1 Feb 2018 08:58:59 -0500 (EST) From: Sam Hartman To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> Date: Thu, 01 Feb 2018 08:58:59 -0500 In-Reply-To: <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> (Greg Hudson's message of "Wed, 31 Jan 2018 16:40:56 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [kitten] pa-hints in draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 13:59:05 -0000 Yesterday I also discussed my RFC 6113 alignment concerns with Greg. If I were more involved in implementing Kerberos, I probably would be arguing for a somewhat different approach--focusing on less duplication of facilities provided in RFC 6113. However, Greg reviewed the history, and I have confidence that the issues I'm thinking about were considhered by those involved in the design of the proposal. So with one exception, with regard to RFc 6113 alignment I believe my concerns have already been considered and rejected. I brought up one issue that I don't think has been adequately considered: the decision not to include a pa-hint in this proposal. Under RFC 6113, the preauthentication types that participate in a preauthentication set are permitted to include a hint in the first message. The intent is for a client to know whether it has the necessary facilities (CAs, algorithm support, access to appropriate tokens, etc) in order to succeed at using a preauthentication set before starting. We're trying to avoid the following: * A KDC proposes an authentication set with SPAKE as the second element * The first member of that authentication set requires user interaction. So the client interacts with the user. * Then the client discovers that it doesn't share a group in common with the KDC. The intent of RFC 6113 is that a client know what user interaction will be required and whether it has the necessary support prior to starting an authentication set. I don't think SPAKE meets this intent. There are mechanisms prior to RFC 6113 that also don't provide this facility. However, I think it would be relatively easy to define a hint message including the set of groups the KDC supports to work in this case. I realize that in the current draft, group offers are always sent from the client to the KDC. I note that beyond a relatively small specification complexity burden (defining a message similar to an existing message), the complexity burden of sometimes getting groups from the KDC would only be suffered by implementations that use SPAKE in authentication sets. From nobody Thu Feb 1 06:10:49 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71B9C13166B for ; Thu, 1 Feb 2018 06:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 GlRsyRewcjzc for ; Thu, 1 Feb 2018 06:10:40 -0800 (PST) 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 62C601317A1 for ; Thu, 1 Feb 2018 06:10:13 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 22960A34B8; Thu, 1 Feb 2018 14:10:13 +0000 (UTC) Received: from ovpn-117-243.phx2.redhat.com (ovpn-117-243.phx2.redhat.com [10.3.117.243]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AC32C6B43C; Thu, 1 Feb 2018 14:10:12 +0000 (UTC) Message-ID: <1517494211.13097.121.camel@redhat.com> From: Simo Sorce To: Greg Hudson , Sam Hartman Cc: kitten@ietf.org Date: Thu, 01 Feb 2018 09:10:11 -0500 In-Reply-To: References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 01 Feb 2018 14:10:13 +0000 (UTC) Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 14:10:47 -0000 On Wed, 2018-01-31 at 17:56 -0500, Greg Hudson wrote: > On 01/31/2018 05:10 PM, Simo Sorce wrote:>> 2. Choose the hash based > on the enctype [...] > > > The one concern here is, what happen if the hash function turns out to > > be broken down the line ? > > How would new and old code negotiate what hash to use ? > > > > Or is the thinking that we'd add new enctypes if the hash function is > > broken anyway so new enctypes will be mapped to this new hash function > > ? > > We would have to migrate to a new enctype to change the hash function we > use in SPAKE. That's a high cost in some scenarios--like if someone > discovers a horrible preimage attack on SHA-256, but SHA-1 still appears > as preimage-resistant as it does today, so that aes-sha1 still seems > like a decent enctype to use for every purpose other than SPAKE. But I > think those scenarios are vanishingly unlikely. > > > What happens when a new enctype is introduced ? Will there have to be > > also an explicit allocation of a hash type to be use for SPAKE? > > Will it be implicit ? At least SHA-256 or whatever the enctype uses if > > "better" ? > > When a new enctype is defined, we would also have to populate its entry > in the SPAKE mapping of enctype to hash function (which could be an IANA > registry). If there's no mapping for an enctype then that enctype can't > be used with SPAKE. But it should be easy to update the SPAKE > enctype-to-hash registry in the same document as we define a new enctype. It is a bit annoying to have to do this for each new enctype ... just for a pre-auth mechanism. I wonder if we couldn't simply add a field in the first message that specifies the hash we are using. The server can then just refuse operations if it doesn't want to use the hash the client selected. This would allow smooths transitions from "current-hash" to "new-hash" in case current hash is not totally broken right away, but like SHA-1 gets weaker and weaker and we plan replacement. It would mean potentially allowing clients to use a new enctype with a keysize longer than the current hash, but I would assume we would add a new hash option as that enctype is introduced and clients would do the same. The server can simply refuse the older hash type with newer enctypes, while still allowing older hash with older enctypes for clients that have not caught up. I do not know if this is desirable or can pose issues (downgrade attacks ?), but I thought mentioning it as an option, to have a possibility for a smoother transition in future. > There is the option of specifying "SHA-256 as long as the key size is <= > 256 bits unless there's an explicit mapping," but that option runs a > serious interoperability risk--one party might use the SHA-256 default > (through negligence or some time window between the enctype assignment > and the SPAKE mapping update) while the other party uses a different, > explicitly specified hash function. Indeed, I wouldn't do this without the option I mention above. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Thu Feb 1 08:45:11 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6124412EB68 for ; Thu, 1 Feb 2018 08:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 3t7lVZ4zgCQY for ; Thu, 1 Feb 2018 08:45:08 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C43FA12EB5A for ; Thu, 1 Feb 2018 08:45:07 -0800 (PST) X-AuditID: 1209190d-95dff70000007853-f6-5a734412f245 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-2.mit.edu (Symantec Messaging Gateway) with SMTP id 83.B9.30803.214437A5; Thu, 1 Feb 2018 11:45:06 -0500 (EST) 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 w11Gj4Xc000976; Thu, 1 Feb 2018 11:45:05 -0500 Received: from [18.101.8.163] (VPN-18-101-8-163.MIT.EDU [18.101.8.163]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w11Gj2km027376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 1 Feb 2018 11:45:04 -0500 To: Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> From: Greg Hudson Message-ID: <73c68e5e-f8b0-23ce-56b2-d97136da035e@mit.edu> Date: Thu, 1 Feb 2018 11:45:02 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrCvkUhxlcGG3usXXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDJuLjnAVjCFo+LDlOfsDYzn2boYOTkkBEwk nn04wN7FyMUhJLCYSaKx8wwjhLOBUWL2g6tQzhEmiS1dH1hBWoQFPCQ+3X4A1i4ioC6x+tIk dhCbWUBYYvmas2wQDdcZJbbf3McEkmATUJZYv38rC4jNK2AlMaNjCdggFgEVid7Gg2CDRAUi JJpmzmWFqBGUODnzCVA9BwengIFE6zxOiPnqEn/mXWKGsMUlbj2ZzwRhy0tsfzuHeQKj4Cwk 3bOQtMxC0jILScsCRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYwaEtybuD 8d9dr0OMAhyMSjy8HNLFUUKsiWXFlbmHGCU5mJREeTudgUJ8SfkplRmJxRnxRaU5qcWHGCU4 mJVEeN/sK4oS4k1JrKxKLcqHSUlzsCiJ87qbaEcJCaQnlqRmp6YWpBbBZGU4OJQkeDNBhgoW paanVqRl5pQgpJk4OEGG8wANrwKp4S0uSMwtzkyHyJ9i1OW48eJ1G7MQS15+XqqUOO8FJ6Ai AZCijNI8uDnglJTKsfgVozjQW8K820CqeIDpDG7SK6AlTEBLfmYXgiwpSURISTUwavVqPT9/ NUp24Yx1jf5v3k4qOX1n/q4vz5+0/Cxfxe5w7LXB5bLT8krJxf2iXQsV/QVq5hx7s36K5e2w k1vCZO4e9tTasuGM8oHN8149nr/KRdf5oMx5k9MzFG74PBWTd/DVYZy+5ULGMvPzk+bXF//Z fUlWPrZ000K1K45JqX51T1PY5K6EVCuxFGckGmoxFxUnAgCPsTStJAMAAA== Archived-At: Subject: Re: [kitten] pa-hints in draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 16:45:09 -0000 On 02/01/2018 08:58 AM, Sam Hartman wrote: > I brought up one issue that I don't think has been adequately > considered: the decision not to include a pa-hint in this proposal. [...] > I note that beyond a relatively small specification complexity burden > (defining a message similar to an existing message), the complexity > burden of sometimes getting groups from the KDC would only be suffered > by implementations that use SPAKE in authentication sets. I think we can just reuse SPAKESupport, so this should be easy to specify. And yes, a KDC or client which doesn't implement authentication sets doesn't have to do anything. I can write up the text. My inclination is to specify that the pa-hint should not affect the transcript, since it occurs in an earlier phase of operation (authentication set selection), and including it in the transcript would make life harder for the KDC. The client will send its own SPAKESupport message once SPAKE preauth beginsw, and that message will be included in the transcript. From nobody Thu Feb 1 09:17:50 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE06012D889 for ; Thu, 1 Feb 2018 09:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 9fCWjudpyIXo for ; Thu, 1 Feb 2018 09:17:48 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 272CF126BF6 for ; Thu, 1 Feb 2018 09:17:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id 620F129A61; Thu, 1 Feb 2018 12:17:47 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfmQSN5gghVK; Thu, 1 Feb 2018 12:17:47 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-174-63-85-75.hsd1.ma.comcast.net [174.63.85.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA; Thu, 1 Feb 2018 12:17:47 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 79EFAC4A0F; Thu, 1 Feb 2018 12:17:45 -0500 (EST) From: Sam Hartman To: Simo Sorce Cc: Greg Hudson , Sam Hartman , kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> Date: Thu, 01 Feb 2018 12:17:45 -0500 In-Reply-To: <1517494211.13097.121.camel@redhat.com> (Simo Sorce's message of "Thu, 01 Feb 2018 09:10:11 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 17:17:49 -0000 >>>>> "Simo" == Simo Sorce writes: Simo> It is a bit annoying to have to do this for each new enctype Simo> ... just for a pre-auth mechanism. I wonder if we couldn't Simo> simply add a field in the first message that specifies the Simo> hash we are using. The server can then just refuse operations Simo> if it doesn't want to use the hash the client selected. This Simo> would allow smooths transitions from "current-hash" to Simo> "new-hash" in case current hash is not totally broken right Simo> away, but like SHA-1 gets weaker and weaker and we plan Simo> replacement. I think that the idea of combining the hash definition with the group definition is about the same as this, only a bit simpler. My ranked options are: * Combine choice of hash with choice of group (Kerberos SPAKE groups include a hash function in their definition). Requires changing the spec to restart the hash when a KDC rejects an optimistic group offer. Greg and I believe the security of this is fine. * Registering a mapping of SPAKE hashes to enctypes. The major advantage I see is that it can (I think) maintain interop with the existing protocol. The down side is that in some cases you might have to register a new enctype or except a non-ideal SPAKE hash. * Use the PRF. I think that while the concerns are real, the security is fine * Your proposal of hash in first message * Get sufficient review and make RFC 3961 hashes deterministic * Find other options * Give up on SPAKE From nobody Thu Feb 1 11:11:43 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D07E312EC73 for ; Thu, 1 Feb 2018 11:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.911 X-Spam-Level: X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 ufACCff--1sB for ; Thu, 1 Feb 2018 11:11:41 -0800 (PST) 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 066E112EC44 for ; Thu, 1 Feb 2018 11:11:41 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BAB367854C; Thu, 1 Feb 2018 19:11:40 +0000 (UTC) Received: from ovpn-117-243.phx2.redhat.com (ovpn-117-243.phx2.redhat.com [10.3.117.243]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5475B60A9A; Thu, 1 Feb 2018 19:11:40 +0000 (UTC) Message-ID: <1517512299.13097.135.camel@redhat.com> From: Simo Sorce To: Sam Hartman Cc: kitten@ietf.org Date: Thu, 01 Feb 2018 14:11:39 -0500 In-Reply-To: References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> Organization: Red Hat, Inc. Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Thu, 01 Feb 2018 19:11:40 +0000 (UTC) Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:11:43 -0000 On Thu, 2018-02-01 at 12:17 -0500, Sam Hartman wrote: > > > > > > "Simo" == Simo Sorce writes: > > Simo> It is a bit annoying to have to do this for each new enctype > Simo> ... just for a pre-auth mechanism. I wonder if we couldn't > Simo> simply add a field in the first message that specifies the > Simo> hash we are using. The server can then just refuse operations > Simo> if it doesn't want to use the hash the client selected. This > Simo> would allow smooths transitions from "current-hash" to > Simo> "new-hash" in case current hash is not totally broken right > Simo> away, but like SHA-1 gets weaker and weaker and we plan > Simo> replacement. > > I think that the idea of combining the hash definition with the group > definition is about the same as this, only a bit simpler. > > My ranked options are: > > * Combine choice of hash with choice of group (Kerberos SPAKE groups > include a hash function in their definition). Requires changing the > spec to restart the hash when a KDC rejects an optimistic group > offer. Greg and I believe the security of this is fine. > > * Registering a mapping of SPAKE hashes to enctypes. The major > advantage I see is that it can (I think) maintain interop with the > existing protocol. The down side is that in some cases you might have > to register a new enctype or except a non-ideal SPAKE hash. > > * Use the PRF. I think that while the concerns are real, the security > is fine > > * Your proposal of hash in first message I think the above options are all fine by me, maybe not in the same exact order, but they all work. > * Get sufficient review and make RFC 3961 hashes deterministic > > * Find other options > > * Give up on SPAKE I'd rather not go into the last three, but I am open to other options that have substantial advantages and no big downside compared to the first 4 on the table that it is worth spending time on them. Simo. -- Simo Sorce Sr. Principal Software Engineer Red Hat, Inc From nobody Thu Feb 1 12:16:08 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B8F12D84E for ; Thu, 1 Feb 2018 12:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 fF06uf28A3E6 for ; Thu, 1 Feb 2018 12:16:00 -0800 (PST) Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com [209.85.218.66]) (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 6C7C812D77B for ; Thu, 1 Feb 2018 12:16:00 -0800 (PST) Received: by mail-oi0-f66.google.com with SMTP id j188so12953831oib.6 for ; Thu, 01 Feb 2018 12:16:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qn5flZbohISK20oTDpi/wLPNy32Q/W9mYKogpaqtGUI=; b=rE1cTT8vVEXhYcNzHsLudShzdZRbulz75TyKUgaaTGWnJDi7z0fG4jauJE0eRpKOfm jptQWQshQr/RDiZzG1xyFfgtxrMH/73VM30fDg9MSk/oqyVmVZQe8cc/6RISkE6JYpQ/ S/ZhY9fR5rWhVeZU+jlB+AZTatMY/bfY2h+P8UujBrYxknngC9rIxq4agI3e4CIhnkdf JGl8MUA8xFdm3613SbZGovtsGSF/aL4H7JkNScnaD9d6LcShAxKnbayfGgERHoW6PnTJ Hx8k4AkVDolxWiRyvVZOCJqby6pai7Ga7Nk7ALQ67Wu9t9wsLNYTlltmpUQh+N0oDI0x f64g== X-Gm-Message-State: AKwxyteW6AKOnDYdWN599Y1wGen0i3346q1p1HgO69hkR40nhMxYlMHZ cteE4SBetUfuA+I+hUfnceakjiFdVF6jlhwvZLb/Dg== X-Google-Smtp-Source: AH8x2279FYT74nTbd1sik/9eQANlPlR6vLtsuG0UHgbMd1PCqsBbSYZ1i/2iTs8XUQL1W5VGZyZJHZ11T8rZ3bCBrT4= X-Received: by 10.202.180.133 with SMTP id d127mr25965801oif.328.1517516159544; Thu, 01 Feb 2018 12:15:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Thu, 1 Feb 2018 12:15:58 -0800 (PST) In-Reply-To: <1517512299.13097.135.camel@redhat.com> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <1517512299.13097.135.camel@redhat.com> From: Nathaniel McCallum Date: Thu, 1 Feb 2018 15:15:58 -0500 Message-ID: To: Simo Sorce Cc: Sam Hartman , kitten@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:16:07 -0000 I agree with Simo. The first two options are probably the best. I don't have a strong opinion between them. However, I suspect that we aren't worried about compatibility at this point (nobody ships this). On Thu, Feb 1, 2018 at 2:11 PM, Simo Sorce wrote: > On Thu, 2018-02-01 at 12:17 -0500, Sam Hartman wrote: >> > > > > > "Simo" == Simo Sorce writes: >> >> Simo> It is a bit annoying to have to do this for each new enctype >> Simo> ... just for a pre-auth mechanism. I wonder if we couldn't >> Simo> simply add a field in the first message that specifies the >> Simo> hash we are using. The server can then just refuse operations >> Simo> if it doesn't want to use the hash the client selected. This >> Simo> would allow smooths transitions from "current-hash" to >> Simo> "new-hash" in case current hash is not totally broken right >> Simo> away, but like SHA-1 gets weaker and weaker and we plan >> Simo> replacement. >> >> I think that the idea of combining the hash definition with the group >> definition is about the same as this, only a bit simpler. >> >> My ranked options are: >> >> * Combine choice of hash with choice of group (Kerberos SPAKE groups >> include a hash function in their definition). Requires changing the >> spec to restart the hash when a KDC rejects an optimistic group >> offer. Greg and I believe the security of this is fine. >> >> * Registering a mapping of SPAKE hashes to enctypes. The major >> advantage I see is that it can (I think) maintain interop with the >> existing protocol. The down side is that in some cases you might have >> to register a new enctype or except a non-ideal SPAKE hash. >> >> * Use the PRF. I think that while the concerns are real, the security >> is fine >> >> * Your proposal of hash in first message > > I think the above options are all fine by me, maybe not in the same > exact order, but they all work. > >> * Get sufficient review and make RFC 3961 hashes deterministic >> >> * Find other options >> >> * Give up on SPAKE > > I'd rather not go into the last three, but I am open to other options > that have substantial advantages and no big downside compared to the > first 4 on the table that it is worth spending time on them. > > Simo. > > -- > Simo Sorce > Sr. Principal Software Engineer > Red Hat, Inc > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Feb 1 12:27:44 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C3F12EAAD for ; Thu, 1 Feb 2018 12:27:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 pkumg5EgNpDd for ; Thu, 1 Feb 2018 12:27:41 -0800 (PST) Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65]) (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 831781243FE for ; Thu, 1 Feb 2018 12:27:41 -0800 (PST) Received: by mail-oi0-f65.google.com with SMTP id e15so4277500oiy.2 for ; Thu, 01 Feb 2018 12:27:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NeJtWFuvMInyqQJt5HgL3Xy6dMDdSPTHhJJR/vT+o0I=; b=TBZEoKbr7IP56MXi4SJ6PnZCXp3c8e0ENHO9BTjRuR3k5HbYplyGcoPvYgZdrO5y0b Ay5AckCoaZmJHeBUG4Rw20AnkkxDN+R2zf9UvogEX5GR8Nx2z5LGRgf0TycpKKspxYDk Y2I6LuogVpc/aiJv3pW36r96rcaWnukuVWeo9mOKTNCFjOg70utE4Oevg/4wBbyqtfM0 I02wGxQJmcarr8YcHpxpKkSg5nWCoV2i3ndglSHtpGmk0w/3D63jLpUT4u2RTwB3+CXY Z16dAEBq1NVfXWCEGMTNLlRST675C2SHslgOM/L4dbQaV+CJRBlUv3SR49w81gZqZYkB acAg== X-Gm-Message-State: AKwxytegQVzVh9uJ+DZbfG7CD/eGpovIwvdcFNwR4RrlixVVZXasqWqp nz+dgccRIGvbsLnRdlDsNGNm994cb4de+RHUUdMJAg== X-Google-Smtp-Source: AH8x227qyHR5L4mwHW4tYWZKNO7AgxnGNptqnAUpOPMPB04mhw30XPMJImwmsuY4VM5Rqxun7IviZdMiSBv1qsLoW54= X-Received: by 10.202.253.150 with SMTP id b144mr12230908oii.81.1517516860684; Thu, 01 Feb 2018 12:27:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Thu, 1 Feb 2018 12:27:40 -0800 (PST) In-Reply-To: <73c68e5e-f8b0-23ce-56b2-d97136da035e@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <73c68e5e-f8b0-23ce-56b2-d97136da035e@mit.edu> From: Nathaniel McCallum Date: Thu, 1 Feb 2018 15:27:40 -0500 Message-ID: To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [kitten] pa-hints in draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:27:43 -0000 If we reuse SPAKESupport, then we can never differentiate between the client and server messages. I'm not objecting, just noting. On Thu, Feb 1, 2018 at 11:45 AM, Greg Hudson wrote: > On 02/01/2018 08:58 AM, Sam Hartman wrote: >> I brought up one issue that I don't think has been adequately >> considered: the decision not to include a pa-hint in this proposal. > [...] >> I note that beyond a relatively small specification complexity burden >> (defining a message similar to an existing message), the complexity >> burden of sometimes getting groups from the KDC would only be suffered >> by implementations that use SPAKE in authentication sets. > > I think we can just reuse SPAKESupport, so this should be easy to > specify. And yes, a KDC or client which doesn't implement > authentication sets doesn't have to do anything. I can write up the text. > > My inclination is to specify that the pa-hint should not affect the > transcript, since it occurs in an earlier phase of operation > (authentication set selection), and including it in the transcript would > make life harder for the KDC. The client will send its own SPAKESupport > message once SPAKE preauth beginsw, and that message will be included in > the transcript. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Feb 1 20:06:27 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FCC127342 for ; Thu, 1 Feb 2018 20:06:26 -0800 (PST) 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 autolearn_force=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 f0key0j19AMT for ; Thu, 1 Feb 2018 20:06:24 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 B7BDD127136 for ; Thu, 1 Feb 2018 20:06:24 -0800 (PST) X-AuditID: 1209190c-b9fff70000001142-cb-5a73e3bfe016 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 55.66.04418.FB3E37A5; Thu, 1 Feb 2018 23:06:23 -0500 (EST) 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 w1246LtG029042; Thu, 1 Feb 2018 23:06:22 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1246IFH018672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 1 Feb 2018 23:06:20 -0500 Date: Thu, 1 Feb 2018 22:06:18 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org Message-ID: <20180202040617.GB12363@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <73c68e5e-f8b0-23ce-56b2-d97136da035e@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <73c68e5e-f8b0-23ce-56b2-d97136da035e@mit.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrbv/cXGUwarvehZf2x6wWRzdvIrF gcljyZKfTB4rp55mD2CK4rJJSc3JLEst0rdL4Mp4cECiYC5XxaR/Bg2M0zm6GDk5JARMJFbM ucPYxcjFISSwmEli6/QLrCAJIYENjBLzX5lCJM4wSdz49JYNJMEioCLx499GJhCbDchu6L7M DGKLCChKPFs1lwXEZhawkLi/dyojiC0s4CHx6fYDsF5eAR2JlcvfAcU5gIZ2MEksMYEIC0qc nPkEqlVL4sa/l0wgJcwC0hLL/4HdySlgLTF73zewTaICyhJ7+w6xT2AUmIWkexaS7lkI3QsY mVcxyqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEh6ckzw7GM2+8DjEKcDAq8fBy SBdHCbEmlhVX5h5ilORgUhLl9X8AFOJLyk+pzEgszogvKs1JLT7EKMHBrCTC+3UDUI43JbGy KrUoHyYlzcGiJM7rbqIdJSSQnliSmp2aWpBaBJOV4eBQkuDd9gioUbAoNT21Ii0zpwQhzcTB CTKcB2g472OQ4cUFibnFmekQ+VOMuhw3XrxuYxZiycvPS5US5/0MMkgApCijNA9uDiitSGTv r3nFKA70ljCvGMgoHmBKgpv0CmgJE9CSn9mFIEtKEhFSUg2MSksvtvfGrzhrGcbgFhPIaH05 XIzh9FP7Jzt7+z98eh8kMlvrlLZ9/UYRlh2B1zTDz/zg/yPhuOL7rbaN69Ka22Ous7k7Hq96 qc3fPjff3vRG05xZjiVSVTeOK7OubPu0O/TbnZ0vXR5Pdk3tOMgx94upQN+L/lfV1a8ju/6b bXSs0XLJCvqgxFKckWioxVxUnAgAbWQziQYDAAA= Archived-At: Subject: Re: [kitten] pa-hints in draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 04:06:26 -0000 On Thu, Feb 01, 2018 at 11:45:02AM -0500, Greg Hudson wrote: > On 02/01/2018 08:58 AM, Sam Hartman wrote: > > I brought up one issue that I don't think has been adequately > > considered: the decision not to include a pa-hint in this proposal. > [...] > > I note that beyond a relatively small specification complexity burden > > (defining a message similar to an existing message), the complexity > > burden of sometimes getting groups from the KDC would only be suffered > > by implementations that use SPAKE in authentication sets. > > I think we can just reuse SPAKESupport, so this should be easy to > specify. And yes, a KDC or client which doesn't implement > authentication sets doesn't have to do anything. I can write up the text. > > My inclination is to specify that the pa-hint should not affect the > transcript, since it occurs in an earlier phase of operation > (authentication set selection), and including it in the transcript would > make life harder for the KDC. The client will send its own SPAKESupport > message once SPAKE preauth beginsw, and that message will be included in > the transcript. This is probably fine, and we can reiterate in the security considerations that the hints are just hints (i.e., not authoritative), and could be wrong. -Ben From nobody Sat Feb 3 10:19:25 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A45A12D890 for ; Sat, 3 Feb 2018 10:19:23 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 95XAYKy__-fi for ; Sat, 3 Feb 2018 10:19:21 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 B01531270AE for ; Sat, 3 Feb 2018 10:19:21 -0800 (PST) X-AuditID: 1209190e-6e5ff70000004af1-31-5a75fd2862e2 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 F0.74.19185.82DF57A5; Sat, 3 Feb 2018 13:19:20 -0500 (EST) 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 w13IJJp7019245; Sat, 3 Feb 2018 13:19:19 -0500 Received: from [18.101.8.68] (VPN-18-101-8-68.MIT.EDU [18.101.8.68]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w13IJGOD020383 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 Feb 2018 13:19:18 -0500 To: Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> From: Greg Hudson Message-ID: <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> Date: Sat, 3 Feb 2018 13:19:16 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1tX4WxplcHmlisXXtgdsFkc3r2Jx YPJYsuQnk8fKqafZA5iiuGxSUnMyy1KL9O0SuDIOHp3AXvBZoKJr/hmWBsZtvF2MnBwSAiYS xzY2sHUxcnEICSxmkpjwcwM7SEJIYAOjxJqHfhD2QSaJ65cVQWxhgVqJV8cPg9WICKhLrL40 CcxmFhCWWL7mLBtE/XUmiZefPUBsNgFlifX7t7KA2LwCVhKTz09kBLFZBFQk9py9AdYrKhAh 0TRzLitEjaDEyZlPwOo5BXQlZq85zQYxX13iz7xLzBC2uMStJ/OZIGx5ie1v5zBPYBSchaR9 FpKWWUhaZiFpWcDIsopRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0QvNaV0EyM4rCX5djBO avA+xCjAwajEw3sjvSRKiDWxrLgy9xCjJAeTkihv4v7SKCG+pPyUyozE4oz4otKc1OJDjBIc zEoivP92AuV4UxIrq1KL8mFS0hwsSuK87ibaUUIC6YklqdmpqQWpRTBZGQ4OJQlekT9AjYJF qempFWmZOSUIaSYOTpDhPEDDjUBqeIsLEnOLM9Mh8qcYdTluvHjdxizEkpeflyolzqsHUiQA UpRRmgc3B5yOUjlcXjGKA70lzGsBUsUDTGVwk14BLWECWhKYBrakJBEhJdXA+KAzLdhiqltj +q63xYFLT0Rk/v0u3i+y46ahcsvnpotFAWd1g4RvLuBP/uFbEPXuxCrnR6YrvTfrP/WJmxOY bVYSvNdx2pHzGlcPOS7P3/o68ORGmw/T+SbfPyMRJdT9SsNQsKmr/oj5da/zZjWJHpxhuaId LHu5HyzS2RO526wo47ra3v5+JZbijERDLeai4kQAdCmuiyIDAAA= Archived-At: Subject: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 18:19:23 -0000 On 02/01/2018 12:17 PM, Sam Hartman wrote:> * Combine choice of hash with choice of group (Kerberos SPAKE groups > include a hash function in their definition). Requires changing the > spec to restart the hash when a KDC rejects an optimistic group > offer. Greg and I believe the security of this is fine. Under this choice the transcript hash cannot be started until a group is selected, so in the normal message flow we won't initialize the transcript until the KDC sends its challenge message. This works because the client and KDC both still have access to the client's support message (the client because it is stateful, and the KDC because the support message is present in the request the KDC is processing). We can concatenate the support and challenge message together and update the transcript hash with both at once, saving a hash operation. For the case where the group's hash function doesn't output enough bytes for the enctype's random-to-key function, I currently have this text: [as the last field of the hash input:] * A single-byte block counter, with the initial value 0x01. If the hash output is too small for the encryption type's key generation seed length, the block counter value is incremented and the hash function re-computed to produce as many blocks as are required. The result is truncated to the key generation seed length, and the random-to-key function is used to produce the key value. For edwards25519 and P-256, SHA-256 is a clear best choice. From a security perspective, I believe SHA-256 is also an adequate choice for P-384 and P-521 because we're likely going to truncate down to 128 or 256 bits for the key anyway. But if someone is using P-384 or P-521, they're probably doing so for compliance with some kind of 192-bit or 256-bit security standard, and the use of SHA-256 might raise a flag because of its 128-bit collision resistance. So I lean towards specifying SHA-384 for P-384 and SHA-512 for P-521. If someone is using those groups, they are already wasting a bunch of bytes on unnecessarily large public keys anyway. From nobody Sat Feb 3 10:46:57 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5F112D890 for ; Sat, 3 Feb 2018 10:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 zI7b4YNWhjfz for ; Sat, 3 Feb 2018 10:46:53 -0800 (PST) Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65]) (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 971AB12AF77 for ; Sat, 3 Feb 2018 10:46:53 -0800 (PST) Received: by mail-oi0-f65.google.com with SMTP id 8so7273228oix.7 for ; Sat, 03 Feb 2018 10:46:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iXC9rtQOwdOnrM899Bm1OGF8rWToGY9cNeUtsRErYPc=; b=OtfkC+VbTgeupFfpWSIaT3tMF2K7+XbkwR4Xi1FIXakTN4CCTwQPzCMFolUXNY4b5x ookSwFvEf74KbdcbXonedon29mM6t/pkCcWpO66AH8OkekvTwY691HZ0597+Y7Ay0EUV 8aOOrXa4R9+pq96qrzefUhFIh9iDhB83U1ro73ozwc3BnRDscCmHor9Q42g+51Wft33r rtRolsIK2UPwWZ1EpyN/Juk59uSC/uc1fLF4HyVmrVK2xgdnJVidaMoVg3A8xeZxeOHw L/iur7VSwEYEsp8vmEWzqgRkRfxyl5xNZzajjgr2VUu8e/XLgWo/hy3laBJ0GmarFOOt Im5Q== X-Gm-Message-State: AKwxytfpDwT1XbsaLOVjMqvKEfov4R8Sw2C3bkU+hswZMitpJvg1OZ90 cxjLPx25w2ORB7xj1x2wnR/H0tKJwf0An/1jMxBE6yKv X-Google-Smtp-Source: AH8x224eTCAQfuShLCOunlwrqo2U/lwkWlf9t1K1h2dZTqGIpYFIBsDvdEo7du67qKrtTvm4UZamRH/Crp9bDXR4rxA= X-Received: by 10.202.173.212 with SMTP id w203mr28106193oie.149.1517683612777; Sat, 03 Feb 2018 10:46:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Sat, 3 Feb 2018 10:46:52 -0800 (PST) Received: by 10.157.1.139 with HTTP; Sat, 3 Feb 2018 10:46:52 -0800 (PST) In-Reply-To: References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> From: Nathaniel McCallum Date: Sat, 3 Feb 2018 13:46:52 -0500 Message-ID: To: "Hudson, Greg" Cc: Sam Hartman , kitten@ietf.org Content-Type: multipart/alternative; boundary="001a113ce4dc9f175a05645340ea" Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 18:46:56 -0000 --001a113ce4dc9f175a05645340ea Content-Type: text/plain; charset="UTF-8" I agree regarding hash choices. However, as I was thinking about the hint, it does open the door to a downgrade attack. If the hint isn't in the transcript, we can't tell if it was modified. As the protocol currently is defined, any attempt to modify the SPAKESupport message will break the final key derivation. So in my mind, the value of using a hint needs to be weighed against this cost. What is the precise reason the hint can't be included in the transcript? On Feb 3, 2018 1:19 PM, "Greg Hudson" wrote: On 02/01/2018 12:17 PM, Sam Hartman wrote:> * Combine choice of hash with choice of group (Kerberos SPAKE groups > include a hash function in their definition). Requires changing the > spec to restart the hash when a KDC rejects an optimistic group > offer. Greg and I believe the security of this is fine. Under this choice the transcript hash cannot be started until a group is selected, so in the normal message flow we won't initialize the transcript until the KDC sends its challenge message. This works because the client and KDC both still have access to the client's support message (the client because it is stateful, and the KDC because the support message is present in the request the KDC is processing). We can concatenate the support and challenge message together and update the transcript hash with both at once, saving a hash operation. For the case where the group's hash function doesn't output enough bytes for the enctype's random-to-key function, I currently have this text: [as the last field of the hash input:] * A single-byte block counter, with the initial value 0x01. If the hash output is too small for the encryption type's key generation seed length, the block counter value is incremented and the hash function re-computed to produce as many blocks as are required. The result is truncated to the key generation seed length, and the random-to-key function is used to produce the key value. For edwards25519 and P-256, SHA-256 is a clear best choice. From a security perspective, I believe SHA-256 is also an adequate choice for P-384 and P-521 because we're likely going to truncate down to 128 or 256 bits for the key anyway. But if someone is using P-384 or P-521, they're probably doing so for compliance with some kind of 192-bit or 256-bit security standard, and the use of SHA-256 might raise a flag because of its 128-bit collision resistance. So I lean towards specifying SHA-384 for P-384 and SHA-512 for P-521. If someone is using those groups, they are already wasting a bunch of bytes on unnecessarily large public keys anyway. _______________________________________________ Kitten mailing list Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten --001a113ce4dc9f175a05645340ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree regarding hash choices. However, as I was thinkin= g about the hint, it does open the door to a downgrade attack. If the hint = isn't in the transcript, we can't tell if it was modified. As the p= rotocol currently is defined, any attempt to modify the SPAKESupport messag= e will break the final key derivation.

So in my mind, the value of using a hint needs to be weighed agai= nst this cost.

What is t= he precise reason the hint can't be included in the transcript?

On Feb 3, 201= 8 1:19 PM, "Greg Hudson" <g= hudson@mit.edu> wrote:
On 02/01/2018 12:17 PM, Sam Hartman wrote:> * Combine choice of hash=
with choice of group (Kerberos SPAKE groups
>=C2=A0 =C2=A0include a hash function in their definition).=C2=A0 Requir= es changing the
>=C2=A0 =C2=A0spec to restart the hash when a KDC rejects an optimistic = group
>=C2=A0 =C2=A0offer.=C2=A0 Greg and I believe the security of this is fi= ne.

Under this choice the transcript hash cannot be started until a group is selected, so in the normal message flow we won't initialize the
transcript until the KDC sends its challenge message.=C2=A0 This works
because the client and KDC both still have access to the client's
support message (the client because it is stateful, and the KDC because
the support message is present in the request the KDC is processing).
We can concatenate the support and challenge message together and update the transcript hash with both at once, saving a hash operation.

For the case where the group's hash function doesn't output enough = bytes
for the enctype's random-to-key function, I currently have this text:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 [as the last field of the hash input:]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 * A single-byte block counter, with the initial= value 0x01.

=C2=A0 =C2=A0 If the hash output is too small for the encryption type's= key
=C2=A0 =C2=A0 generation seed length, the block counter value is incremente= d and
=C2=A0 =C2=A0 the hash function re-computed to produce as many blocks as ar= e
=C2=A0 =C2=A0 required. The result is truncated to the key generation seed = length,
=C2=A0 =C2=A0 and the random-to-key function is used to produce the key val= ue.

For edwards25519 and P-256, SHA-256 is a clear best choice.=C2=A0 From a security perspective, I believe SHA-256 is also an adequate choice for
P-384 and P-521 because we're likely going to truncate down to 128 or 256 bits for the key anyway.=C2=A0 But if someone is using P-384 or P-521,<= br> they're probably doing so for compliance with some kind of 192-bit or 256-bit security standard, and the use of SHA-256 might raise a flag
because of its 128-bit collision resistance.=C2=A0 So I lean towards
specifying SHA-384 for P-384 and SHA-512 for P-521.=C2=A0 If someone is usi= ng
those groups, they are already wasting a bunch of bytes on unnecessarily large public keys anyway.

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

--001a113ce4dc9f175a05645340ea-- From nobody Sat Feb 3 13:24:59 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED92F12D830 for ; Sat, 3 Feb 2018 13:24:57 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 C-xnnsLVxWpi for ; Sat, 3 Feb 2018 13:24:56 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 2B5A912D77B for ; Sat, 3 Feb 2018 13:24:56 -0800 (PST) X-AuditID: 12074425-81fff70000000cb2-90-5a7628a57dae 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 1D.BA.03250.6A8267A5; Sat, 3 Feb 2018 16:24:54 -0500 (EST) 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 w13LOqUh002696; Sat, 3 Feb 2018 16:24:52 -0500 Received: from [18.101.8.68] (VPN-18-101-8-68.MIT.EDU [18.101.8.68]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w13LOmOe027958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 3 Feb 2018 16:24:51 -0500 To: Nathaniel McCallum Cc: Sam Hartman , kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> From: Greg Hudson Message-ID: <8f82816f-593b-a0f0-8d17-2484dc527b3f@mit.edu> Date: Sat, 3 Feb 2018 16:24:48 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDKsWRmVeSWpSXmKPExsUixCmqrbtMoyzK4OxDBYuvbQ/YLI5uXsVi MffrLFYHZo8lS34yebzfd5XNY+XU0+wBzFFcNimpOZllqUX6dglcGWsaXrEXrBat2LN4OksD 4zLBLkZODgkBE4l98x4zdzFycQgJLGaSaO17zQjhbGCUaPjxiAXCOcgk8fjuJ7CMsEAjo8Tt 91PZQfpFBPQklu2bwAhiMwtYSNzfOxWq/S6LxMquSWAJNgFlifX7twKN4uDgFbCS+NUoCxJm EVCRWNN9HWyOqECERNPMuawgNq+AoMTJmU9YQGxOgUCJS4e+sEPMV5f4M+8SM4QtLnHryXwm CFteYvvbOcwTGAVnIWmfhaRlFpKWWUhaFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvN LNFLTSndxAgKeHYX1R2Mc/56HWIU4GBU4uG9kV4SJcSaWFZcmXuIUZKDSUmUN3F/aZQQX1J+ SmVGYnFGfFFpTmrxIUYJDmYlEd5/O4FyvCmJlVWpRfkwKWkOFiVxXg8T7SghgfTEktTs1NSC 1CKYrAwHh5IE7zX1sighwaLU9NSKtMycEoQ0EwcnyHAeoOFywAQhxFtckJhbnJkOkT/FqMtx 48XrNmYhlrz8vFQpcd7pIIMEQIoySvPg5oATVSqHyytGcaC3hHmjQKp4gEkObtIroCVMQEsC 00A+KC5JREhJNTAu/P8t0HaRjFPo0q2aFa5X3JVrgwu+PpgRKimfGbt9aVaMB/feA2GiB7I8 zybK1LxbcEpuuQnPks83p70+VGFouLHx5br3VnXm8zncGly/Cq7ZIO6zdJfnZd26fxukkyMW qezoeKGTYZgW953747p9PY1e6Q8OrrrzPGShONca/YgjF2r97y9UYinOSDTUYi4qTgQAISzs 6S8DAAA= Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 21:24:58 -0000 On 02/03/2018 01:46 PM, Nathaniel McCallum wrote: > I agree regarding hash choices. However, as I was thinking about the > hint, it does open the door to a downgrade attack. If the hint isn't in > the transcript, we can't tell if it was modified. As the protocol > currently is defined, any attempt to modify the SPAKESupport message > will break the final key derivation. A pa-hint would be used only when a KDC advertises an RFC 6113 authentication set containing SPAKE and one or more other preauth mechanisms. (As far as I know, nobody implements RFC 6113 authentication sets at this time.) The pa-hint would be used by a client to decide whether to select between this authentication set, and another authentication set which perhaps does not use SPAKE. The pa-hint would allow the client to determine ahead of time whether SPAKE group negotiation will succeed. Without the pa-hint, the client might only find out that SPAKE won't work after it has already processed an earlier part of the authentication set, perhaps asking for user input. If the client does decide to use this authentication set, it will use the normal message flow which begins with a client's SPAKESupport message. This support message will be included in the transcript, so group negotiation will be protected. Including the pa-hint in the transcript would pose some difficulty for the KDC. The KDC does not know at the time of the pa-hint what group will be negotiated (so it doesn't know what hash function to use, if the hash function is a property of the group). It also might not want to use network bytes on a cookie at this point, since it doesn't know if the client understands SPAKE at all. So I would expect a KDC to instead reconstruct its pa-hint later on when it processes the client's support message. That would mean changes to the KDC configuration could break authentications in progress. (It's possible that you were thinking of a rejected KDC optimistic challenge rather than a pa-hint, the problem is that the hash function might change when the selected group changes. If the client rejects an optimistic KDC challenge, it will fall back to the normal message flow which still protects group negotiation.) (It's also possible that you were thinking of the initial pa-value that gets included in a preauth_required error that simply lists SPAKE as one of several preauth types. That would be understandable because the MIT krb5 KDC code calls the preauth_required method-data a "hint list", but that is not what an RFC 6113 pa-hint is. Currently the initial SPAKE pa-value is empty unless the KDC issues an optimistic challenge, and we are not proposing to change that.) From nobody Sat Feb 3 20:02:36 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FE5126DC2 for ; Sat, 3 Feb 2018 20:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hXrz_55HcxVF for ; Sat, 3 Feb 2018 20:02:33 -0800 (PST) Received: from mail-oi0-f65.google.com (mail-oi0-f65.google.com [209.85.218.65]) (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 DA78B126D45 for ; Sat, 3 Feb 2018 20:02:32 -0800 (PST) Received: by mail-oi0-f65.google.com with SMTP id k15so18948844oib.1 for ; Sat, 03 Feb 2018 20:02:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+TeurFxaJ/ZR1x3pWiU6PcbmYzE3/4ohW9FTN9UYbh0=; b=dqLUSaRsRMXKmSUtGfxiAE1RblA3FgWXqXtugv8AmC6YbHiIt4EUNpQ6QgN03ljCo2 QbJWjAZAC0Zg2lqIwU6XUt6+BNloSpUayFOgfUCCsxges6NxKZDUM6kn0e2exj/J9r9/ 6dt77woRAoz/wa7T0NiAkwv0AW2L8Tvo8+6W74SqBUzhpIPccvmvpjdzU9C+Lr4uqtto ZPgLvr92viAuiaFyr7qmpOo9Q0vrdB+ztXvLqkgHvvg5wFh3wcESwVMBd4U8lW4mBsYW neWOQazBHSsIgKj/eGwKiF7k8c1JGxLO0IOriV2+Iaq1R+8A1VTy721fnjprza1lcrl/ 7mkA== X-Gm-Message-State: AKwxytczWKsO3JKOqPOsNeWkQCgvqoEMKeDTl143YGpkbDYojAXlvmq6 TCi5ZS2xOsh4wqTRwu2G+getckoaFo7veXxGc2mmDA== X-Google-Smtp-Source: AH8x227nHkNxnUsdpxbLOnOVUfSpofw7oOlEwPYnf0uWOMLnlyOMZ78ZY9icah2a2HZCBZKXoZIumo4JqHg3kCLP0OU= X-Received: by 10.202.10.202 with SMTP id k71mr19205486oiy.20.1517716952021; Sat, 03 Feb 2018 20:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Sat, 3 Feb 2018 20:02:30 -0800 (PST) Received: by 10.157.1.139 with HTTP; Sat, 3 Feb 2018 20:02:30 -0800 (PST) In-Reply-To: <8f82816f-593b-a0f0-8d17-2484dc527b3f@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> <8f82816f-593b-a0f0-8d17-2484dc527b3f@mit.edu> From: Nathaniel McCallum Date: Sat, 3 Feb 2018 23:02:30 -0500 Message-ID: To: "Hudson, Greg" Cc: Sam Hartman , kitten@ietf.org Content-Type: multipart/alternative; boundary="001a1140cbfccb8d3b05645b039f" Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 04:02:35 -0000 --001a1140cbfccb8d3b05645b039f Content-Type: text/plain; charset="UTF-8" Got it. Thank you for the clarification. On Feb 3, 2018 4:25 PM, "Greg Hudson" wrote: > On 02/03/2018 01:46 PM, Nathaniel McCallum wrote: > > I agree regarding hash choices. However, as I was thinking about the > > hint, it does open the door to a downgrade attack. If the hint isn't in > > the transcript, we can't tell if it was modified. As the protocol > > currently is defined, any attempt to modify the SPAKESupport message > > will break the final key derivation. > > A pa-hint would be used only when a KDC advertises an RFC 6113 > authentication set containing SPAKE and one or more other preauth > mechanisms. (As far as I know, nobody implements RFC 6113 > authentication sets at this time.) The pa-hint would be used by a > client to decide whether to select between this authentication set, and > another authentication set which perhaps does not use SPAKE. The > pa-hint would allow the client to determine ahead of time whether SPAKE > group negotiation will succeed. Without the pa-hint, the client might > only find out that SPAKE won't work after it has already processed an > earlier part of the authentication set, perhaps asking for user input. > > If the client does decide to use this authentication set, it will use > the normal message flow which begins with a client's SPAKESupport > message. This support message will be included in the transcript, so > group negotiation will be protected. > > Including the pa-hint in the transcript would pose some difficulty for > the KDC. The KDC does not know at the time of the pa-hint what group > will be negotiated (so it doesn't know what hash function to use, if the > hash function is a property of the group). It also might not want to > use network bytes on a cookie at this point, since it doesn't know if > the client understands SPAKE at all. So I would expect a KDC to instead > reconstruct its pa-hint later on when it processes the client's support > message. That would mean changes to the KDC configuration could break > authentications in progress. > > (It's possible that you were thinking of a rejected KDC optimistic > challenge rather than a pa-hint, the problem is that the hash function > might change when the selected group changes. If the client rejects an > optimistic KDC challenge, it will fall back to the normal message flow > which still protects group negotiation.) > > (It's also possible that you were thinking of the initial pa-value that > gets included in a preauth_required error that simply lists SPAKE as one > of several preauth types. That would be understandable because the MIT > krb5 KDC code calls the preauth_required method-data a "hint list", but > that is not what an RFC 6113 pa-hint is. Currently the initial SPAKE > pa-value is empty unless the KDC issues an optimistic challenge, and we > are not proposing to change that.) > --001a1140cbfccb8d3b05645b039f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Got it. Thank you for the clarification.

On Feb 3, 2018 4:25 PM, &qu= ot;Greg Hudson" <ghudson@mit.edu= > wrote:
On 0= 2/03/2018 01:46 PM, Nathaniel McCallum wrote:
> I agree regarding hash choices. However, as I was thinking about the > hint, it does open the door to a downgrade attack. If the hint isn'= ;t in
> the transcript, we can't tell if it was modified. As the protocol<= br> > currently is defined, any attempt to modify the SPAKESupport message > will break the final key derivation.

A pa-hint would be used only when a KDC advertises an RFC 6113
authentication set containing SPAKE and one or more other preauth
mechanisms.=C2=A0 (As far as I know, nobody implements RFC 6113
authentication sets at this time.)=C2=A0 The pa-hint would be used by a
client to decide whether to select between this authentication set, and
another authentication set which perhaps does not use SPAKE.=C2=A0 The
pa-hint would allow the client to determine ahead of time whether SPAKE
group negotiation will succeed.=C2=A0 Without the pa-hint, the client might=
only find out that SPAKE won't work after it has already processed an earlier part of the authentication set, perhaps asking for user input.

If the client does decide to use this authentication set, it will use
the normal message flow which begins with a client's SPAKESupport
message.=C2=A0 This support message will be included in the transcript, so<= br> group negotiation will be protected.

Including the pa-hint in the transcript would pose some difficulty for
the KDC.=C2=A0 The KDC does not know at the time of the pa-hint what group<= br> will be negotiated (so it doesn't know what hash function to use, if th= e
hash function is a property of the group).=C2=A0 It also might not want to<= br> use network bytes on a cookie at this point, since it doesn't know if the client understands SPAKE at all.=C2=A0 So I would expect a KDC to inste= ad
reconstruct its pa-hint later on when it processes the client's support=
message.=C2=A0 That would mean changes to the KDC configuration could break=
authentications in progress.

(It's possible that you were thinking of a rejected KDC optimistic
challenge rather than a pa-hint, the problem is that the hash function
might change when the selected group changes.=C2=A0 If the client rejects a= n
optimistic KDC challenge, it will fall back to the normal message flow
which still protects group negotiation.)

(It's also possible that you were thinking of the initial pa-value that=
gets included in a preauth_required error that simply lists SPAKE as one of several preauth types.=C2=A0 That would be understandable because the MI= T
krb5 KDC code calls the preauth_required method-data a "hint list"= ;, but
that is not what an RFC 6113 pa-hint is.=C2=A0 Currently the initial SPAKE<= br> pa-value is empty unless the KDC issues an optimistic challenge, and we
are not proposing to change that.)
--001a1140cbfccb8d3b05645b039f-- From nobody Sun Feb 4 19:06:54 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794B612422F for ; Sun, 4 Feb 2018 19:06:53 -0800 (PST) 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 autolearn_force=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 LV0FUznXPpWx for ; Sun, 4 Feb 2018 19:06:51 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 986931200C1 for ; Sun, 4 Feb 2018 19:06:51 -0800 (PST) X-AuditID: 12074424-841ff700000073d7-9d-5a77ca483fe5 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 91.07.29655.94AC77A5; Sun, 4 Feb 2018 22:06:49 -0500 (EST) 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 w1536lWI018837; Sun, 4 Feb 2018 22:06:47 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1536hF1013152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 4 Feb 2018 22:06:45 -0500 Date: Sun, 4 Feb 2018 21:06:43 -0600 From: Benjamin Kaduk To: Nathaniel McCallum Cc: Simo Sorce , kitten@ietf.org, Sam Hartman Message-ID: <20180205030642.GV12363@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <1517512299.13097.135.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplleLIzCtJLcpLzFFi42IR4hRV1vU8VR5lsPKDqcXXtgdsFkc3r2Kx mPt1FqvFj7mLWB1YPJYs+cnk8X7fVTaPlVNPswcwR3HZpKTmZJalFunbJXBl9Oy+wFawXrqi 6XpUA+NE0S5GTg4JAROJo1v72UBsIYHFTBJv5yl1MXIB2RsYJa5+n8EG4Zxhkti7/xw7SBWL gIrEtX8NTCA2G5Dd0H2ZGcQWEdCTWLZvAiOIzSwQL7Fy0k6wGmEBb4n7H++C2bwCOhKXuz+x Qww9xSyxe8I8VoiEoMTJmU9YIJq1JG78ewnUwAFkS0ss/8cBEuYUCJT4uOwSWLmogLLE3r5D 7BMYBWYh6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrFyYl5ealFuuZ6uZkleqkppZsYQSHM 7qKyg7G7x/sQowAHoxIP74TE8igh1sSy4srcQ4ySHExKoryz1gKF+JLyUyozEosz4otKc1KL DzFKcDArifDOmFQWJcSbklhZlVqUD5OS5mBREuf1MNGOEhJITyxJzU5NLUgtgsnKcHAoSfBa nAQaKliUmp5akZaZU4KQZuLgBBnOAzT82wmgGt7igsTc4sx0iPwpRl2OGy9etzELseTl56VK ifMmgxQJgBRllObBzQGlHons/TWvGMWB3hLmrQVZxwNMW3CTXgEtYQJaEphWCrKkJBEhJdXA OIGz/91il7KfU5TL+WxmXDlZs0DslPp5pun/NixrYDm9q9D2wmc2Yf6eTVWOT9W/Wm+ZMcnp RX31316dwvSK+zXzYrT0YzMmuKnapvrnxQttfV+27pC92jz9ohnCZ+ZW7WY6E2nYevf9SYUS 6Yw5t16ISz0XfX2lYf17h1PSbJs/aT8R/u7+WomlOCPRUIu5qDgRAGQ+WfoYAwAA Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 03:06:53 -0000 I also think that we should probably go with one of the first two options. There is some appeal to attaching the hash to the SPAKE group, since they both are things new in this spec and we don't have to awkwardly try to force enctypes to also include a new thing. The downside is of course that we might choose a hash that is "too small" for some hypothetical new enctype that uses large keys, but presumably we will notice the conflict if such a new enctype arises, and can make new group entries (even if they are the same underlying groups) with larger hashes. -Ben On Thu, Feb 01, 2018 at 03:15:58PM -0500, Nathaniel McCallum wrote: > I agree with Simo. The first two options are probably the best. I > don't have a strong opinion between them. However, I suspect that we > aren't worried about compatibility at this point (nobody ships this). > > On Thu, Feb 1, 2018 at 2:11 PM, Simo Sorce wrote: > > On Thu, 2018-02-01 at 12:17 -0500, Sam Hartman wrote: > >> > > > > > "Simo" == Simo Sorce writes: > >> > >> Simo> It is a bit annoying to have to do this for each new enctype > >> Simo> ... just for a pre-auth mechanism. I wonder if we couldn't > >> Simo> simply add a field in the first message that specifies the > >> Simo> hash we are using. The server can then just refuse operations > >> Simo> if it doesn't want to use the hash the client selected. This > >> Simo> would allow smooths transitions from "current-hash" to > >> Simo> "new-hash" in case current hash is not totally broken right > >> Simo> away, but like SHA-1 gets weaker and weaker and we plan > >> Simo> replacement. > >> > >> I think that the idea of combining the hash definition with the group > >> definition is about the same as this, only a bit simpler. > >> > >> My ranked options are: > >> > >> * Combine choice of hash with choice of group (Kerberos SPAKE groups > >> include a hash function in their definition). Requires changing the > >> spec to restart the hash when a KDC rejects an optimistic group > >> offer. Greg and I believe the security of this is fine. > >> > >> * Registering a mapping of SPAKE hashes to enctypes. The major > >> advantage I see is that it can (I think) maintain interop with the > >> existing protocol. The down side is that in some cases you might have > >> to register a new enctype or except a non-ideal SPAKE hash. > >> > >> * Use the PRF. I think that while the concerns are real, the security > >> is fine > >> > >> * Your proposal of hash in first message > > > > I think the above options are all fine by me, maybe not in the same > > exact order, but they all work. > > > >> * Get sufficient review and make RFC 3961 hashes deterministic > >> > >> * Find other options > >> > >> * Give up on SPAKE > > > > I'd rather not go into the last three, but I am open to other options > > that have substantial advantages and no big downside compared to the > > first 4 on the table that it is worth spending time on them. > > > > Simo. > > > > -- > > Simo Sorce > > Sr. Principal Software Engineer > > Red Hat, Inc > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Sun Feb 4 22:00:34 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11478126D74 for ; Sun, 4 Feb 2018 22:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 JbigDjj7fVdl for ; Sun, 4 Feb 2018 22:00:30 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 306C0126CD6 for ; Sun, 4 Feb 2018 22:00:29 -0800 (PST) X-AuditID: 1209190d-7a5ff70000003403-94-5a77f2fb3e81 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 64.B1.13315.CF2F77A5; Mon, 5 Feb 2018 01:00:28 -0500 (EST) 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 w1560NOt007629; Mon, 5 Feb 2018 01:00:24 -0500 Received: from [18.101.8.203] (VPN-18-101-8-203.MIT.EDU [18.101.8.203]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1560Jnj016619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 Feb 2018 01:00:21 -0500 From: Greg Hudson To: Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> Message-ID: Date: Mon, 5 Feb 2018 01:00:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixG6novvnU3mUwd7jehZf2x6wWRzdvIrF gcljyZKfTB4rp55mD2CK4rJJSc3JLEst0rdL4MrY+3Ylc8FemYrfL1ayNjA+EOti5OSQEDCR 2PNuOmsXIxeHkMBiJomXCzaxQTgbGCVmXJ3HClIlJHCESeL+LSuQhLBAI6PE7fdT2UESbALK Euv3b2UBsUUE1CVWX5oEFmcWEJZYvuYs1KQOZomzdz8CORwcvAJWEv03s0BqWARUJP7ePQVW LyoQIdE0cy7YMl4BQYmTM5+AzeQUsJZYcvUPE8RMdYk/8y4xQ9jiEreezIeKy0tsfzuHeQKj 4Cwk7bOQtMxC0jILScsCRpZVjLIpuVW6uYmZOcWpybrFyYl5ealFukZ6uZkleqkppZsYQaHN Kcm7g/HfXa9DjAIcjEo8vBMSy6OEWBPLiitzDzFKcjApifKGfwAK8SXlp1RmJBZnxBeV5qQW H2KU4GBWEuF1ug6U401JrKxKLcqHSUlzsCiJ87qbaEcJCaQnlqRmp6YWpBbBZGU4OJQkeIuA MSwkWJSanlqRlplTgpBm4uAEGc4DNDwApIa3uCAxtzgzHSJ/ilGX48aL123MQix5+XmpUuK8 Jh+BigRAijJK8+DmgFNSKsfpV4ziQG8J854HqeIBpjO4Sa+AljABLQlMKwVZUpKIkJJqYMyv fvqg5cO69DdpN6ZcFlb9sOz++c95t84vyHN6b2M1veRPp8+DeeayXY4+FxuUusoTQ1qr1r1u YK8zOF2Ve7VOgVn5wIYiwQjtpVFiLRWphcUPuU+eUxdYZPNgzWsevT3f8mRnBoXMC5jFc2VD YNm/jLv/ehaWxSyOyed4vLpnrq4K08+k00osxRmJhlrMRcWJALqXpJckAwAA Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 06:00:32 -0000 This option seems to have the most initial WG support. So I have put together proposed changes to the spec: https://github.com/greghudson/ietf/pull/4/commits/77753ee1c901ff771cba46b8c16d801fd8c74676 I have also updated my Python implementation to produce updated test vectors, and my C implementation (for MIT krb5) to verify them. Substantial bits of new text: [In the section "SPAKE Pre-Authentication Message Protocol":] Each group definition specifies an associated hash function, which will be used for transcript protection and key derivation. [In the section "Second Pass":] The client and KDC will each initialize a transcript hash [xref] using the hash function associated with the hosen group, and update it with the concatenation of the DER-encoded PA-SPAKE messages sent by the client and the KDC. [In the section "Optimizations":] If the group chosen by the challenge message is supported by the client, the client MUST skip to the third pass by issuing an AS-REQ with a PA-SPAKE message using the response choice. In this case no SPAKESupport message is sent by the client, so the first update to the transcript hash contains only the KDC's optimistic challenge. If the KDC's chosen group is not supported by the client, the client MUST continue to the second pass. In this case both the client and KDC MUST reinitialize the transcript hash for the client's support message. Clients MUST support this optimization. [In the section "Transcript Hash":] When the transcript hash is updated with an octet string input, the new value is the hash function computed over the concatenation of the old value and the input. In the normal message flow or with the second optimization described in [xref], the transcript hash is first updated with the concatenation of the client's support message and the KDC's challenge, and then updated a second time with the client's pubkey value. It therefore incorporates the client's supported groups, the KDC's chosen group, the KDC's initial second-factor messages, and the client and KDC public values. Once the transcript hash is finalized, it is used without change for all key derivations [xref]. If the first optimization described in [xref] is used successfully, the transcript hash is updated first with the KDC's challenge message, and second with the client's pubkey value. If first optimization is used unsuccessfully (i.e. the client does not accept the KDC's selected group), the transcript hash is computed as in the normal message flow, without including the KDC's optimistic challenge. [In the section "Key Derivation":] [As the fourth field in the hash input:] The PRF+ output used to compute the initial secret input w as specified in [xref]. [As the ninth and final field in the hash input:] A single-byte block counter, with the initial value 0x01. If the hash output is too small for the encryption type's key generation seed length, the block counter value is incremented and the hash function re-computed to produce as many blocks as are required. The result is truncated to the key generation seed length, and the random-to-key function is used to produce the key value. The section "Update to Checksum Specifications" is removed, and with it the prohibition against using SPAKE with single-DES enctypes. For the pa-hint for authentication sets, I realized that we probably want to include second factor info as well as KDC group support, so I will address that in a separate update and thread. From nobody Mon Feb 5 08:08:06 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511F7127286 for ; Mon, 5 Feb 2018 08:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 rGTyavxkX-q3 for ; Mon, 5 Feb 2018 08:08:02 -0800 (PST) Received: from mail-oi0-f67.google.com (mail-oi0-f67.google.com [209.85.218.67]) (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 D6562126C2F for ; Mon, 5 Feb 2018 08:08:01 -0800 (PST) Received: by mail-oi0-f67.google.com with SMTP id l8so21535959oig.0 for ; Mon, 05 Feb 2018 08:08:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qSjiJiXvEhbMo0g/FIPiOE5XQoMXfmS3WhJVyuckuVw=; b=CM3zcuHC1j8zWa/Kr7bgwcRBs9SKpFmdTyI14GTmKq13d79gA+n7jVPpYqgjBxvJun ENUQ/vXOPc8WH/tGV104AaGGkXLpNp9vJPLlxIfLXJTo3czDE7h+a+XpPlMrDy8e5YdE VVJVnb7BgO7c8YkVCZybgMV5GeYCSYvBQ93L8otrLwjRmw5XbyZUZX7ldZ8uJBlyv/EE P9/c6FPr19++ZIRVLi6yOqn1Jg2cmkBTmn0k3IKXdHwLScSpK0mVv++4Kl2iyIJv8E6q PH89Ar1P4/rNKiWwVgA6pykcEB0c46O4ndWc3TmgRpoX/olAZIh8KcoUNO62/hdwY+uJ +RDQ== X-Gm-Message-State: APf1xPCCUTjtvg/C5wvdYNipA3PMMaGDx7sk8jZXCiVxOPDJbM9aQgXn jW0gsJX5x5cAK1Ih2hsh3Ly6LTJbrhkJ9lwnI/nPMQ== X-Google-Smtp-Source: AH8x227Vrj7XexvMWq0yD9RVhKd17GhgOg+6fxfTV+JDsv9VVGYzqnggbHYTPaUsXG2o6JKzwG4Ar/ENcuFC0prdVio= X-Received: by 10.202.180.136 with SMTP id d130mr1328104oif.328.1517846880855; Mon, 05 Feb 2018 08:08:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Mon, 5 Feb 2018 08:08:00 -0800 (PST) In-Reply-To: References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> From: Nathaniel McCallum Date: Mon, 5 Feb 2018 11:08:00 -0500 Message-ID: To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:08:04 -0000 This all looks good. Thanks! On Mon, Feb 5, 2018 at 1:00 AM, Greg Hudson wrote: > This option seems to have the most initial WG support. So I have put > together proposed changes to the spec: > > https://github.com/greghudson/ietf/pull/4/commits/77753ee1c901ff771cba46b8c16d801fd8c74676 > > I have also updated my Python implementation to produce updated test > vectors, and my C implementation (for MIT krb5) to verify them. > > Substantial bits of new text: > > [In the section "SPAKE Pre-Authentication Message Protocol":] > Each group definition specifies an associated hash function, which > will be used for transcript protection and key derivation. > > [In the section "Second Pass":] > The client and KDC will each initialize a transcript hash [xref] > using the hash function associated with the hosen group, and update it > with the concatenation of the DER-encoded PA-SPAKE messages sent by > the client and the KDC. > > [In the section "Optimizations":] > If the group chosen by the challenge message is supported by > the client, the client MUST skip to the third pass by issuing an > AS-REQ with a PA-SPAKE message using the response choice. In this case > no SPAKESupport message is sent by the client, so the first update to > the transcript hash contains only the KDC's optimistic challenge. If > the KDC's chosen group is not supported by the client, the client MUST > continue to the second pass. In this case both the client and KDC MUST > reinitialize the transcript hash for the client's support message. > Clients MUST support this optimization. > > [In the section "Transcript Hash":] > When the transcript hash is updated with an octet string input, the > new value is the hash function computed over the concatenation of the > old value and the input. > > In the normal message flow or with the second optimization described > in [xref], the transcript hash is first updated with the concatenation > of the client's support message and the KDC's challenge, and then > updated a second time with the client's pubkey value. It therefore > incorporates the client's supported groups, the KDC's chosen group, > the KDC's initial second-factor messages, and the client and KDC > public values. Once the transcript hash is finalized, it is used > without change for all key derivations [xref]. > > If the first optimization described in [xref] is used successfully, > the transcript hash is updated first with the KDC's challenge message, > and second with the client's pubkey value. > > If first optimization is used unsuccessfully (i.e. the client does > not accept the KDC's selected group), the transcript hash is computed > as in the normal message flow, without including the KDC's optimistic > > challenge. > > [In the section "Key Derivation":] > > [As the fourth field in the hash input:] > The PRF+ output used to compute the initial secret input w as > specified in [xref]. > > [As the ninth and final field in the hash input:] > A single-byte block counter, with the initial value 0x01. > > If the hash output is too small for the encryption type's key > generation seed length, the block counter value is incremented and the > hash function re-computed to produce as many blocks as are required. > The result is truncated to the key generation seed length, and the > random-to-key function is used to produce the key value. > > The section "Update to Checksum Specifications" is removed, and with it > the prohibition against using SPAKE with single-DES enctypes. > > For the pa-hint for authentication sets, I realized that we probably > want to include second factor info as well as KDC group support, so I > will address that in a separate update and thread. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Feb 5 08:11:09 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2920112D852 for ; Mon, 5 Feb 2018 08:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 F4sTpdt1cvRA for ; Mon, 5 Feb 2018 08:11:02 -0800 (PST) Received: from mail-oi0-f67.google.com (mail-oi0-f67.google.com [209.85.218.67]) (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 D25F61270AC for ; Mon, 5 Feb 2018 08:11:01 -0800 (PST) Received: by mail-oi0-f67.google.com with SMTP id t78so21539082oih.4 for ; Mon, 05 Feb 2018 08:11:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IZ4xqQ+O++DZrFIAULzATRj04uhMKXhP3+qFaUGad+4=; b=JR7VG5oBWe+tVep1ueUDnSLHDeHKTUTKPePnsaQm2RWIFv2u8zdoIEDGIjoT1bfHoI nUuuGNbnZkJ3nzwq4QAKFwJdu+sIptwn0hoR4Rz6ZCGg2PMiWrrk52OSu5N8UyWbWSRp mhHyeD7oa3MzlyY78d4o1KzBK1oucBSKEQbSssoMeowknsoHX7/0sAWH1MkUj0NlXRzu SqfGcNTlVBSxyynX9jnGGZpONGxMyFpADPAQeo2vZRLpRQLPUhwAOVYvN/UqVD4mpM2A ztz7kzYNtQ/8hHftFoO81wN3vKmFKar1SIX6GKN/pYBOT03oM9JYnVuEKEFKD0kDVgw7 Cq+Q== X-Gm-Message-State: AKwxytdZmNz199CqATWlub/12fXSICh8zqUGVUHo1LHSrcw42lG1zYaV JtPW/102jOuY/THx9zaiqTuH9XPW1XLdj353Z4tT4w== X-Google-Smtp-Source: AH8x2253kuFYq1zC2EdWhroGrHeUgafj1qlOOSaRl6ctrP2ZIRCcrD9KJvOKFaCtB4jzJ634tEDhdQnQ2toq85wl9/g= X-Received: by 10.202.173.212 with SMTP id w203mr31557540oie.149.1517847061031; Mon, 05 Feb 2018 08:11:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Mon, 5 Feb 2018 08:11:00 -0800 (PST) In-Reply-To: <20180205030642.GV12363@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <1517512299.13097.135.camel@redhat.com> <20180205030642.GV12363@mit.edu> From: Nathaniel McCallum Date: Mon, 5 Feb 2018 11:11:00 -0500 Message-ID: To: Benjamin Kaduk Cc: Simo Sorce , kitten@ietf.org, Sam Hartman Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [kitten] Concerns about draft-ietf-kitten-krb-spake-preauth-04 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 16:11:04 -0000 Unless I'm missing something, I don't think this is necessary. When the hash is associated with the group choice, the output size of the hash is correlated to the strength of the group used. If a new enctype arises with stronger keys, increasing the hash alone won't increase the security of the SPAKE exchange itself. Therefore, an entirely new group is needed. On Sun, Feb 4, 2018 at 10:06 PM, Benjamin Kaduk wrote: > I also think that we should probably go with one of the first two > options. There is some appeal to attaching the hash to the SPAKE > group, since they both are things new in this spec and we don't have > to awkwardly try to force enctypes to also include a new thing. > The downside is of course that we might choose a hash that is "too > small" for some hypothetical new enctype that uses large keys, but > presumably we will notice the conflict if such a new enctype arises, > and can make new group entries (even if they are the same underlying > groups) with larger hashes. > > -Ben > > On Thu, Feb 01, 2018 at 03:15:58PM -0500, Nathaniel McCallum wrote: >> I agree with Simo. The first two options are probably the best. I >> don't have a strong opinion between them. However, I suspect that we >> aren't worried about compatibility at this point (nobody ships this). >> >> On Thu, Feb 1, 2018 at 2:11 PM, Simo Sorce wrote: >> > On Thu, 2018-02-01 at 12:17 -0500, Sam Hartman wrote: >> >> > > > > > "Simo" == Simo Sorce writes: >> >> >> >> Simo> It is a bit annoying to have to do this for each new enctype >> >> Simo> ... just for a pre-auth mechanism. I wonder if we couldn't >> >> Simo> simply add a field in the first message that specifies the >> >> Simo> hash we are using. The server can then just refuse operations >> >> Simo> if it doesn't want to use the hash the client selected. This >> >> Simo> would allow smooths transitions from "current-hash" to >> >> Simo> "new-hash" in case current hash is not totally broken right >> >> Simo> away, but like SHA-1 gets weaker and weaker and we plan >> >> Simo> replacement. >> >> >> >> I think that the idea of combining the hash definition with the group >> >> definition is about the same as this, only a bit simpler. >> >> >> >> My ranked options are: >> >> >> >> * Combine choice of hash with choice of group (Kerberos SPAKE groups >> >> include a hash function in their definition). Requires changing the >> >> spec to restart the hash when a KDC rejects an optimistic group >> >> offer. Greg and I believe the security of this is fine. >> >> >> >> * Registering a mapping of SPAKE hashes to enctypes. The major >> >> advantage I see is that it can (I think) maintain interop with the >> >> existing protocol. The down side is that in some cases you might have >> >> to register a new enctype or except a non-ideal SPAKE hash. >> >> >> >> * Use the PRF. I think that while the concerns are real, the security >> >> is fine >> >> >> >> * Your proposal of hash in first message >> > >> > I think the above options are all fine by me, maybe not in the same >> > exact order, but they all work. >> > >> >> * Get sufficient review and make RFC 3961 hashes deterministic >> >> >> >> * Find other options >> >> >> >> * Give up on SPAKE >> > >> > I'd rather not go into the last three, but I am open to other options >> > that have substantial advantages and no big downside compared to the >> > first 4 on the table that it is worth spending time on them. >> > >> > Simo. >> > >> > -- >> > Simo Sorce >> > Sr. Principal Software Engineer >> > Red Hat, Inc >> > >> > _______________________________________________ >> > Kitten mailing list >> > Kitten@ietf.org >> > https://www.ietf.org/mailman/listinfo/kitten >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Feb 5 12:32:14 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818C8128D2E for ; Mon, 5 Feb 2018 12:32:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 8BrSFXLG0qRE for ; Mon, 5 Feb 2018 12:32:11 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 19D03127978 for ; Mon, 5 Feb 2018 12:32:10 -0800 (PST) X-AuditID: 1209190e-501ff70000005a6e-2d-5a78bf492001 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 AD.AA.23150.94FB87A5; Mon, 5 Feb 2018 15:32:10 -0500 (EST) 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 w15KW86g016733; Mon, 5 Feb 2018 15:32:09 -0500 Received: from [18.101.8.171] (VPN-18-101-8-171.MIT.EDU [18.101.8.171]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w15KW5vA007610 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 5 Feb 2018 15:32:07 -0500 From: Greg Hudson To: Sam Hartman Cc: kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> Message-ID: Date: Mon, 5 Feb 2018 15:32:05 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqreu1vyLK4GWmxde2B2wWRzevYnFg 8liy5CeTx8qpp9kDmKK4bFJSczLLUov07RK4MvZ1LGQpmCJQsWLWG/YGxuM8XYycHBICJhIL WmczdTFycQgJLGaS2D61jxHC2cAo8fXWBKjMESaJexsmMoM4wgKNjBK3309lB+lnE1CWWL9/ KwuILSKgLrH60iSwOLOAsMTyNWfZILp3Mks82zmVESTBK2Al8ezSYbAiFgEVid6ft9hAbFGB CImmmXNZIWoEJU7OfAI0lIODU8Ba4uvzSoiZ6hJ/5l1ihrDFJW49mc8EYctLbH87h3kCo+As JN2zkLTMQtIyC0nLAkaWVYyyKblVurmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWbGMGhLcm3 g3FSg/chRgEORiUeXoGMiigh1sSy4srcQ4ySHExKorypU4BCfEn5KZUZicUZ8UWlOanFhxgl OJiVRHidrpdHCfGmJFZWpRblw6SkOViUxHndTbSjhATSE0tSs1NTC1KLYLIyHBxKErxB+4CG ChalpqdWpGXmlCCkmTg4QYbzAA3/sReohre4IDG3ODMdIn+KUZfjxovXbcxCLHn5ealS4rxT QQYJgBRllObBzQGnpFSO1a8YxYHeEuaNAaniAaYzuEmvgJYwAS0JTCsFWVKSiJCSamA8sDij c/rzYkan4/wbyvTKRDMTJS/XPzD7Wf9ee8Lj86tTjAQCGd9utJlts1fJ7HnJc9HP6bpxn1l+ 95tk3PypyC6m+PCNydrX+jsYjp+uT5hyxXdxjsf0gqk//tk2zJ2Y6t/r2azyUCdP1dmGzX7r ggPHzhkkBJ1LVw9hc2g50ZZ4ce1i+blKLMUZiYZazEXFiQB6Xu2cJAMAAA== Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 20:32:12 -0000 On 02/05/2018 01:00 AM, Greg Hudson wrote: > [As the fourth field in the hash input:] > The PRF+ output used to compute the initial secret input w as > specified in [xref]. [...] > If the hash output is too small for the encryption type's key > generation seed length, the block counter value is incremented and the > hash function re-computed to produce as many blocks as are required. > The result is truncated to the key generation seed length, and the > random-to-key function is used to produce the key value. Nathaniel wrote, in a different part of the thread responding to Ben: > When > the hash is associated with the group choice, the output size of the > hash is correlated to the strength of the group used. If a new enctype > arises with stronger keys, increasing the hash alone won't increase > the security of the SPAKE exchange itself. Therefore, an entirely new > group is needed. Ben may have been thinking about the protocol working at all (easily solved by hash extension), but Nathaniel's response made me think about the possibility that the SPAKE exchange might reduce the work an attacker would require to discover the reply key, in the case where the initial reply key was high-entropy to start with. As Nathaniel notes, for this possibility we have to consider the group as well as the hash function. To make a long story short, I think to be excruciatingly correct we should compute KRB-FX-CF2 of the derived key with the initial reply key, in case w (as represented by the PRF output used to compute it) is shorter than the initial reply key was and therefore contains lower entropy. So we would have: reply-key <- KRB-FX-CF2(initial-reply-key, random-to-key(H(...|w|K|...)), pepper1, pepper2) That way we can't possibly make the reply key any worse. This is only really an issue for a future where attackers can do 2^128 brute force work (enough to break ECDLP on edwards25519 or P-256), but we may as well get it right. From nobody Mon Feb 5 13:39:24 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A8A12D969 for ; Mon, 5 Feb 2018 13:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ZcIsZqF5q5ba for ; Mon, 5 Feb 2018 13:39:18 -0800 (PST) Received: from mail-ot0-f196.google.com (mail-ot0-f196.google.com [74.125.82.196]) (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 4BEED12DA08 for ; Mon, 5 Feb 2018 13:39:18 -0800 (PST) Received: by mail-ot0-f196.google.com with SMTP id r23so26802998ote.8 for ; Mon, 05 Feb 2018 13:39:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PuREALysogA0mMrGXx1xS+DJ4arl5tTw+9N9+jo6i4Y=; b=EMfQCb/q/bC6SneybmYwDYmeabSakxbsAr8Z2zm/3E+jWypq7NOhumqPDPrkQcAOzz 6sOe/WuvcdWKX/rbLqWhQiz8pvRkEc6ib3cXv+zmxooX0+euBXhIN/RCBwCP5PLHSvrV 8u0vEqBwOP/7F/y2YnlGrX48bWqoKRvpokETje6TtiW2fH4Z9csGFUyGAgRW+PpMaHHZ 0iC7oWcfjBC48bC3WmQTiNUdk81T8wSoscGY4ySYVkWlOxacdzto9zU7KOFCTH70GoUv K1FMVHvSDJhDAprFgkpQvykwOVo/16HMzUD/XLCQ9ptOVZ1tL1YRtidMqwXmLrmZbO+i f69Q== X-Gm-Message-State: APf1xPD/tCdVmWWlHj/W2m7fJg++mgIk/oQUnDsD/vOG+Go7bVtziB64 az6ejXlMDI0vivVHg715SSUfZaMa90QrJ5X5tYYu4g== X-Google-Smtp-Source: AH8x227IHQMMQo+0myT7bPEPK2YidZL2C8VIlg+KDQgC1IRFgAJLOK/kSSmw2MNT1pTV05gel9miz2NAvWz6GM6v+jo= X-Received: by 10.157.20.231 with SMTP id r36mr164935otr.266.1517866757483; Mon, 05 Feb 2018 13:39:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.139 with HTTP; Mon, 5 Feb 2018 13:39:16 -0800 (PST) Received: by 10.157.1.139 with HTTP; Mon, 5 Feb 2018 13:39:16 -0800 (PST) In-Reply-To: References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> From: Nathaniel McCallum Date: Mon, 5 Feb 2018 16:39:16 -0500 Message-ID: To: "Hudson, Greg" Cc: Sam Hartman , kitten@ietf.org Content-Type: multipart/alternative; boundary="001a1142e8c8e583d905647de443" Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 21:39:22 -0000 --001a1142e8c8e583d905647de443 Content-Type: text/plain; charset="UTF-8" Agreed. On Feb 5, 2018 3:32 PM, "Greg Hudson" wrote: > On 02/05/2018 01:00 AM, Greg Hudson wrote: > > [As the fourth field in the hash input:] > > The PRF+ output used to compute the initial secret input w as > > specified in [xref]. > [...] > > If the hash output is too small for the encryption type's key > > generation seed length, the block counter value is incremented and the > > hash function re-computed to produce as many blocks as are required. > > The result is truncated to the key generation seed length, and the > > random-to-key function is used to produce the key value. > > Nathaniel wrote, in a different part of the thread responding to Ben: > > When > > the hash is associated with the group choice, the output size of the > > hash is correlated to the strength of the group used. If a new enctype > > arises with stronger keys, increasing the hash alone won't increase > > the security of the SPAKE exchange itself. Therefore, an entirely new > > group is needed. > > Ben may have been thinking about the protocol working at all (easily > solved by hash extension), but Nathaniel's response made me think about > the possibility that the SPAKE exchange might reduce the work an > attacker would require to discover the reply key, in the case where the > initial reply key was high-entropy to start with. As Nathaniel notes, > for this possibility we have to consider the group as well as the hash > function. > > To make a long story short, I think to be excruciatingly correct we > should compute KRB-FX-CF2 of the derived key with the initial reply key, > in case w (as represented by the PRF output used to compute it) is > shorter than the initial reply key was and therefore contains lower > entropy. So we would have: > > reply-key <- KRB-FX-CF2(initial-reply-key, > random-to-key(H(...|w|K|...)), > pepper1, pepper2) > > That way we can't possibly make the reply key any worse. This is only > really an issue for a future where attackers can do 2^128 brute force > work (enough to break ECDLP on edwards25519 or P-256), but we may as > well get it right. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --001a1142e8c8e583d905647de443 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed.

On Feb 5, 2018 3:32 PM, "Greg Hudson" <ghudson@mit.edu> wrote:
On 02/05/2018 01:00 AM, Greg Hudson = wrote:
>=C2=A0 =C2=A0[As the fourth field in the hash input:]
>=C2=A0 =C2=A0The PRF+ output used to compute the initial secret input w= as
>=C2=A0 =C2=A0specified in [xref].
[...]
>=C2=A0 =C2=A0If the hash output is too small for the encryption type= 9;s key
>=C2=A0 =C2=A0generation seed length, the block counter value is increme= nted and the
>=C2=A0 =C2=A0hash function re-computed to produce as many blocks as are= required.
>=C2=A0 =C2=A0The result is truncated to the key generation seed length,= and the
>=C2=A0 =C2=A0random-to-key function is used to produce the key value.
Nathaniel wrote, in a different part of the thread responding to Ben:
> When
> the hash is associated with the group choice, the output size of the > hash is correlated to the strength of the group used. If a new enctype=
> arises with stronger keys, increasing the hash alone won't increas= e
> the security of the SPAKE exchange itself. Therefore, an entirely new<= br> > group is needed.

Ben may have been thinking about the protocol working at all (easily
solved by hash extension), but Nathaniel's response made me think about=
the possibility that the SPAKE exchange might reduce the work an
attacker would require to discover the reply key, in the case where the
initial reply key was high-entropy to start with.=C2=A0 As Nathaniel notes,=
for this possibility we have to consider the group as well as the hash
function.

To make a long story short, I think to be excruciatingly correct we
should compute KRB-FX-CF2 of the derived key with the initial reply key, in case w (as represented by the PRF output used to compute it) is
shorter than the initial reply key was and therefore contains lower
entropy.=C2=A0 So we would have:

=C2=A0 reply-key <- KRB-FX-CF2(initial-reply-key,
=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 random-to-key(H(...|w|K|...)),
=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 pepper1, pepper2)

That way we can't possibly make the reply key any worse.=C2=A0 This is = only
really an issue for a future where attackers can do 2^128 brute force
work (enough to break ECDLP on edwards25519 or P-256), but we may as
well get it right.

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
--001a1142e8c8e583d905647de443-- From nobody Mon Feb 5 17:00:50 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9CA0126C26 for ; Mon, 5 Feb 2018 17:00:47 -0800 (PST) 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 autolearn_force=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 aOIFP8moQhL8 for ; Mon, 5 Feb 2018 17:00:32 -0800 (PST) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.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 5FC9E12DA27 for ; Mon, 5 Feb 2018 17:00:31 -0800 (PST) X-AuditID: 12074425-731ff7000000349a-0b-5a78fe2c12d9 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-8.mit.edu (Symantec Messaging Gateway) with SMTP id 69.1B.13466.D2EF87A5; Mon, 5 Feb 2018 20:00:29 -0500 (EST) 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 w1610RJk015528; Mon, 5 Feb 2018 20:00:27 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1610NY4016881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 5 Feb 2018 20:00:26 -0500 Date: Mon, 5 Feb 2018 19:00:23 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: Sam Hartman , kitten@ietf.org Message-ID: <20180206010023.GI12363@mit.edu> References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixCmqrKv7ryLK4MVMPYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGX0H5nDXPBLqGLPkb/sDYwn+LoYOTkkBEwk Pvz6ytTFyMUhJLCYSeLJlFZ2CGcDo8TbI88ZIZwzTBIb294xgrSwCKhIHJjSxgRiswHZDd2X mUFsEQFFiWer5rKA2MwCFhL3904FaxYWaGSUuP1+KjtIgldAR+Lb9FNsEFNPMktsaXnKBpEQ lDg58wlUt5bEjX8vgTZwANnSEsv/cYCEOQWsJe68usIKYosKKEvs7TvEPoFRYBaS7llIumch dC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6GXm1mil5pSuokRFKrsLqo7GOf89TrEKMDB qMTDK5BRESXEmlhWXJl7iFGSg0lJlDd1ClCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCK/T9fIo Id6UxMqq1KJ8mJQ0B4uSOK+HiXaUkEB6YklqdmpqQWoRTFaGg0NJglf2L9BQwaLU9NSKtMyc EoQ0EwcnyHAeoOGv/gDV8BYXJOYWZ6ZD5E8x6nLcePG6jVmIJS8/L1VKnLcEZJAASFFGaR7c HFCKkcjeX/OKURzoLWHecpAqHmB6gpv0CmgJE9CSwLRSkCUliQgpqQbG+fdSlmjOv3+gVLhF 9qpPqVyGiGqOxZxYTvsV8698zEmffi1ln+rKU2uf2tyKCKtbuFabqynR5/jNlZ8v/vukV8rV bXZ96szrMcbCtm+uPV94KaJkZ+r2uv/v55r/+WLT3JSd/E7a4uFGsernu4Kuaj/1OlF9YOGD mlDmj/M+T886dTRuQhJniBJLcUaioRZzUXEiAAzDVgkMAwAA Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 01:00:48 -0000 On Mon, Feb 05, 2018 at 03:32:05PM -0500, Greg Hudson wrote: > On 02/05/2018 01:00 AM, Greg Hudson wrote: > > [As the fourth field in the hash input:] > > The PRF+ output used to compute the initial secret input w as > > specified in [xref]. > [...] > > If the hash output is too small for the encryption type's key > > generation seed length, the block counter value is incremented and the > > hash function re-computed to produce as many blocks as are required. > > The result is truncated to the key generation seed length, and the > > random-to-key function is used to produce the key value. > > Nathaniel wrote, in a different part of the thread responding to Ben: > > When > > the hash is associated with the group choice, the output size of the > > hash is correlated to the strength of the group used. If a new enctype > > arises with stronger keys, increasing the hash alone won't increase > > the security of the SPAKE exchange itself. Therefore, an entirely new > > group is needed. > > Ben may have been thinking about the protocol working at all (easily > solved by hash extension), but Nathaniel's response made me think about > the possibility that the SPAKE exchange might reduce the work an > attacker would require to discover the reply key, in the case where the > initial reply key was high-entropy to start with. As Nathaniel notes, > for this possibility we have to consider the group as well as the hash > function. Right, I mean the case where the group size matches the SPAKE hash, but the enctype is bigger than both, though you have taken this even a little further than I had in mind. (But it still makes sense!) > To make a long story short, I think to be excruciatingly correct we > should compute KRB-FX-CF2 of the derived key with the initial reply key, > in case w (as represented by the PRF output used to compute it) is > shorter than the initial reply key was and therefore contains lower > entropy. So we would have: > > reply-key <- KRB-FX-CF2(initial-reply-key, > random-to-key(H(...|w|K|...)), > pepper1, pepper2) > > That way we can't possibly make the reply key any worse. This is only > really an issue for a future where attackers can do 2^128 brute force > work (enough to break ECDLP on edwards25519 or P-256), but we may as > well get it right. Yup. From nobody Tue Feb 6 06:17:48 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D67D512E042; Tue, 6 Feb 2018 06:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.03 X-Spam-Level: X-Spam-Status: No, score=-2.03 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 rbJxXNXhG6v1; Tue, 6 Feb 2018 06:17:45 -0800 (PST) Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (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 0B17E126B72; Tue, 6 Feb 2018 06:17:44 -0800 (PST) Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w16EHJTQ095389; Tue, 6 Feb 2018 14:17:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=uCi14oGA4lp7lopxft2UStqkZ8lisf33jEXQTfQ8V1I=; b=G0kRmselerGuaV21mgKaEPx+QsfTOJ0qz1PeGtrWu6bTy43vu5NPR5/vsY8nr+FTKHdR +UyeF6kvZTrrDtLWe/rqQr0dj0I/QjoAk71qPOk6NnF6Sd1QJhomQhI94C8/PPMKwKsD yEMmfKT5A/KIBDsrqU79XGkhI/kUhW1mk0Y9rejZYZk7ugni/91bsPGJVxhcDIYQUShl 22CzO56kgbpd0+UfpjX5WaqLvYA5hbzoFge415cELmNNhO+uSt6BUkpOnT4P0yuk7fRg 6ZUFZ3BupxiAqFF1YgNB9j5MYWHCyNUWDOZBFHOCYiE/P1mQoXc/XE173ZVhClZy7cdG nA== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp2130.oracle.com with ESMTP id 2fydy8r0js-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 06 Feb 2018 14:17:41 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w16EHekE027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 6 Feb 2018 14:17:41 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w16EHeRR004096; Tue, 6 Feb 2018 14:17:40 GMT Received: from [192.168.1.105] (/111.196.137.43) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 06 Feb 2018 06:17:40 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> Date: Tue, 6 Feb 2018 22:17:35 +0800 Cc: kitten , gen-art , "Joel M. Halpern" , Alissa Cooper , Greg Hudson Content-Transfer-Encoding: quoted-printable Message-Id: <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> References: <151493583156.30989.1076207750886953383@ietfa.amsl.com> <20180103013808.GG50827@kduck.kaduk.org> <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> To: draft-ietf-kitten-rfc5653bis.all@ietf.org X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8796 signatures=668662 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=14 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=955 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802060180 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:17:47 -0000 I will submit a new draft tomorrow if there is no other feedback. Thanks Weijun > On Jan 29, 2018, at 9:26 AM, Weijun Wang = wrote: >=20 > The HTML file updated in place. >=20 > Thanks > Weijun >=20 >> On Jan 27, 2018, at 10:12 AM, Greg Hudson wrote: >>=20 >> On 01/23/2018 06:43 PM, Weijun Wang wrote: >>> I've uploaded an updated version at >>>=20 >>> = http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis= -07.html >>=20 >> This is a great format for reviewing these changes; thanks for >> generating it. >>=20 >> Line 416 does not capitalize "optional" in "optional services", but >> lines 385 and 391 do. >>=20 >> Lines 422 and 424 should probably capitalize "should". Line 429 = should >> probably capitalize "may". >>=20 >> At line 598, I would lean towards leaving "MUST" in lowercase as we = are >> describing an application requirement, not prescribing one. >>=20 >> Line 1174, I would leave "MAY" in lowercase. >>=20 >> Line 1229, "may" should probably be capitalized. >>=20 >> Line 1369, I would leave "MAY" alone as this seems more descriptive = than >> prescriptive. >>=20 >> Line 3221's use of "SHOULD" is prescriptive, but there's no other way = to >> request the default QOP. So I would leave it lowercase (or change = the >> wording, but I'm not trying to open any more cans of worms). >>=20 >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Tue Feb 6 17:15:37 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC0CE1242EA for ; Tue, 6 Feb 2018 17:15:34 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 rD3d2szbvE0x for ; Tue, 6 Feb 2018 17:15:33 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 D524A12025C for ; Tue, 6 Feb 2018 17:15:32 -0800 (PST) X-AuditID: 1209190c-8b7ff70000003228-93-5a7a533240d6 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id 81.9D.12840.3335A7A5; Tue, 6 Feb 2018 20:15:31 -0500 (EST) 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 w171FSRO024728 for ; Tue, 6 Feb 2018 20:15:29 -0500 Received: from localhost (EQUAL-RITES.MIT.EDU [10.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 w171FQUO021949 for ; Tue, 6 Feb 2018 20:15:27 -0500 From: Greg Hudson To: kitten@ietf.org Date: Tue, 06 Feb 2018 20:15:26 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUixG6nomscXBVlsGy+ucXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0Xf3LGvBNO6Ku40nWBsYb3J0MXJySAiYSMy5e4y9i5GLQ0hg MZPE1X2tzBDOMUaJP/vbWCGcdiaJqU+vsoO0sAkoS6zfv5UFxBYREJbYvfUdM4gtLCAmcfXQ FSCbg4NFQFVi6nYnkDCvgKHEj2tzmSBsQYmTM5+AtTILSEgcfPGCeQIj9ywkqVlIUgsYmVYx yqbkVunmJmbmFKcm6xYnJ+blpRbpGurlZpbopaaUbmIEBQGnJM8OxjNvvA4xCnAwKvHw3lhb GSXEmlhWXJl7iFGSg0lJlDd1SkWUEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeoE1A5bwpiZVV qUX5MClpDhYlcV53E+0oIYH0xJLU7NTUgtQimKwMB4eSBO+UoKooIcGi1PTUirTMnBKENBMH J8hwHqDhtSA1vMUFibnFmekQ+VOMqhw3XrxuYxZiycvPS5US550BUiQAUpRRmgc35xWjONA7 wrynAoGyPMBIh5vwCmg4E9DwG0EglxeXJCKkpBoYFwW943/X2TVN7tKyucsd+9XXn+P78mSa d8y83wyvHiv73Hf5uHOdXPrxqHz2zel+gv413WpL7aY6P7+8IEW09tzn+uU/ZxwSndNaXiBR Of3RTomjHDY86/6+6rEOP1tpbydasc9/a8OXxZ4WN8u2iLSxuczlS+e/vePxgRVP7gqUSZ1d 3r2cVYmlOCPRUIu5qDgRAD3z2dmxAgAA Archived-At: Subject: [kitten] SPAKE pa-hint X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:15:35 -0000 Candidate draft changes here: https://github.com/greghudson/ietf/pull/5/files For convenience, here is the proposed text. Keep in mind that (as far as I know) no one currently implements RFC 6113 authentication sets, so implementations will generally ignore the new section for the time being. 10. Hint for Authentication Sets If a KDC offers SPAKE pre-authentication as part of an authentication set ([RFC6113] section 5.3), it MAY provide a pa-hint value containing the DER encoding of the ASN.1 type PA-SPAKE-HINT, to help the client determine whether SPAKE pre-authentication is likely to succeed if the authentication set is chosen. PA-SPAKE-HINT ::= SEQUENCE { groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor } The groups field indicates the KDC's supported groups. The factors field indicates the KDC's supported second factors. The KDC MAY omit the data field of values in the factors list. A KDC MUST NOT include a PA-SPAKE-HINT message in a pa-value field; hints must only be provided within authentication sets. A KDC SHOULD include a hint if SPAKE pre-authentication is offered as the second or later element of an authentication set. The PA-SPAKE-HINT message is not part of the transcript, and does not replace any part of the SPAKE message flow. From nobody Wed Feb 7 09:35:53 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEBC212D84B; Wed, 7 Feb 2018 09:35:46 -0800 (PST) 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 autolearn_force=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 urOJ7r83swWF; Wed, 7 Feb 2018 09:35:45 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 AC3C81270AE; Wed, 7 Feb 2018 09:35:44 -0800 (PST) X-AuditID: 12074424-cafff700000048fe-7b-5a7b38edf9fe 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 7C.43.18686.EE83B7A5; Wed, 7 Feb 2018 12:35:42 -0500 (EST) 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 w17HZdlc005810; Wed, 7 Feb 2018 12:35:40 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w17HZYiw029773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Feb 2018 12:35:37 -0500 Date: Wed, 7 Feb 2018 11:35:34 -0600 From: Benjamin Kaduk To: Weijun Wang Cc: draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper , Greg Hudson Message-ID: <20180207173534.GX12363@mit.edu> References: <25d5a1bb-e7bb-431b-6632-09904a581d77@joelhalpern.com> <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixCmqrfvOojrKYPkzK4vpZ/4yWiw6uo/Z 4uqrzywWH0+9YbI4unkVi8XXpRuYHdg8vjx5yeSxZMlPJo9zU74zenx8eoslgCWKyyYlNSez LLVI3y6BK6PhnXxBF3/F5j/nmRoYH3N3MXJySAiYSFxZvJ+5i5GLQ0hgMZPE4ZuLGSGcDYwS e/duhcqcYZLYdHIaE0gLi4CKxOGXnewgNhuQ3dB9mRnEFhHQkGh40ATWwCzwgFFi3udOFpCE sEC0RNvCa2wgNq+AjsT026+hVvSzSJx5fYMVIiEocXLmE7AGZgEtiRv/XgJt4wCypSWW/+MA MTkF7CTW3tYBqRAVUJbY23eIfQKjwCwkzbOQNM9CaF7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEv L7VI11wvN7NELzWldBMjKMTZXVR2MHb3eB9iFOBgVOLhnWFeHSXEmlhWXJl7iFGSg0lJlPfx wqooIb6k/JTKjMTijPii0pzU4kOMEhzMSiK87uxA5bwpiZVVqUX5MClpDhYlcV4PE+0oIYH0 xJLU7NTUgtQimKwMB4eSBO8dkD2CRanpqRVpmTklCGkmDk6Q4TxAw5eA1PAWFyTmFmemQ+RP Mepy3Hjxuo1ZiCUvPy9VSpz3A0iRAEhRRmke3BxQapLI3l/zilEc6C1hiHU8wLQGN+kV0BIm oCU3gipBlpQkIqSkGhinMkVM4omT9Ijbr3DgpLx4385lu+5pzD/2W8EjsuWRxi2RGK87vx1n qUcYhnM13dm7dHV+RJ1J0d2Sdee2fNzMNfc7H8+/jW6zUrRLDwRFhz8zq+fJVrwfanNWUMPJ NNDf5srTDveH593/PF7zVsA45PfHlODrcxI8ZxkzBdt/WfGJ3fmfn6sSS3FGoqEWc1FxIgAM vqanKAMAAA== Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 17:35:47 -0000 I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT" is all I have so far.) And I will second Greg's comment about this format being an awesome way to view these changes -- thank you again for putting them together! -Ben On Tue, Feb 06, 2018 at 10:17:35PM +0800, Weijun Wang wrote: > I will submit a new draft tomorrow if there is no other feedback. > > Thanks > Weijun > > > On Jan 29, 2018, at 9:26 AM, Weijun Wang wrote: > > > > The HTML file updated in place. > > > > Thanks > > Weijun > > > >> On Jan 27, 2018, at 10:12 AM, Greg Hudson wrote: > >> > >> On 01/23/2018 06:43 PM, Weijun Wang wrote: > >>> I've uploaded an updated version at > >>> > >>> http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html > >> > >> This is a great format for reviewing these changes; thanks for > >> generating it. > >> > >> Line 416 does not capitalize "optional" in "optional services", but > >> lines 385 and 391 do. > >> > >> Lines 422 and 424 should probably capitalize "should". Line 429 should > >> probably capitalize "may". > >> > >> At line 598, I would lean towards leaving "MUST" in lowercase as we are > >> describing an application requirement, not prescribing one. > >> > >> Line 1174, I would leave "MAY" in lowercase. > >> > >> Line 1229, "may" should probably be capitalized. > >> > >> Line 1369, I would leave "MAY" alone as this seems more descriptive than > >> prescriptive. > >> > >> Line 3221's use of "SHOULD" is prescriptive, but there's no other way to > >> request the default QOP. So I would leave it lowercase (or change the > >> wording, but I'm not trying to open any more cans of worms). > >> > > > > _______________________________________________ > > Kitten mailing list > > Kitten@ietf.org > > https://www.ietf.org/mailman/listinfo/kitten > From nobody Wed Feb 7 13:33:23 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A59D12D87B; Wed, 7 Feb 2018 13:33:05 -0800 (PST) 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 autolearn_force=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 OIpyitI13Had; Wed, 7 Feb 2018 13:33:03 -0800 (PST) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 9DB3612D864; Wed, 7 Feb 2018 13:33:02 -0800 (PST) X-AuditID: 12074423-e5dff70000000e05-5c-5a7b708beff5 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-6.mit.edu (Symantec Messaging Gateway) with SMTP id 1F.7A.03589.C807B7A5; Wed, 7 Feb 2018 16:33:00 -0500 (EST) 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 w17LWrtv020105; Wed, 7 Feb 2018 16:32:55 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w17LWn73025012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Feb 2018 16:32:51 -0500 Date: Wed, 7 Feb 2018 15:32:48 -0600 From: Benjamin Kaduk To: Weijun Wang , Greg Hudson Cc: draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper Message-ID: <20180207213248.GB12363@mit.edu> References: <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207173534.GX12363@mit.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0gTcQDH+d3dttvYxXkq+zUVYlp/rGZJUqPCLJQWPQgTokXU6U633G7j bj6mggY5apYFE9SZlmlYImQGMiuLRoaaPUASC0sihTYlE4uhkXXn8PHfFz7fB78HjlK1EjVu YZ0Mx9JWjVSBUbK0JN1VR5lxR3Bcq68b/gv0d/qfofoPoXlMPzc0g+j7H3Vg+t93u9B0qeHX ZBAxtLUtIIa3tWFgmJv6hJ3AjIp9JsZqKWK47WnnFeaX9xuAww1LZpviKsEA5QFyHJKp0N0z gXmAAqfIVgQuzrZKRECRXQAGw4YIGEZg00MfJgKMTILeJ5dkopYKurJ6BBV1DHkI1nZ2omIA JV8A2Dn+cbkpmjwD3S2jUlET5Db4ZzAsibQuoHCmNwgiIAoONkwuL6CkFo4tBREPwAUdB9uX cFHKSR0M3cwWHbFkIuyrCchuANK3LuxbF/athW8DtAMkmGylOhttsfJMro7PpVmW4XS7km0W ZzJjKuwGyxeekegHwZojAUDiQKMk6neXGSkJXcS7bAGwEUc0scS3llIjtSHHbnKZad58jiu0 MnwAQBzVxBCHjwp2wkS7ShnOvoLicEyjIgypW40UmU87mQKGcTDcCo3HcQ0klMIjU1Eck8+U 5FmszjWM4HKxXCmUP7WL5byDtvGW/AgfAjp87Pu0G6Uw1s4yahVxSjSRoslcyK72iJ8JFjwv DwGVcKxoYpEVXErhq602hYQRRBgZy3KJI056DakrgfzClejig8dDBR1+f3M4tMXwvrG5sbw3 Szk8i1tz/BNVyYqBN3VGc8WBn/dSljLoW909qotw73W9p20i01PXpz5b5d2U4J1O2e+tyPiC LLKVI58xt+zY1OPMKe2D7D2KanlF+84f9aer4rnRoneX1enX/p0snv/6Ku+1Kdu82aTBeDOd okU5nv4PZ19LzCcDAAA= Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:33:05 -0000 And the rest of the review: Line 2519, I think should --> SHOULD, since elsewhere we use SHOULD for sending the error token to the peer. Line 2561, I could go either way on "may" vs. "MAY" -- the argument for the former would be that it's just stating an attribute of the operation, and this text is describing something specified elsewhere and not introducing any restrictions or giving guidance on it. Similarly for acceptSecContext on line 2597. Line 2668, SHOULD not --> SHOULD NOT Line 2858, MAY --> may, since this is just describing what some implementations could be doing and not exactly granting permission for it. I guess for consistency I should say the same thing about line 3049. Line 3716, MUST not --> MUST NOT In general, things looked quite good; I do not think I can say thank you enough for putting this together. Greg, would you be able to sanity-check the above (and one below) comment? Thanks, Ben On Wed, Feb 07, 2018 at 11:35:34AM -0600, Benjamin Kaduk wrote: > I am doing a review now. (Line 413, "SHOULD not" --> "SHOULD NOT" > is all I have so far.) > > And I will second Greg's comment about this format being an awesome > way to view these changes -- thank you again for putting them > together! > > -Ben > > On Tue, Feb 06, 2018 at 10:17:35PM +0800, Weijun Wang wrote: > > I will submit a new draft tomorrow if there is no other feedback. > > > > Thanks > > Weijun > > > > > On Jan 29, 2018, at 9:26 AM, Weijun Wang wrote: > > > > > > The HTML file updated in place. > > > > > > Thanks > > > Weijun > > > > > >> On Jan 27, 2018, at 10:12 AM, Greg Hudson wrote: > > >> > > >> On 01/23/2018 06:43 PM, Weijun Wang wrote: > > >>> I've uploaded an updated version at > > >>> > > >>> http://cr.openjdk.java.net/~weijun/rfc5653bis/draft-ietf-kitten-rfc5653bis-07.html > > >> > > >> This is a great format for reviewing these changes; thanks for > > >> generating it. > > >> > > >> Line 416 does not capitalize "optional" in "optional services", but > > >> lines 385 and 391 do. > > >> > > >> Lines 422 and 424 should probably capitalize "should". Line 429 should > > >> probably capitalize "may". > > >> > > >> At line 598, I would lean towards leaving "MUST" in lowercase as we are > > >> describing an application requirement, not prescribing one. > > >> > > >> Line 1174, I would leave "MAY" in lowercase. > > >> > > >> Line 1229, "may" should probably be capitalized. > > >> > > >> Line 1369, I would leave "MAY" alone as this seems more descriptive than > > >> prescriptive. > > >> > > >> Line 3221's use of "SHOULD" is prescriptive, but there's no other way to > > >> request the default QOP. So I would leave it lowercase (or change the > > >> wording, but I'm not trying to open any more cans of worms). > > >> > > > > > > _______________________________________________ > > > Kitten mailing list > > > Kitten@ietf.org > > > https://www.ietf.org/mailman/listinfo/kitten > > From nobody Wed Feb 7 14:44:17 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA4F126CF9; Wed, 7 Feb 2018 14:44:12 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 EtQt15ysJpKs; Wed, 7 Feb 2018 14:44:06 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 4D8C9126C89; Wed, 7 Feb 2018 14:44:06 -0800 (PST) X-AuditID: 12074422-783ff70000004254-d9-5a7b8133a6c0 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-5.mit.edu (Symantec Messaging Gateway) with SMTP id A1.5F.16980.4318B7A5; Wed, 7 Feb 2018 17:44:04 -0500 (EST) 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 w17Mi1lW015410; Wed, 7 Feb 2018 17:44:02 -0500 Received: from [18.101.8.138] (VPN-18-101-8-138.MIT.EDU [18.101.8.138]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w17MhwXf025873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 7 Feb 2018 17:43:59 -0500 To: Benjamin Kaduk , Weijun Wang Cc: draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper References: <074DA813-1E7F-4C03-AEEE-5D76E8804C31@oracle.com> <41bbbe7d-0f35-78ad-a5cd-673488f3ac09@joelhalpern.com> <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> From: Greg Hudson Message-ID: <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> Date: Wed, 7 Feb 2018 17:43:58 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180207213248.GB12363@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAKsWRmVeSWpSXmKPExsUixCmqrGvSWB1lMOGoisX0M38ZLRYd3cds cfXVZxaLj6feMFkc3byKxeLr0g3MDmweX568ZPJYsuQnk8e5Kd8ZPT4+vcUSwBLFZZOSmpNZ llqkb5fAlfHiq2HBZY6Klg0LGBsYn7N1MXJySAiYSNw5t42li5GLQ0hgMZPE9n897BDOBkaJ 3i9voZwjTBJL5n1jB2kRFoiWaFt4DaxdRMBD4saE92DtzAIHGSXW3LnJCtExi0Vi39eXLCBV bALKEuv3bwWzeQWsJOZ8fQjWzSKgItH24CMriC0qECHRNHMuK0SNoMTJmU/A6jkFdCVO71oB tplZQF3iz7xLzBC2uMStJ/OZIGx5ie1v5zBPYBSchaR9FpKWWUhaZiFpWcDIsopRNiW3Sjc3 MTOnODVZtzg5MS8vtUjXVC83s0QvNaV0EyMoMthdlHYwTvzndYhRgINRiYd3hnl1lBBrYllx Ze4hRkkOJiVR3scLq6KE+JLyUyozEosz4otKc1KLDzFKcDArifB6+gCV86YkVlalFuXDpKQ5 WJTEeT1MtKOEBNITS1KzU1MLUotgsjIcHEoSvP4NQI2CRanpqRVpmTklCGkmDk6Q4TxAw5eA 1PAWFyTmFmemQ+RPMepy3Hjxuo1ZiCUvPy9VSpz3aT1QkQBIUUZpHtwccEJL5eh6xSgO9JYw byZIFQ8wGcJNegW0hAloyY2gSpAlJYkIKakGxtnTtS5ITLp4eI+QsfsU5Wfv/2v83c0d85Jl WYeSWPse28QpipEZRgppTypcN0RO7bni9qzn79o93xWijYKCTt3ozvuyyM34iT5TQPvDw/Uv th/gyZGLzDRiz7v6v1VazuzDi59HY5/fXLJf7ftebb8Xl4rO7ygoEZdS6zQ/vFnm0AseV9U4 diWW4oxEQy3mouJEAJjVHqRDAwAA Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:44:13 -0000 On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should --> SHOULD, since elsewhere we use SHOULD > for sending the error token to the peer. No opinion. You could make a case for "that should be sent" being either descriptive on the token or prescriptive on the application. > Line 2561, I could go either way on "may" vs. "MAY" -- the argument > for the former would be that it's just stating an attribute of the > operation, and this text is describing something specified elsewhere > and not introducing any restrictions or giving guidance on it. > Similarly for acceptSecContext on line 2597. I think that's a MAY. It seems prescriptive on the method implementation. > Line 2668, SHOULD not --> SHOULD NOT Agree. > Line 2858, MAY --> may, since this is just describing what some > implementations could be doing and not exactly granting permission > for it. Sure, and it's an example. > I guess for consistency I should say the same thing about line 3049. I guess "may" here, but no strong opinion. > Line 3716, MUST not --> MUST NOT Agree. From nobody Wed Feb 7 14:58:17 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D44126D45; Wed, 7 Feb 2018 14:58:11 -0800 (PST) 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 autolearn_force=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 BEdWjtmYnY2b; Wed, 7 Feb 2018 14:58:10 -0800 (PST) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 739FF126CD8; Wed, 7 Feb 2018 14:58:09 -0800 (PST) X-AuditID: 12074424-cafff700000048fe-78-5a7b847e7ee8 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 30.BF.18686.F748B7A5; Wed, 7 Feb 2018 17:58:07 -0500 (EST) 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 w17Mw0kJ015490; Wed, 7 Feb 2018 17:58:02 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w17Mvug8008118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 7 Feb 2018 17:57:58 -0500 Date: Wed, 7 Feb 2018 16:57:56 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: Weijun Wang , draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper Message-ID: <20180207225756.GC12363@mit.edu> References: <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixG6nrlvfUh1lsGSFicX0M38ZLRYd3cds cfXVZxaLj6feMFkc3byKxeLr0g3MDmweX568ZPJYsuQnk8e5Kd8ZPT4+vcUSwBLFZZOSmpNZ llqkb5fAlTHjoUrBOa6KL7dvMDcwzuToYuTkkBAwkbj+5BljFyMXh5DAYiaJ28t+MkE4Gxgl Tv/+wwzhnGGSWHTjIStIC4uAikTTtvNsIDYbkN3QfZkZxBYRUJR4tmouC0gDs8AHRokns+8x giSEBaIl2hZeA2vgFdCRaP7Vygox9QGzROfbuYwQCUGJkzOfsIDYzAJaEjf+vQS6gwPIlpZY /g/sVk4Ba4l71+aCzREVUJbY23eIfQKjwCwk3bOQdM9C6F7AyLyKUTYlt0o3NzEzpzg1Wbc4 OTEvL7VI11wvN7NELzWldBMjOMhdVHYwdvd4H2IU4GBU4uGdYV4dJcSaWFZcmXuIUZKDSUmU 9/HCqighvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryePkDlvCmJlVWpRfkwKWkOFiVxXg8T7Sgh gfTEktTs1NSC1CKYrAwHh5IEb3gzUKNgUWp6akVaZk4JQpqJgxNkOA/QcK4mkOHFBYm5xZnp EPlTjLocN168bmMWYsnLz0uVEuedDzJIAKQoozQPbg4oOUlk7695xSgO9JYwbzZIFQ8wscFN egW0hAloyY2gSpAlJYkIKakGxnVbLnStlOv5xbos5kFxq+t0pZ32m006wxZu7DkZfXWaubn1 yaVbdT5Nspn7k23xtR42tZ3Kd/8uP/q9icVXM+KEbNuxVu4rFkHKcUZrD2nzXTTjEJP1fe66 geWkVVhwuVo3w+ubVz7vvxD96d+HmSo3N25LZlPZ9NE+xlM+/PnTTwuWiullCSmxFGckGmox FxUnAgBTeXWoKQMAAA== Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:58:12 -0000 On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote: > On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should [line 2519] > --> SHOULD, since elsewhere we use SHOULD > > for sending the error token to the peer. > > No opinion. You could make a case for "that should be sent" being > either descriptive on the token or prescriptive on the application. Re-reading, I agree with you and retract the suggestion. > > Line 2561, I could go either way on "may" vs. "MAY" -- the argument > > for the former would be that it's just stating an attribute of the > > operation, and this text is describing something specified elsewhere > > and not introducing any restrictions or giving guidance on it. > > Similarly for acceptSecContext on line 2597. > > I think that's a MAY. It seems prescriptive on the method implementation. Okay. > > Line 2668, SHOULD not --> SHOULD NOT > > Agree. > > > Line 2858, MAY --> may, since this is just describing what some > > implementations could be doing and not exactly granting permission > > for it. > > Sure, and it's an example. > > > I guess for consistency I should say the same thing about line 3049. > > I guess "may" here, but no strong opinion. > > > Line 3716, MUST not --> MUST NOT > > Agree. Thanks for double-checking my work. -Ben From nobody Wed Feb 7 19:36:38 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECFF412D77D; Wed, 7 Feb 2018 19:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 mdLJJh0U56En; Wed, 7 Feb 2018 19:36:35 -0800 (PST) Received: from aserp2130.oracle.com (aserp2130.oracle.com [141.146.126.79]) (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 49FC11200F1; Wed, 7 Feb 2018 19:36:35 -0800 (PST) Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w183NSuX154575; Thu, 8 Feb 2018 03:36:31 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=+8mtUvpdXCIhfdMb9xWHeL+jMcew5KUZKQtrdB7smVk=; b=AIfBLSkQEoEl7Njq9Dn/JN+enVgVipUfuY3Eg6QNzjnKNmI4LTZ9Ih1oAMYcx3nuWMRu a/wC+eP1o7gmc5BFASiP6vDmeo6ckU+tgtJE0guwWgyFuw/YpaeeYHU/6dhCjfxdhwj6 0nDHlfRtHrWX6u2+CDWrIywYT7A8xvxdxzLQ616t5bsaAjlDcpdLVXS8CCh2BdZhcBOJ 2hOV7AQKKCNV8jXLTNLGlJDdozQMdTZkFR3LdOXiWYHZdFM9idJ3hQD6dN82sYT73sMs YyLv0RMu3M7HFupJIqFlPCzZcAcdb8m7coyph7i7YY6281T9K387i4Gbc+C58uIsJasI hQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2g0ekpr0sw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 08 Feb 2018 03:36:31 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w183aUY8027256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 8 Feb 2018 03:36:30 GMT Received: from abhmp0014.oracle.com (abhmp0014.oracle.com [141.146.116.20]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w183aTPv024855; Thu, 8 Feb 2018 03:36:29 GMT Received: from [192.168.1.105] (/114.250.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 07 Feb 2018 19:36:29 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <20180207225756.GC12363@mit.edu> Date: Thu, 8 Feb 2018 11:36:23 +0800 Cc: Greg Hudson , draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper Content-Transfer-Encoding: 7bit Message-Id: <933B4F63-BBDD-450D-A17A-3972F53B3EE4@oracle.com> References: <20180103030817.GH50827@kduck.kaduk.org> <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> <20180207225756.GC12363@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8798 signatures=668663 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=8 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=904 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080022 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 03:36:37 -0000 Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/. @@ -410,7 +410,7 @@ of sequence. Anonymous Authentication: The establishment of the security - context SHOULD not reveal the initiator's identity to the context + context SHOULD NOT reveal the initiator's identity to the context acceptor. Some mechanisms may not support all OPTIONAL services, and some @@ -2665,7 +2665,7 @@ ability may depend on the availability of system resources at the time that wrap is called. However, if the implementation itself imposes an upper limit on the length of messages that may be - processed by wrap, the implementation SHOULD not return a value that + processed by wrap, the implementation SHOULD NOT return a value that is greater than this length. Parameters: @@ -2855,7 +2855,7 @@ The implementation MAY constrain the set of processes by which the inter-process token may be imported, either as a function of local security policy, or as a result of implementation decisions. For - example, some implementations MAY constrain contexts to be passed + example, some implementations may constrain contexts to be passed only between processes that run under the same account, or which are part of the same process group. @@ -3046,7 +3046,7 @@ public boolean isProtReady() Returns "true" if the per-message operations can be applied over the - context. Some mechanisms MAY allow the usage of per-message + context. Some mechanisms may allow the usage of per-message operations before the context is fully established. This will also indicate that the get methods will return actual context state characteristics instead of the desired ones. @@ -3713,7 +3713,7 @@ outputToken The output token that SHOULD be sent to the peer. Can be null if no such token is available. It - MUST not be an empty array. When provided, the + MUST NOT be an empty array. When provided, the array will be cloned to protect against subsequent modifications. Thanks Weijun > On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk wrote: > > On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote: >> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should > [line 2519] >> --> SHOULD, since elsewhere we use SHOULD >>> for sending the error token to the peer. >> >> No opinion. You could make a case for "that should be sent" being >> either descriptive on the token or prescriptive on the application. > > Re-reading, I agree with you and retract the suggestion. > >>> Line 2561, I could go either way on "may" vs. "MAY" -- the argument >>> for the former would be that it's just stating an attribute of the >>> operation, and this text is describing something specified elsewhere >>> and not introducing any restrictions or giving guidance on it. >>> Similarly for acceptSecContext on line 2597. >> >> I think that's a MAY. It seems prescriptive on the method implementation. > > Okay. > >>> Line 2668, SHOULD not --> SHOULD NOT >> >> Agree. >> >>> Line 2858, MAY --> may, since this is just describing what some >>> implementations could be doing and not exactly granting permission >>> for it. >> >> Sure, and it's an example. >> >>> I guess for consistency I should say the same thing about line 3049. >> >> I guess "may" here, but no strong opinion. >> >>> Line 3716, MUST not --> MUST NOT >> >> Agree. > > Thanks for double-checking my work. > > -Ben From nobody Thu Feb 8 14:33:05 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ACC412711D; Thu, 8 Feb 2018 14:32:52 -0800 (PST) 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 autolearn_force=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 oOJ0DaNNSZle; Thu, 8 Feb 2018 14:32:49 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 0251612785F; Thu, 8 Feb 2018 14:32:48 -0800 (PST) X-AuditID: 1209190f-45fff70000000cb0-19-5a7cd00fce60 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-4.mit.edu (Symantec Messaging Gateway) with SMTP id CB.AE.03248.F00DC7A5; Thu, 8 Feb 2018 17:32:47 -0500 (EST) 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 w18MWjWW008667; Thu, 8 Feb 2018 17:32:46 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w18MWeWD020773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Feb 2018 17:32:43 -0500 Date: Thu, 8 Feb 2018 16:32:40 -0600 From: Benjamin Kaduk To: Weijun Wang Cc: Greg Hudson , draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper Message-ID: <20180208223240.GK12363@mit.edu> References: <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> <20180207225756.GC12363@mit.edu> <933B4F63-BBDD-450D-A17A-3972F53B3EE4@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <933B4F63-BBDD-450D-A17A-3972F53B3EE4@oracle.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOKsWRmVeSWpSXmKPExsUixCmqrct/oSbK4MxbG4vpZ/4yWiw6uo/Z 4uqrzywWH0+9YbI4unkVi8XXpRuYHdg8vjx5yeSxZMlPJo9zU74zenx8eoslgCWKyyYlNSez LLVI3y6BK2P/np9sBZ8VKhpnPWRqYJwp0cXIySEhYCLxqGM+YxcjF4eQwGImiY379kM5Gxgl jvSsYYVwzjBJHPr0gR2khUVARWJ39xdGEJsNyG7ovswMYosIaEg0PGhiBmlgFnjJKNH+6gtY QlggWqJt4TU2EJtXQEficdNCdoipN5glDu54zgyREJQ4OfMJC4jNLKAlcePfS6YuRg4gW1pi +T8OkDCngJ3E6YUtYHNEBZQl9vYdYp/AKDALSfcsJN2zELoXMDKvYpRNya3SzU3MzClOTdYt Tk7My0st0jXRy80s0UtNKd3ECA5zSf4djHMavA8xCnAwKvHwToipiRJiTSwrrsw9xCjJwaQk yru5FyjEl5SfUpmRWJwRX1Sak1p8iFGCg1lJhFe3GSjHm5JYWZValA+TkuZgURLndTfRjhIS SE8sSc1OTS1ILYLJynBwKEnwrj4H1ChYlJqeWpGWmVOCkGbi4AQZzgM0fAJIDW9xQWJucWY6 RP4Uoy7HjRev25iFWPLy81KlxHnXgxQJgBRllObBzQGlJ4ns/TWvGMWB3hLmnQVSxQNMbXCT XgEtYQJaciOoEmRJSSJCSqqBUeZK3T+JlJy8+4uEL39NF73B+X/rrRlfG44VHg8+eXxipL+9 7+TVbjtFJ54vCp96ykg78tiV29qKfPweM0NDMzZ9D857NvO13WbvGye7xD7dcV9u+//ozuy5 4u/ey8Ys2Gp6x2bJ3RlHb+7f/2bDps/9K1zqfi5S6rr+f/qS6b3cetHs7gefeBUpsRRnJBpq MRcVJwIAMYe8lCoDAAA= Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 22:32:52 -0000 On Thu, Feb 08, 2018 at 11:36:23AM +0800, Weijun Wang wrote: > Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/. Great! I think that once you submit the new revision, it's up to Ekr to verify that the diff addresses the point raised by Alissa/Joel and then inform the secretariat that the document is approved. Thanks again, Ben > > @@ -410,7 +410,7 @@ > of sequence. > > Anonymous Authentication: The establishment of the security > - context SHOULD not reveal the initiator's identity to the context > + context SHOULD NOT reveal the initiator's identity to the context > acceptor. > > Some mechanisms may not support all OPTIONAL services, and some > @@ -2665,7 +2665,7 @@ > ability may depend on the availability of system resources at the > time that wrap is called. However, if the implementation itself > imposes an upper limit on the length of messages that may be > - processed by wrap, the implementation SHOULD not return a value that > + processed by wrap, the implementation SHOULD NOT return a value that > is greater than this length. > > Parameters: > @@ -2855,7 +2855,7 @@ > The implementation MAY constrain the set of processes by which the > inter-process token may be imported, either as a function of local > security policy, or as a result of implementation decisions. For > - example, some implementations MAY constrain contexts to be passed > + example, some implementations may constrain contexts to be passed > only between processes that run under the same account, or which are > part of the same process group. > > @@ -3046,7 +3046,7 @@ > public boolean isProtReady() > > Returns "true" if the per-message operations can be applied over the > - context. Some mechanisms MAY allow the usage of per-message > + context. Some mechanisms may allow the usage of per-message > operations before the context is fully established. This will also > indicate that the get methods will return actual context state > characteristics instead of the desired ones. > @@ -3713,7 +3713,7 @@ > > outputToken The output token that SHOULD be sent to the peer. > Can be null if no such token is available. It > - MUST not be an empty array. When provided, the > + MUST NOT be an empty array. When provided, the > array will be cloned to protect against > subsequent modifications. > > Thanks > Weijun > > > On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk wrote: > > > > On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote: > >> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think should > > [line 2519] > >> --> SHOULD, since elsewhere we use SHOULD > >>> for sending the error token to the peer. > >> > >> No opinion. You could make a case for "that should be sent" being > >> either descriptive on the token or prescriptive on the application. > > > > Re-reading, I agree with you and retract the suggestion. > > > >>> Line 2561, I could go either way on "may" vs. "MAY" -- the argument > >>> for the former would be that it's just stating an attribute of the > >>> operation, and this text is describing something specified elsewhere > >>> and not introducing any restrictions or giving guidance on it. > >>> Similarly for acceptSecContext on line 2597. > >> > >> I think that's a MAY. It seems prescriptive on the method implementation. > > > > Okay. > > > >>> Line 2668, SHOULD not --> SHOULD NOT > >> > >> Agree. > >> > >>> Line 2858, MAY --> may, since this is just describing what some > >>> implementations could be doing and not exactly granting permission > >>> for it. > >> > >> Sure, and it's an example. > >> > >>> I guess for consistency I should say the same thing about line 3049. > >> > >> I guess "may" here, but no strong opinion. > >> > >>> Line 3716, MUST not --> MUST NOT > >> > >> Agree. > > > > Thanks for double-checking my work. > > > > -Ben > From nobody Thu Feb 8 17:19:50 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B5692120724; Thu, 8 Feb 2018 17:19:43 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151813918361.1244.11685248591965999479@ietfa.amsl.com> Date: Thu, 08 Feb 2018 17:19:43 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 01:19:44 -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 WG of the IETF. Title : Generic Security Service API Version 2: Java Bindings Update Authors : Mayank D. Upadhyay Seema Malkani Wang Weijun Filename : draft-ietf-kitten-rfc5653bis-07.txt Pages : 94 Date : 2018-02-08 Abstract: The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-07 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-rfc5653bis-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-07 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 Thu Feb 8 17:32:15 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B75120721; Thu, 8 Feb 2018 17:32:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.031 X-Spam-Level: X-Spam-Status: No, score=-2.031 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.com 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 rC8P0zuccmyY; Thu, 8 Feb 2018 17:32:11 -0800 (PST) Received: from aserp2120.oracle.com (aserp2120.oracle.com [141.146.126.78]) (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 9EA11124B17; Thu, 8 Feb 2018 17:32:11 -0800 (PST) Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w191RYDu107367; Fri, 9 Feb 2018 01:32:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2017-10-26; bh=AUoBC2Pl4KpoV/C1J0IeZqBvoj2izxszYhAnCDeiJKs=; b=qUDo5SfMTuvkcvqx1WHzDE99hBoZueH3g+6sp4psDTEsJdXKlK8HDkVIx0T9qmHAlEy6 xIbBFDbo9TpHaecVbvoj7yimj7L+bMJ0Xyv0mKyTPPm2LC04uc0C/wxenDcdSSN1cB7R D2NymeDn1St8H74mLPR162cGc7xxlNJ2NS+6isfJZAV8LHej34S5GgeUlqrr4R3NpbXD IbIqMOBP0dKDt0POg7Gl8ak6R9alF/EnRPHm48PKRoMnECuuLsuBGV/BCMFMQTEbo7/B 3C1mWdgQq/RQTyHgwUMmdWOg7Dp4ehYm+3g08opbhdMVO5/j0wyut0PgOyp09whNY1cF 5w== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2120.oracle.com with ESMTP id 2g11w5r1ad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 09 Feb 2018 01:32:08 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w191W6Ce002290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 9 Feb 2018 01:32:07 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w191W6An013337; Fri, 9 Feb 2018 01:32:06 GMT Received: from [192.168.1.105] (/114.250.155.53) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 08 Feb 2018 17:32:06 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Weijun Wang In-Reply-To: <20180208223240.GK12363@mit.edu> Date: Fri, 9 Feb 2018 09:31:59 +0800 Cc: Greg Hudson , draft-ietf-kitten-rfc5653bis.all@ietf.org, kitten , gen-art , "Joel M. Halpern" , Alissa Cooper Content-Transfer-Encoding: quoted-printable Message-Id: References: <19F5D23D-3677-41C6-B504-454C7595FF1F@cooperw.in> <366697b8-2a0c-243b-b153-ee8eb4358580@mit.edu> <8F5B79CD-B928-4B8E-97FA-D946784228B7@oracle.com> <505EACB9-D92E-4DE9-9ECC-DF931C1B924D@oracle.com> <20180207173534.GX12363@mit.edu> <20180207213248.GB12363@mit.edu> <0c34b6ba-cd35-aca5-e9d1-e15e0812413d@mit.edu> <20180207225756.GC12363@mit.edu> <933B4F63-BBDD-450D-A17A-3972F53B3EE4@oracle.com> <20180208223240.GK12363@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.5.20) X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8799 signatures=668665 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=7 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090016 Archived-At: Subject: Re: [kitten] [Gen-art] Genart telechat review of draft-ietf-kitten-rfc5653bis-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 01:32:13 -0000 https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-07 posted. Thanks Weijun > On Feb 9, 2018, at 6:32 AM, Benjamin Kaduk wrote: >=20 > On Thu, Feb 08, 2018 at 11:36:23AM +0800, Weijun Wang wrote: >> Thanks a lot. I finally make 3 s/not/NOT/ and 2 s/MAY/may/. >=20 > Great! >=20 > I think that once you submit the new revision, it's up to Ekr to > verify that the diff addresses the point raised by Alissa/Joel and > then inform the secretariat that the document is approved. >=20 > Thanks again, >=20 > Ben >=20 >>=20 >> @@ -410,7 +410,7 @@ >> of sequence. >>=20 >> Anonymous Authentication: The establishment of the security >> - context SHOULD not reveal the initiator's identity to the = context >> + context SHOULD NOT reveal the initiator's identity to the = context >> acceptor. >>=20 >> Some mechanisms may not support all OPTIONAL services, and some >> @@ -2665,7 +2665,7 @@ >> ability may depend on the availability of system resources at the >> time that wrap is called. However, if the implementation itself >> imposes an upper limit on the length of messages that may be >> - processed by wrap, the implementation SHOULD not return a value = that >> + processed by wrap, the implementation SHOULD NOT return a value = that >> is greater than this length. >>=20 >> Parameters: >> @@ -2855,7 +2855,7 @@ >> The implementation MAY constrain the set of processes by which the >> inter-process token may be imported, either as a function of local >> security policy, or as a result of implementation decisions. For >> - example, some implementations MAY constrain contexts to be passed >> + example, some implementations may constrain contexts to be passed >> only between processes that run under the same account, or which = are >> part of the same process group. >>=20 >> @@ -3046,7 +3046,7 @@ >> public boolean isProtReady() >>=20 >> Returns "true" if the per-message operations can be applied over = the >> - context. Some mechanisms MAY allow the usage of per-message >> + context. Some mechanisms may allow the usage of per-message >> operations before the context is fully established. This will = also >> indicate that the get methods will return actual context state >> characteristics instead of the desired ones. >> @@ -3713,7 +3713,7 @@ >>=20 >> outputToken The output token that SHOULD be sent to the = peer. >> Can be null if no such token is available. It >> - MUST not be an empty array. When provided, = the >> + MUST NOT be an empty array. When provided, = the >> array will be cloned to protect against >> subsequent modifications. >>=20 >> Thanks >> Weijun >>=20 >>> On Feb 8, 2018, at 6:57 AM, Benjamin Kaduk wrote: >>>=20 >>> On Wed, Feb 07, 2018 at 05:43:58PM -0500, Greg Hudson wrote: >>>> On 02/07/2018 04:32 PM, Benjamin Kaduk wrote:> Line 2519, I think = should >>> [line 2519] >>>> --> SHOULD, since elsewhere we use SHOULD >>>>> for sending the error token to the peer. >>>>=20 >>>> No opinion. You could make a case for "that should be sent" being >>>> either descriptive on the token or prescriptive on the application. >>>=20 >>> Re-reading, I agree with you and retract the suggestion. >>>=20 >>>>> Line 2561, I could go either way on "may" vs. "MAY" -- the = argument >>>>> for the former would be that it's just stating an attribute of the >>>>> operation, and this text is describing something specified = elsewhere >>>>> and not introducing any restrictions or giving guidance on it. >>>>> Similarly for acceptSecContext on line 2597. >>>>=20 >>>> I think that's a MAY. It seems prescriptive on the method = implementation. >>>=20 >>> Okay. >>>=20 >>>>> Line 2668, SHOULD not --> SHOULD NOT >>>>=20 >>>> Agree. >>>>=20 >>>>> Line 2858, MAY --> may, since this is just describing what some >>>>> implementations could be doing and not exactly granting permission >>>>> for it. >>>>=20 >>>> Sure, and it's an example. >>>>=20 >>>>> I guess for consistency I should say the same thing about line = 3049. >>>>=20 >>>> I guess "may" here, but no strong opinion. >>>>=20 >>>>> Line 3716, MUST not --> MUST NOT >>>>=20 >>>> Agree. >>>=20 >>> Thanks for double-checking my work. >>>=20 >>> -Ben >>=20 From nobody Thu Feb 8 18:21:49 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75C2126DD9 for ; Thu, 8 Feb 2018 18:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 YEWEfrM3C4Yf for ; Thu, 8 Feb 2018 18:21:46 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 065FB126CF9 for ; Thu, 8 Feb 2018 18:21:45 -0800 (PST) X-AuditID: 1209190e-6d7ff700000013d1-67-5a7d05b72230 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-3.mit.edu (Symantec Messaging Gateway) with SMTP id DF.3B.05073.8B50D7A5; Thu, 8 Feb 2018 21:21:44 -0500 (EST) 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 w192Ldo3031977; Thu, 8 Feb 2018 21:21:41 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w192LaKD032178 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Feb 2018 21:21:38 -0500 Date: Thu, 8 Feb 2018 20:21:36 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20180209022135.GN12363@mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6noruDtTbK4MAkfYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoErY9KCFpaCB3wVZ26uZWlgPMzdxcjJISFgInG14z57FyMXh5DA YiaJv9t2QTkbGCW65j1ihXDOMEksm9fIAtLCIqAisfXXbkYQmw3Ibui+zAxiiwgoSjxbNRes hllAWGL5mrNsILawgLLE3OcTwOp5BXQkrnX9Y+pi5AAaaijxt6EOIiwocXLmE6hWLYkb/16C lTALSEss/8cBYnIKGEm8veIJUiEKNHBv3yH2CYwCs5A0z0LSPAuheQEj8ypG2ZTcKt3cxMyc 4tRk3eLkxLy81CJdY73czBK91JTSTYygcOSU5NvBOKnB+xCjAAejEg/vhJiaKCHWxLLiytxD jJIcTEqivJt7gUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeHWbgXK8KYmVValF+TApaQ4WJXFe dxPtKCGB9MSS1OzU1ILUIpisDAeHkgTva5baKCHBotT01Iq0zJwShDQTByfIcB6g4XeZgWp4 iwsSc4sz0yHypxh1OW68eN3GLMSSl5+XKiXOawoySACkKKM0D24OKI1IZO+vecUoDvSWMO8/ kCoeYAqCm/QKaAkT0JIbQZUgS0oSEVJSDYwP6opUqw70dn1mLGEVPCLgyrnddo25o5wT+w3p v7N8GWOL9YzZsg/uV1rwWp2/rbgh2ZXPXfSrb5rgudQZj6w2Pkta4hn1JVY4cee1bwvj/bMd j4qsmxlntXKpou2V9VVMZ4XvZmRy/8+ftVZ+w+xFeZc0TlhKvTjbL3DROunu+Sy5/IlK4kos xRmJhlrMRcWJAFytfmn+AgAA Archived-At: Subject: Re: [kitten] SPAKE pa-hint X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 02:21:48 -0000 On Tue, Feb 06, 2018 at 08:15:26PM -0500, Greg Hudson wrote: > Candidate draft changes here: > https://github.com/greghudson/ietf/pull/5/files > > For convenience, here is the proposed text. Keep in mind that (as far > as I know) no one currently implements RFC 6113 authentication sets, so > implementations will generally ignore the new section for the time > being. > > 10. Hint for Authentication Sets > > If a KDC offers SPAKE pre-authentication as part of an authentication > set ([RFC6113] section 5.3), it MAY provide a pa-hint value > containing the DER encoding of the ASN.1 type PA-SPAKE-HINT, to help > the client determine whether SPAKE pre-authentication is likely to > succeed if the authentication set is chosen. > > PA-SPAKE-HINT ::= SEQUENCE { > groups [0] SEQUENCE (SIZE(1..MAX)) OF Int32, > factors [1] SEQUENCE (SIZE(1..MAX)) OF SPAKESecondFactor > } Do we need to repeat and/or modify the security considerations text about unauthenticated plaintext in the factors portion of a challenge with respect to the pa-hint contents? -Ben > The groups field indicates the KDC's supported groups. The factors > field indicates the KDC's supported second factors. The KDC MAY omit > the data field of values in the factors list. > > A KDC MUST NOT include a PA-SPAKE-HINT message in a pa-value field; > hints must only be provided within authentication sets. A KDC SHOULD > include a hint if SPAKE pre-authentication is offered as the second > or later element of an authentication set. > > The PA-SPAKE-HINT message is not part of the transcript, and does not > replace any part of the SPAKE message flow. > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Feb 8 21:31:32 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6D9F127873 for ; Thu, 8 Feb 2018 21:31:31 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 ZgR6kISn5o4g for ; Thu, 8 Feb 2018 21:31:30 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 3FAA4126D45 for ; Thu, 8 Feb 2018 21:31:29 -0800 (PST) X-AuditID: 1209190d-f45ff700000013bf-21-5a7d32300bb1 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 07.52.05055.0323D7A5; Fri, 9 Feb 2018 00:31:29 -0500 (EST) 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 w195VNnr017728; Fri, 9 Feb 2018 00:31:25 -0500 Received: from [18.101.8.145] (VPN-18-101-8-145.MIT.EDU [18.101.8.145]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w195VLnQ022613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 9 Feb 2018 00:31:23 -0500 To: Benjamin Kaduk Cc: kitten@ietf.org References: <20180209022135.GN12363@mit.edu> From: Greg Hudson Message-ID: <786c256d-980d-6857-0390-67c5542319d2@mit.edu> Date: Fri, 9 Feb 2018 00:31:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180209022135.GN12363@mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupileLIzCtJLcpLzFFi42IRYrdT0TU0qo0ymDeL3eLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK6DpdUNDNVrH97k/GBsa3LF2MnBwSAiYSf7t6mLoYuTiEBBYz SXyedQDK2cAo0fn7LwuEc4RJYvq812AtwgLKEnOfT2AEsUUElCQWn21hA7GZBYQllq85C2YL CYRItL5aBWazAdWv378VqJeDg1fASmLSNQWQMIuAisTzm5tZQWxRgQiJpplzwWxeAUGJkzOf gJVzCuhKzHrlATFdXeLPvEvMELa4xK0n85kgbHmJ7W/nME9gFJyFpHsWkpZZSFpmIWlZwMiy ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdILzezRC81pXQTIyiAOSV5dzD+u+t1iFGAg1GJh3dC TE2UEGtiWXFl7iFGSQ4mJVHezb1AIb6k/JTKjMTijPii0pzU4kOMEhzMSiK8us1AOd6UxMqq 1KJ8mJQ0B4uSOK+7iXaUkEB6YklqdmpqQWoRTFaGg0NJgjfQsDZKSLAoNT21Ii0zpwQhzcTB CTKcB2j4NwOgGt7igsTc4sx0iPwpRmOOtpVP2pg5brx43cYsxJKXn5cqJc57BaRUAKQ0ozQP bho4CaVyTHzFKA70nDCvGMhSHmACg5v3CmgVE9CqG0GVIKtKEhFSUg2MHfZ9/bGCOW5S9hcs rqTzcR7sj/8/lTc+6uKc90ysD9Tl/nV2Np1tFy+/eLJpq+tCzX0CUg1dlr7umzzFM25Yxcw4 veV65qNrNV/0FUKjHqzSUM7Zb7Nh7ersCDce+eviojffv35dvsSDI+ODw8nXVla5FR3XFwsW ed9cfmD9hDfXek8XPniuxFKckWioxVxUnAgAHlOjmx0DAAA= Archived-At: Subject: Re: [kitten] SPAKE pa-hint X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 05:31:32 -0000 On 02/08/2018 09:21 PM, Benjamin Kaduk wrote:> Do we need to repeat and/or modify the security considerations text > about unauthenticated plaintext in the factors portion of a > challenge with respect to the pa-hint contents? Proposed text, adding a fourth paragraph to the unauthenticated plaintext subsection: Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE is advertised in authentication sets are unauthenticated, and are not protected by the transcript hash. Since hints do not replace any part of the message flow, manipulation of hint messages can only affect the client's decision to use or not use an authentication set, which could more easily be accomplished by removing authentication sets entirely. From nobody Fri Feb 9 10:12:03 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009BE120454 for ; Fri, 9 Feb 2018 10:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=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 8T23Mnvjl1Id for ; Fri, 9 Feb 2018 10:12:00 -0800 (PST) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (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 7D7771201F8 for ; Fri, 9 Feb 2018 10:12:00 -0800 (PST) X-AuditID: 1209190e-271ff700000028f3-f5-5a7de46e9551 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 B6.E6.10483.E64ED7A5; Fri, 9 Feb 2018 13:11:58 -0500 (EST) 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 w19IBv7B022172; Fri, 9 Feb 2018 13:11:57 -0500 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w19IBsdW013653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Feb 2018 13:11:56 -0500 Date: Fri, 9 Feb 2018 12:11:54 -0600 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20180209181153.GR12363@mit.edu> References: <20180209022135.GN12363@mit.edu> <786c256d-980d-6857-0390-67c5542319d2@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <786c256d-980d-6857-0390-67c5542319d2@mit.edu> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixCmqrJv3pDbK4PoGLYujm1exODB6LFny kymAMYrLJiU1J7MstUjfLoEr43XjZ6aCDvaKdat5GhiPsHYxcnJICJhIrPz2A8jm4hASWMwk sevMSxaQhJDABkaJlw3WEIkzTBJ7Xu9hB0mwCKhIrGk9BlbEBmQ3dF9mBrFFBBQlnq2aCxZn FhCWWL7mLBuILSygLDH3+QRGEJtXQEfi4r4/TBBDWxkllvz4xAqREJQ4OfMJVLOWxI1/L4GK OIBsaYnl/zhAwpwC1hLzH7wAu0EUaObevkPsExgFZiHpnoWkexZC9wJG5lWMsim5Vbq5iZk5 xanJusXJiXl5qUW6xnq5mSV6qSmlmxjBASnJt4NxUoP3IUYBDkYlHt6ElbVRQqyJZcWVuYcY JTmYlER5188CCvEl5adUZiQWZ8QXleakFh9ilOBgVhLhvbwCKMebklhZlVqUD5OS5mBREud1 N9GOEhJITyxJzU5NLUgtgsnKcHAoSfB+eQTUKFiUmp5akZaZU4KQZuLgBBnOAzQ88DHI8OKC xNzizHSI/ClGY462lU/amDluvHjdxizEkpeflyolzhsGUioAUppRmgc3DZRUJLL317xiFAd6 TphXD6SKB5iQ4Oa9AlrFBLTqrgPYqpJEhJRUA6Mhv55C02P7DxueWdUl6e7ednn27icPYmcc VH3t8sk4ndt7toj5ArlbS3a/3XAx6Lbe978tzvVnTXJa/92tvBhRYnXmy+tVi1f2PnrUum6f YV9I3PTfDzf75ZgZ/tCzZKvbqcg+Z5N/6PTW38XzGZbwH7M6Nqvjg/ee3G27Wx9snWp+b2GE y6YLSizFGYmGWsxFxYkA1roejgUDAAA= Archived-At: Subject: Re: [kitten] SPAKE pa-hint X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 18:12:02 -0000 On Fri, Feb 09, 2018 at 12:31:21AM -0500, Greg Hudson wrote: > On 02/08/2018 09:21 PM, Benjamin Kaduk wrote:> Do we need to repeat > and/or modify the security considerations text > > about unauthenticated plaintext in the factors portion of a > > challenge with respect to the pa-hint contents? > > Proposed text, adding a fourth paragraph to the unauthenticated > plaintext subsection: > > Unless FAST is used, any PA-SPAKE-HINT messages included when SPAKE > is advertised in authentication sets are unauthenticated, and are not > protected by the transcript hash. Since hints do not replace any > part of the message flow, manipulation of hint messages can only > affect the client's decision to use or not use an authentication set, > which could more easily be accomplished by removing authentication > sets entirely. Sounds good. Thanks! -Ben From nobody Sat Feb 10 08:30:08 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71235126C0F; Sat, 10 Feb 2018 08:30:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151828020643.27636.3865906773469312871@ietfa.amsl.com> Date: Sat, 10 Feb 2018 08:30:06 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-05.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2018 16:30:06 -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 WG of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-05.txt Pages : 35 Date : 2018-02-10 Abstract: This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-05 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-05 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 Mon Feb 12 06:35:05 2018 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 67DE71270FC; Mon, 12 Feb 2018 06:34:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Cc: mrogers@redhat.com, The IESG , ekr@rtfm.com, draft-ietf-kitten-rfc5653bis@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <151844609542.6145.6075433862133716740.idtracker@ietfa.amsl.com> Date: Mon, 12 Feb 2018 06:34:55 -0800 Archived-At: Subject: [kitten] Protocol Action: 'Generic Security Service API Version 2: Java Bindings Update' to Proposed Standard (draft-ietf-kitten-rfc5653bis-07.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 14:34:55 -0000 The IESG has approved the following document: - 'Generic Security Service API Version 2: Java Bindings Update' (draft-ietf-kitten-rfc5653bis-07.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Kathleen Moriarty and Eric Rescorla. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ Technical Summary This document is a Proposed Standard to update RFC 5653 (Generic Security Service API Version 2 : Java Bindings Update). This document addresses a flaw in RFC 5653 by extending the GSSException class with an error token, as well as removing the specification of stream-based GSSContext methods. Working Group Summary There is consensus among the WG for this document, and it saw active discussion and review by WG members. As a ‘bis’ document, all errata have been considered. Concerns about the design of the stream-based GSSContext methods were brought up and addressed during the WG Last Call process and there was agreement on their removal from the document. Document Quality See above. Personnel Matt Rogers is the Document Shepherd. Eric Rescorla is the Responsible Area Director. From nobody Tue Feb 13 06:17:56 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1864C12EA7F for ; Tue, 13 Feb 2018 06:17:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.646 X-Spam-Level: * X-Spam-Status: No, score=1.646 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=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 v0ZS1cYRch5F for ; Tue, 13 Feb 2018 06:17:54 -0800 (PST) Received: from mail.suchdamage.org (ec2-52-9-186-167.us-west-1.compute.amazonaws.com [52.9.186.167]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D95012EA90 for ; Tue, 13 Feb 2018 06:17:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.suchdamage.org (Postfix) with ESMTP id CFBC229BDF; Tue, 13 Feb 2018 09:17:52 -0500 (EST) Received: from mail.suchdamage.org ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rA_LBNvV8P8; Tue, 13 Feb 2018 09:17:52 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-174-63-85-75.hsd1.ma.comcast.net [174.63.85.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by mail.suchdamage.org (Postfix) with ESMTPSA; Tue, 13 Feb 2018 09:17:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 99ECDC5D61; Tue, 13 Feb 2018 09:17:50 -0500 (EST) From: Sam Hartman To: Nathaniel McCallum Cc: "Hudson\, Greg" , Sam Hartman , kitten@ietf.org References: <5777908c-6752-e623-d25d-3b5b23bcbda4@mit.edu> <7d4423be-7737-b97f-ba6c-92e4552804f3@mit.edu> <1517436654.13097.119.camel@redhat.com> <1517494211.13097.121.camel@redhat.com> <8f688cc7-45a7-815c-2c4e-27ffd1197b0e@mit.edu> Date: Tue, 13 Feb 2018 09:17:50 -0500 In-Reply-To: (Nathaniel McCallum's message of "Mon, 5 Feb 2018 16:39:16 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [kitten] SPAKE hash function associated with group (was Re: Concerns about draft-ietf-kitten-krb-spake-preauth-04) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 14:17:55 -0000 >>>>> "Nathaniel" == Nathaniel McCallum writes: Nathaniel> Agreed. The changes, including the discussion of using krb-fx-cf2 to protect initial high-entropy reply keys. I agree that high entropy reply keys are unlikely in cases where SPAKE is valuable, but it's relatively easy to do. From nobody Tue Feb 13 07:11:40 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D436126C2F for ; Tue, 13 Feb 2018 07:11:39 -0800 (PST) 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 autolearn_force=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 yMJCdK2lWzlK for ; Tue, 13 Feb 2018 07:11:37 -0800 (PST) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (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 3D578126BF0 for ; Tue, 13 Feb 2018 07:11:37 -0800 (PST) X-AuditID: 1209190f-36bff70000000d09-fe-5a8300276a24 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 31.CD.03337.720038A5; Tue, 13 Feb 2018 10:11:36 -0500 (EST) 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 w1DFBWJV004212 for ; Tue, 13 Feb 2018 10:11:33 -0500 Received: from localhost (EQUAL-RITES.MIT.EDU [10.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 w1DFBUea004088 for ; Tue, 13 Feb 2018 10:11:31 -0500 From: Greg Hudson To: kitten@ietf.org Date: Tue, 13 Feb 2018 10:11:29 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsUixG6noqvB0BxlsGEhs8XRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8aXZuGCNTMW+1TdYGhiviXUxcnJICJhIfJv8jLWLkYtDSGAx k8SS2e3sEM5xRolpX64zQjgdTBJ39zxlB2lhE1CWWL9/KwuILSIgLLF76ztmEFtYQFLiestN NhCbRUBV4vXZz2A1vAKGEhfmv2eGsAUlTs58AhZnFpCQOPjiBfMERu5ZSFKzkKQWMDKtYpRN ya3SzU3MzClOTdYtTk7My0st0jXRy80s0UtNKd3ECAoCTkn+HYxzGrwPMQpwMCrx8G541RQl xJpYVlyZe4hRkoNJSZSX+T9QiC8pP6UyI7E4I76oNCe1+BCjBAezkghvwn2gHG9KYmVValE+ TEqag0VJnNfdRDtKSCA9sSQ1OzW1ILUIJivDwaEkwSsLMlSwKDU9tSItM6cEIc3EwQkynAdo uBpIDW9xQWJucWY6RP4UozZH04MHbcwcN168bmMWYsnLz0uVEudNASkVACnNKM2Dm/aKURzo KWFeAZAsDzDq4ea8AlrBBLRCV7sRZEVJIkJKqoFR4ZkJK+uRuPCa8m6ehRMWW8k7rV9mzbz0 QdUu/hcNUyqV++teylt5PjGpZjY9UiNhOqUq6FzvztwIXfYlL39+3a8WYFB6vtlD/MIdC76v DIfs3tvFGn3365RpiDNN2HD3kt6Z5/YhbVF/5nl76xkmyP/vP7GI99Cpc9LTAgsYXZcWC+5z u6XEUpyRaKjFXFScCADtowG0twIAAA== Archived-At: Subject: [kitten] etype-info notes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 15:11:39 -0000 I am mostly sending these notes for archival, although they might be of interest to some Kerberos implementors. There are two PKINIT interop notes mentioned within. etype-info (PA-ETYPE-INFO and/or PA-ETYPE-INFO2) may appear in a preauth error or in an AS-REP. It is intended to give the client the information it needs to turn a password into an RFC 3961 key. In the context of RFC 4120, etype-info in a PREAUTH_REQUIRED error is described as informing encrypted timestamp. etype-info in an AS-REP is described as informing the client of string-to-key parameters for the reply key. If AS-REP etype-info is sent, "there shall be exactly one ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in the AS-REP". There aren't any cases in RFC 4120 where the reply key is replaced, so there is no discussion of whether there should be AS-REP etype-info in that situation or what it should contain. RFC 4556 (PKINIT) replaces the reply key. It does not mention etype-info at all, as PKINIT makes no use of string-to-key or client long-term keys. If Diffie-Hellman is used, the enctype of the new reply key is selected "according to [RFC4120]". I'm not sure what that should mean, but a reasonable interpretation is the first request enctype which the KDC implements. Interop note #1: if the client has any long-term keys, the MIT krb5 KDC sends etype-info in the AS-REP with the enctype of the new reply key, but salt information from a client long-term key. This mixture is nonsensical, but mostly harmless since the client won't perform any string-to-key operations. Interop note #2: the MIT krb5 PKINIT client code should use the AS-REP enc-part enctype to generate the reply key. Instead it relies on etype-info in the AS-REP. If there is no etype-info in the AS-REP, it uses etype-info from a previous KDC message, or it assumes the first request enctype (which is usually correct, but not guaranteed to be). I hope to fix this bug for 1.17 but haven't done so yet. RFC 6113 more formally introduces the concepts of the initial reply key and replacing or strengthening it. It says that etype-info in preauth errors allows the client to determine the initial reply key (or a set of them), and suggests that KDCs send only one etype-info element based on the negotiated enctype so that there can be exactly one initial reply key. There is no new discussion of etype-info in AS-REP, so the RFC 4120 restriction on AS-REP etype-info (one element matching the AS-REP enc-part, if any is sent at all) would seem to stand. The inability of AS-REP etype-info to describe the initial reply key could present an obstacle to some hypothetical extensions. For example, here is a dummy forward secrecy extension using Diffie-Hellman (finite field or DH; g is the generator and multiplication is within some DH group): 1. The client generates x and sends gx in a pa-data element in every AS request. 2. In the AS-REP, the KDC generates y and sends gy in an AS-REP pa-data element. Both sides compute gxy and strengthen the reply key using the result. During this strengthening the reply key is upgraded to the first requested enctype implemented by the KDC. If no preauth is used, the KDC never gets a chance to describe the initial reply key in etype-info. Such an extension would have to respecify what goes into AS-REP etype-info, or abandon upgrading the enctype in strengthening so that the AS-REP etype-info can describe the initial reply key without violating the RFC 4120 restriction. From nobody Tue Feb 13 13:19:36 2018 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 692B812D949 for ; Tue, 13 Feb 2018 13:19:35 -0800 (PST) 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=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 UX4DFFVng34v for ; Tue, 13 Feb 2018 13:19:34 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 CDEDA12D948 for ; Tue, 13 Feb 2018 13:19:33 -0800 (PST) X-AuditID: 1209190c-e1fff70000006fdf-9d-5a8356638f53 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-1.mit.edu (Symantec Messaging Gateway) with SMTP id CC.BB.28639.366538A5; Tue, 13 Feb 2018 16:19:32 -0500 (EST) 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 w1DLJSFY017073 for ; Tue, 13 Feb 2018 16:19:29 -0500 Received: from [18.101.8.167] (VPN-18-101-8-167.MIT.EDU [18.101.8.167]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w1DLJQ2M012958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Tue, 13 Feb 2018 16:19:27 -0500 From: Greg Hudson To: kitten@ietf.org References: Message-ID: <3a9bba21-cd78-71b2-7b09-04a9a29dd94d@mit.edu> Date: Tue, 13 Feb 2018 16:19:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPIsWRmVeSWpSXmKPExsUixG6nrpsS1hxlMHezsMXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8WRdA3vBT9aKH7e3sDQw3mDpYuTkkBAwkXjZ8Yy5i5GLQ0hg MZPE0edTwBJCAscZJf7/tIJI3GaSuPT5EBtIQlhATeLIspVgNpuAssT6/VvBGkQEhCV2b33H DNFsKPHqwQmwGl4BK4lHXatYuxg5OFgEVCVub8oGCYsKREg0zZzLClEiKHFy5hOwMZwCRhLv /v4Ca2UWUJf4M+8SM4QtLnHryXwmCFteYvvbOcwTGAVmIWmfhaRlFpKWWUhaFjCyrGKUTcmt 0s1NzMwpTk3WLU5OzMtLLdI11MvNLNFLTSndxAgKVU5Jnh2MZ954HWIU4GBU4uHd8KopSog1 say4MvcQoyQHk5IoL/N/oBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3oT7QDnelMTKqtSifJiU NAeLkjivu4l2lJBAemJJanZqakFqEUxWhoNDSYL3aWhzlJBgUWp6akVaZk4JQpqJgxNkOA/Q 8BaQGt7igsTc4sx0iPwpRmOOtpVP2pg5brx43cYsxJKXn5cqJc47H6RUAKQ0ozQPbho43aRy LH/FKA70nDCvF0gVDzBVwc17BbSKCWiVrnYjyKqSRISUVAPj8SVRz/dJNc1oVo6NvpHMlzrJ tPJdw/H9q+POf0+btvFsYvG5g4b3N4cdPtlRpeWmc5zzlcxBzTMCPRt1fFXq3tzwvLjuH/Px uQxve6adEp1Q4v5zd3Ks3Nq+vj2e4kwc1zIeLZeMPyFp5GXG915b9srux9fmLTkV7VJSsffO sdibkXPfPNzAosRSnJFoqMVcVJwIAP8GcacSAwAA Archived-At: Subject: Re: [kitten] etype-info notes X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Feb 2018 21:19:35 -0000 On 02/13/2018 10:11 AM, Greg Hudson wrote: > Interop note #2: the MIT krb5 PKINIT client code should use the AS-REP > enc-part enctype to generate the reply key. Instead it relies on > etype-info in the AS-REP. If there is no etype-info in the AS-REP, it > uses etype-info from a previous KDC message, or it assumes the first > request enctype (which is usually correct, but not guaranteed to be). > I hope to fix this bug for 1.17 but haven't done so yet. On further investigation, it appears I was partly wrong about this. The MIT krb5 PKINIT client will correctly use AS-REP enc-part enctype unless the KDC sends a different enctype in etype-info in the AS-REP (which would be in violation of RFC 4120). Apologies for the noise.