From nobody Thu Apr 4 16:59:10 2019 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 B544D1200CE; Thu, 4 Apr 2019 16:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Ev4smPVA9XiK; Thu, 4 Apr 2019 16:59:07 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 0858A120295; Thu, 4 Apr 2019 16:59:03 -0700 (PDT) Received: from kduck.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.14.7/8.12.4) with ESMTP id x34NwxOn023098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 4 Apr 2019 19:59:01 -0400 Date: Thu, 4 Apr 2019 18:58:59 -0500 From: Benjamin Kaduk To: draft-ietf-kitten-krb-spake-preauth.all@ietf.org Cc: kitten@ietf.org Message-ID: <20190404235859.GM54777@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 23:59:10 -0000 In general this document is in good shape, but the elephant in the room is the state of the dependency draft-irtf-cfrg-spake2, which is apparently not as stable as we thought. It seems likely that we'll need to wait until that document is further along before we can finalize our revisions to this document and go to IETF LC; furthermore, I expect we'll want to reissue some codepoints so that the current meanings stay valid (tied to draft-irtf-cfrg-06's behavior) and the new codepoints match the RFC version of the CFRG spec. (Except when we consciously diverge, as for the transcript hash, etc.) In particular I think we will need to allocate a new PA-SPAKE value. (I don't think I see a reason to allocate a new KEY_USAGE_SPAKE value.) Some section-by-section comments follow. -Ben Section 1.1 Password authenticated key exchange (PAKE) algorithms provide several properties which are useful to overcome this problem and make them ideal for use as a Kerberos pre-authentication mechanism. We should probably expand out "this problem": offline dictionary attacks. Section 1.2 2. It can compute the shared key after just one message from each party. I guess we could say a little more about why this is useful (reduced state on KDC, reduce number of round-trips, etc.) Section 1.3 We may want to give the reader a bit more help in here: Using PAKE in a pre-authentication mechanism also has another benefit when used as a component of two-factor authentication (2FA). 2FA methods often require the secure transfer of plaintext material to the KDC for verification. This includes one-time passwords, challenge/response signatures and biometric data. Attempting to encrypt this data using the long-term secret results in packets that are vulnerable to offline brute-force attack if either authenticated encryption is used or if the plaintext is distinguishable from random (because it gives the attacker an authentication tag for offline attack) data. This is a problem that PAKE solves for first factor (because brute-force attack on the ciphertext yields a success result when the underlying structure is correct) We probably want to be more specific about what "this" is that is a problem. authentication. So a similar technique can be used with PAKE to encrypt second-factor data. I'm not sure if "similar technique can be used with PAKE" is the right phrasing. It's similar in that we add onto the PAKE, but it's only sort of used *with* in that sense. These requirements lead to a scenario where FAST cannot be enabled by default without sufficient configuration. [...] We leave it pretty vague about what "sufficient configuration" is. Isn't the point that coordination with the realm administrator or some similar authority is needed in order to use FAST by default on a given system? Section 1.4 Higher level protocols must define their own verification step. In This is a requirement from the SPAKE spec, not one we introduce here. So we probably want to say something like "SPAKE requires that higher level protocols [...]". the case of this mechanism, verification happens implicitly by a successful decryption of the 2FA data. I'd consider adding a note here that "a placeholder second-factor is allocated to provide key confirmation when no actual second factor is available", though I'm not 100% sure it's needed. Section 2 RFC 8174 has an updated version of the BCP 14 boilerplate text to use (and every subsequent reviewer that looks at this document will tell you about it if you don't fix it beforehand). Section 3.1 This mechanism requires the initial KDC pre-authentication state to contain a singular reply key. Therefore, a KDC which offers SPAKE pre-authentication as a stand-alone mechanism MUST supply a PA-ETYPE- INFO2 value containing a single ETYPE-INFO2-ENTRY, as described in [RFC6113] section 2.1. [...] RFC 6113 section 2.1 doesn't specifically talk about ETYPE-INFO2-ENTRYs at all, and is instead using a little more abstract language. So perhaps we want something like "following the guidance in" to keep our language precise. Section 4.2 The pubkey field indicates the KDC's public key generated using the M constant in the SPAKE algorithm, with inputs and conversions as specified in Section 5. I think I want something more concretely tying this to the OCTET STRING representation of the ASN.1 element, perhaps "conversions to and from OCTET STRING form". The data field contains optional challenge data. The contents in this field will depend upon the second factor type chosen. I'd suggest a forward reference to the security considerations here, noting that when these are being processed they are unauthenticated plaintext. Section 4.3 Do we need to say that the 'kvno' field of the EncryptedData is absent (here and elsewhere)? The client and KDC will update the transcript hash with the pubkey value, and use the resulting hash for all encryption key derivations. Isn't it the whole message and not just the pubkey value? Section 4.6 If the KDC cannot continue with SPAKE (either because initial reply key type is incompatible with SPAKE or because it does not support any of the client's groups) but can offer other pre-authentication mechanisms, it MUST respond with a KDC_ERR_PREAUTH_FAILED error containing METHOD-DATA. [...] (appropriate for the mechanisms in question?) Section 5 1. Determine the length of the multiplier octet string as defined in the IANA "Kerberos SPAKE Groups" registry created by this document. If this multiplier length ended up being smaller than the key width for the initial reply key, it seems like we'd end up losing security strength. Should we mention this in the considerations for new registrations in the IANA section? 2. Compose a pepper string by concatenating the string "SPAKEsecret" and the group number as a big-endian four-byte two's complement binary number. In a very general sense, we get better prefix isolation if we include the trailing NUL as a separator, but that's a gratuitously breaking change that we shouldn't make in the absence of other breaking changes. (Which, well, we are kind of looking at anyway...) Section 6 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 (Section 7). I might go so far as to explicitly say "In particular, subsequent encrypted second-factor exchanges are not included in the transcript used for key derivation.", though it may be overkill. Section 7 First, the hash function associated with the selected group is computed over the concatenation of the following values: Do we want to include the client/server principal names here as well, as suggested by draft-irtf-cfrg-spake2-08? o The fixed string "SPAKEkey". (Same as above about NUL separator.) o The SPAKE result K, converted to an octet string as specified in Section 5. I failed to convince myself that I saw where this conversion was specified in Section 5. Could you help me out? Section 9 A KDC MUST NOT include a PA-SPAKE-HINT message in a pa-value field; Do we want to say "directly in"? Section 10 All of the security considerations from SPAKE [I-D.irtf-cfrg-spake2] apply here as well. Editorially speaking, it might be nice to the reader to say "Additional considerations specific to this document are discussed in the following subsections". One potential additional consideration to note is that the encdata choice does not indicate which party is sending it so we have to consider the risk of reflection attacks wherein a message is replayed to a party that should have sent it instead of receiving it. I think we're safe since each party will only attempt to use even or odd numbers in the K'[x] hierarchy for decryption and thus avoid using the wrong plaintext, but it's probably worth a mention. Section 10.1 The KDC-REQ-BODY contents are also incorporated into key derivation, ensuring their integrity. The unauthenticated plaintext in the KDC-REP message is not protected by this mechanism. Do we want to have a short note about how this is not expected to cause problems (as it's the default state for all KDC exchanges)? Subsequent factor data, including the data in the response, are encrypted in a derivative of the shared secret K. Therefore, it is not possible to exploit the untrustworthiness of the challenge to turn the client into an encryption or signing oracle, unless the attacker knows the client's long-term key. I'd consider adding a note "in which case the attacker does not need an external oracle to encrypt or sign using that key". Section 10.2 I guess it's a tossup whether this topic is better in 10.1 or 10.2, but we do send lists of factors in the clear, which can leak whether SF_NONE is potentially in use (i.e., if the client has a second factor at all). [...] Others may silently accept such a multiplier, but proceed to perform multiplication that is not constant time. This is a minor risk in all known groups, but is a major risk for P-521 due to the extra seven high bits in the input octet string. A common solution to this I'm having a hard time parsing this middle sentence; the best I can come up with is that "this is only a minor risk in most known groups". Section 10.3 We discuss replay of cookie values by attackers, but don't really talk about the related possibility of splicing cookie values across SPAKE exchanges. E.g., if an attacker observes two simultaneous requests and swaps the cookies between the two before forwarding to the KDC. Section 10.4 Although this pre-authentication mechanism is designed to prevent an offline dictionary attack by an active attacker posing as the KDC, such an attacker can attempt to downgrade the client to encrypted timestamp. [...] Maybe "or similar preauthentication mechanisms"? Client implementations SHOULD assume that encrypted timestamp and encrypted challenge are unlikely to succeed if SPAKE pre- authentication fails in the second pass and no second factor was used. Maybe s/no second factor/SF_NONE/? Like any other pre-authentication mechanism using the client long- term key, this pre-authentication mechanism does not prevent online password guessing attacks. The KDC is made aware of unsuccessful guesses, and can apply facilities such as password lockout to mitigate the risk of online attacks. I'd suggest "rate limiting" as a suggestion over "password lockout", which has some downsides in comparison to rate-limiting. Section 10.6 Is there much that a KDC can do in the face of such an attack? Will forcing fallback to the full SPAKE exchange help at all (e.g., with proof of return routability)? We can't really suggest reusing ephemeral key shares to reduce that part of the load. Section 12 In addition to potentially allocating a new value for the RFC version of this spec, we probably also want to say a bit more about the registration procedures. Should requestors send the request directly to the list, or to IANA first and IANA sends to the list? Is the list publicly archived (and can anyone sign up as a member)? Section 12.1.2 I think we spell this "SF_NONE" in the body, not "NONE". Section 12.2 This section specifies the IANA "Kerberos SPAKE Groups" registry. This registry records the number, name, specification, serialization, multiplier length, multiplier conversion, SPAKE M constant and SPAKE N constant. We also include a hash. Section 12.2.1 Serialization: Reference to the definition of the method used to serialize group elements. Do we think it's implicit that this is also used for deserializing group elements? Section 12.2.2 o Serialization: [SEC1] section 2.3.3 (compressed). I'd use a couple more words, e.g., "this specification uses the 'compressed' point format". (multiple occurrences) I did verify that these listed M and N values match draft-irtf-cfrg-spake2-08. Section 13.2 Normally we call these "Informative References". Appendix B (the CFRG doc has the M and N values for edwards25519 so we can drop that bit when we update the reference) Appendix C (The test vectors would need to be updated if we make breaking changes to the protocol, e.g., adopting the prime subgroup changes in draft-irtf-cfrg-spake2-08. But it's fine to just leave this section as an empty placeholder until things settle down, unless lots of people are planning to implement the intermediate states.) We use lowercase 'w' for both the PRF+ output and the reduced multiplier; could we maybe use the majuscule form for one to disambiguate? RC4 was deprecated by RFC 8429; do we still need test vectors for it? Similarly, just "AES128" and "AES256" are not super-unambiguous for enctype specifiers, given the enctypes in RFC 8009. (The price we pay for being slow to publish...) We don't have any test vectors with non-empty 'data' elements in SPAKESecondFactor, but that's probably okay (whichever doc adds a factor that uses it can have test vectors thereof). From nobody Thu Apr 4 17:58:21 2019 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 496871202D5 for ; Thu, 4 Apr 2019 17:58:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 QJdjpvuc4vpO for ; Thu, 4 Apr 2019 17:58:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 489651202D6 for ; Thu, 4 Apr 2019 17:58:17 -0700 (PDT) Received: from [18.101.8.192] (VPN-18-101-8-192.MIT.EDU [18.101.8.192]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x350wE2v007771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Apr 2019 20:58:15 -0400 To: Benjamin Kaduk Cc: kitten@ietf.org References: <20190404235859.GM54777@kduck.mit.edu> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <320b38a9-7dc1-49af-f054-a8863da4d23b@mit.edu> Date: Thu, 4 Apr 2019 20:58:14 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190404235859.GM54777@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 00:58:19 -0000 On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > In general this document is in good shape, but the elephant in the room > is the state of the dependency draft-irtf-cfrg-spake2, which is > apparently not as stable as we thought. It seems likely that we'll need > to wait until that document is further along before we can finalize our > revisions to this document and go to IETF LC; furthermore, I expect > we'll want to reissue some codepoints so that the current meanings stay > valid (tied to draft-irtf-cfrg-06's behavior) and the new codepoints > match the RFC version of the CFRG spec. (Except when we consciously > diverge, as for the transcript hash, etc.) > > In particular I think we will need to allocate a new PA-SPAKE value. > (I don't think I see a reason to allocate a new KEY_USAGE_SPAKE value.) I guess we didn't have the same takeaways regarding the recent revisions to draft-irtf-cfrg-spake2. I argued that the changes to cofactor handling in SPAKE2 were unnecessary, inconsistent with how X25519 was specified, and should be reverted (though w1 in SPAKE2+ should become a scaled cofactor instead of an unscaled one). There are also changes to the requirements for key derivation which I believe we cannot reasonably meet within the Kerberos protocol; while these changes can be reasonably justified, I believe they make draft-irtf-cfrg-spake2 unsuitable as a normative reference for draft-ietf-kitten-krb-spake-preauth in my opinion. Instead, we should describe the SPAKE2 algorithm within the Kerberos draft as it is used there, using the Abdalla/Pointcheval paper as an informative reference. I do not at this time understand why we would want or need to allocate new code points. From nobody Fri Apr 5 19:26:32 2019 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 4349B12046E for ; Fri, 5 Apr 2019 19:26:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 XnXfMXNMsQaf for ; Fri, 5 Apr 2019 19:26:29 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 D3A33120149 for ; Fri, 5 Apr 2019 19:26:28 -0700 (PDT) Received: from kduck.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.14.7/8.12.4) with ESMTP id x362QNuI023356 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 5 Apr 2019 22:26:27 -0400 Date: Fri, 5 Apr 2019 21:26:23 -0500 From: Benjamin Kaduk To: Greg Hudson Cc: kitten@ietf.org Message-ID: <20190406022623.GH70202@kduck.mit.edu> References: <20190404235859.GM54777@kduck.mit.edu> <320b38a9-7dc1-49af-f054-a8863da4d23b@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <320b38a9-7dc1-49af-f054-a8863da4d23b@mit.edu> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 02:26:31 -0000 On Thu, Apr 04, 2019 at 08:58:14PM -0400, Greg Hudson wrote: > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > > In general this document is in good shape, but the elephant in the room > > is the state of the dependency draft-irtf-cfrg-spake2, which is > > apparently not as stable as we thought. It seems likely that we'll need > > to wait until that document is further along before we can finalize our > > revisions to this document and go to IETF LC; furthermore, I expect > > we'll want to reissue some codepoints so that the current meanings stay > > valid (tied to draft-irtf-cfrg-06's behavior) and the new codepoints > > match the RFC version of the CFRG spec. (Except when we consciously > > diverge, as for the transcript hash, etc.) > > > > In particular I think we will need to allocate a new PA-SPAKE value. > > (I don't think I see a reason to allocate a new KEY_USAGE_SPAKE value.) > > I guess we didn't have the same takeaways regarding the recent revisions > to draft-irtf-cfrg-spake2. I argued that the changes to cofactor > handling in SPAKE2 were unnecessary, inconsistent with how X25519 was > specified, and should be reverted (though w1 in SPAKE2+ should become a > scaled cofactor instead of an unscaled one). Well, I see draft-irtf-cfrg-spake2 as being somewhat in flux still, in response to Kenny's review, and I'm reluctant to blindly charge ahead with this document until some clearer consensus arises there. I do owe everyone some responses to the thread for that document, still... With respect to this document, the main change in draft-irtf-cfrg-spake2 that seems like a "breaking change" would be the cofactor handling, e.g., whether we pick a value that's divisible by h and send that vs. sending the number from [0,p) and having the peer do the multiplication. IIRC the latter is "safer" in that it requires each party to perform the needed check as a matter of course in running the protocol, rather than having an additional "check step" that might be seen as optional and omitted. > There are also changes to the requirements for key derivation which I > believe we cannot reasonably meet within the Kerberos protocol; while > these changes can be reasonably justified, I believe they make > draft-irtf-cfrg-spake2 unsuitable as a normative reference for > draft-ietf-kitten-krb-spake-preauth in my opinion. Instead, we should > describe the SPAKE2 algorithm within the Kerberos draft as it is used > there, using the Abdalla/Pointcheval paper as an informative reference. I agree that we don't want (and in fact can't use) the key derivation and transcript hash from draft-irtf-cfrg-spake2-08, and don't see an issue with referencing the document just for the core algebraic operations. I had intended draft-irtf-cfrg-spake2 to have some text along the lines of "in the absence of a more suitable application-defined transcript and key-derivation mechanism, the following are defined for generic use", but in the rush of getting submitted before the draft deadline that didn't really come through. -Ben > I do not at this time understand why we would want or need to allocate > new code points. From nobody Fri Apr 5 22:12:37 2019 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 39A5C1202EA for ; Fri, 5 Apr 2019 22:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 EYSUNE3GDFTr for ; Fri, 5 Apr 2019 22:12:34 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 01FFA1202DE for ; Fri, 5 Apr 2019 22:12:33 -0700 (PDT) Received: from [18.101.8.228] (VPN-18-101-8-228.MIT.EDU [18.101.8.228]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x365CUos026645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Apr 2019 01:12:31 -0400 To: Benjamin Kaduk Cc: kitten@ietf.org References: <20190404235859.GM54777@kduck.mit.edu> <320b38a9-7dc1-49af-f054-a8863da4d23b@mit.edu> <20190406022623.GH70202@kduck.mit.edu> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: <261fda36-3c75-12db-76a7-46ff6f87697e@mit.edu> Date: Sat, 6 Apr 2019 01:12:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190406022623.GH70202@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 05:12:36 -0000 On 4/5/19 10:26 PM, Benjamin Kaduk wrote: > With respect to this document, the main change in draft-irtf-cfrg-spake2 > that seems like a "breaking change" would be the cofactor handling, e.g., > whether we pick a value that's divisible by h and send that vs. sending the > number from [0,p) and having the peer do the multiplication. IIRC the > latter is "safer" in that it requires each party to perform the needed > check as a matter of course in running the protocol, rather than having an > additional "check step" that might be seen as optional and omitted. The public value is a point, not a coefficient. The last step in each party's computation is to multiply by the private multiplier, e.g. K=x(S-wN). If x is divisible by h, then we are implicitly multiplying by the cofactor, so values of S which are of order 2p, 4p, ..., hp will be brought into the prime-order subgroup, just as if we multiplied by h explicitly. No check step is required. RFC 7748 uses this same approach to specify X25519. In section 5, each party's private scalar is "of the form 2^254 plus eight times a value between 0 and 2^251 - 1 (inclusive)." Each party computes the shared value as its (scaled) coefficient times the counterparty's point, without explicitly multiplying by h. (Well, just one coordinate of the resultant point, since it's using a Montgomery ladder.) Eike's writeup (the last message in the CFRG thread) is a decent explanation: https://mailarchive.ietf.org/arch/msg/cfrg/b1hIQguoaqLw2ioLsBHll06AglI In this writeup, x is unscaled and x'=h*x is scaled, but x is never used directly so that's just a minor matter of terminology. From nobody Tue Apr 16 11:29:33 2019 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 0E3AB12014F for ; Tue, 16 Apr 2019 11:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 IZnIHxCNaH9B for ; Tue, 16 Apr 2019 11:29:28 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 B2EE012012A for ; Tue, 16 Apr 2019 11:29:28 -0700 (PDT) Received: from localhost (SMALL-GODS.MIT.EDU [18.9.55.42]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3GITQPC019613; Tue, 16 Apr 2019 14:29:26 -0400 From: Greg Hudson To: kitten@ietf.org Date: Tue, 16 Apr 2019 14:29:26 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [kitten] pkinit-alg-agility downgrade attack discussion X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 18:29:31 -0000 Eric Rescorla wrote about draft-ietf-kitten-pkinit-alg-agility: I think this document would benefit greatly from describing the downgrade properties of each of the axes on which algorithms can be negotiated against various forms of compromise in the digest function. The relevant case is one in which the client and KDC both support one weak and one strong algorithm. Can the attacker either (1) force them to complete a handshake with a weak algorithm or (2) convince one side that the other side supports a weak algorithm and then interpose itself as that side. Specifically it would be useful to know which attacks are possible with a collision attack versus a preimage attack (though this can sometimes be hard to know). along with some discussion of specifics. I propose to address this feedback by adding security considerations text: The discovery method described in Section 4 uses a Kerberos error message, which is unauthenticated in a typical exchange. An attacker may attempt to downgrade a client to a weaker CMS type by forging a KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is a matter of local policy whether a client accepts a downgrade to a weaker CMS type. A client may reasonably assume that the real KDC implements all hash functions used in the client's X.509 certificate, and refuse attempts to downgrade to weaker hash functions. The discovery method described in Section 5 also uses a Kerberos error message. An attacker may attempt to downgrade a client to a certificate using a weaker signing algorithm by forging a KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local policy whether a client accepts a downgrade to a weaker certificate. This attack is only possible if the client device possesses multiple client certificates of varying strength. In the KDF negotiation method described in Section 6, the client supportedKDFs value is protected by the signature on the signedAuthPack field in the request. If this signature algorithm is weak to collision attacks, an attacker may attempt to downgrade the negotiation by substituting an AuthPack with a different or absent supportedKDFs value, using a PKINIT freshness token [RFC8070] to partially control the legitimate AuthPack value. A client performing anonymous PKINIT [RFC8062] does not sign the AuthPack, so an attacker can easily remove the supportedKDFs value in this case. Finally, the kdf field in the DHRepInfo of the KDC response is unauthenticated, so could be altered or removed by an attacker, although this alteration will likely result in a decryption failure by the client rather than a successful downgrade. It is a matter of local policy whether a client accepts a downgrade to the old KDF. Eric also wrote: I'm having a little trouble following the point in S 3. Is the idea that the paChecksum is always SHA-1 and you don't add a way to negotiate it, so you are instead folding the information into the KDF? If so, I think we need to work through the chain of logic here. As I understand it, the paRequest is included in the AuthPack, which is signed. So presumably the idea is that the AuthPack is signed with SHA-256 but because paChecksum is SHA-1, the binding is weak, right? But can you safely send a SHA-256 signature to a KDC which you have never talked to before? Can't you just get downgraded by the attack I describe above? Can you help unpack this for me? (I assume "paRequest" is a typo for "paChecksum".) I don't understand the last part of this question. If an attacker substitutes an altered KDC-REQ-BODY via an attack on SHA-1 (either on the paChecksum itself or on the CMS signature of the SignedAuthPack containing the checksum), the KDC won't detect the substitution, but the client will fail to decrypt the reply because the KDC will derive the reply key with the altered KDC-REQ-BODY and the client will derive the reply key with the original one. This protection does not apply if the attacker manages to downgrade the exchange to the old KDF, of course. From nobody Tue Apr 16 14:34:44 2019 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 148EA120140; Tue, 16 Apr 2019 14:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qZ0laCcsRwyQ; Tue, 16 Apr 2019 14:34:40 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 036E3120155; Tue, 16 Apr 2019 14:34:37 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 52BCD5946A; Tue, 16 Apr 2019 21:34:36 +0000 (UTC) Received: from localhost (ovpn-112-50.rdu2.redhat.com [10.10.112.50]) by smtp.corp.redhat.com (Postfix) with ESMTP id B40D319C6A; Tue, 16 Apr 2019 21:34:35 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , kitten@ietf.org Cc: Eric Rescorla , draft-ietf-kitten-pkinit-alg-agility@ietf.org In-Reply-To: References: Date: Tue, 16 Apr 2019 17:34:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 16 Apr 2019 21:34:36 +0000 (UTC) Archived-At: Subject: Re: [kitten] pkinit-alg-agility downgrade attack discussion X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2019 21:34:43 -0000 --=-=-= Content-Type: text/plain Greg Hudson writes: > Eric Rescorla wrote about draft-ietf-kitten-pkinit-alg-agility: > > I think this document would benefit greatly from describing the > downgrade properties of each of the axes on which algorithms can be > negotiated against various forms of compromise in the digest > function. > > The relevant case is one in which the client and KDC both support > one weak and one strong algorithm. Can the attacker either > > (1) force them to complete a handshake with a weak algorithm > or > (2) convince one side that the other side supports a weak algorithm > and then interpose itself as that side. > > Specifically it would be useful to know which attacks are possible > with a collision attack versus a preimage attack (though this can > sometimes be hard to know). > > along with some discussion of specifics. > > I propose to address this feedback by adding security considerations > text: > > The discovery method described in Section 4 uses a Kerberos error > message, which is unauthenticated in a typical exchange. An > attacker may attempt to downgrade a client to a weaker CMS type by > forging a KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error. It is > a matter of local policy whether a client accepts a downgrade to a > weaker CMS type. A client may reasonably assume that the real KDC > implements all hash functions used in the client's X.509 > certificate, and refuse attempts to downgrade to weaker hash > functions. > > The discovery method described in Section 5 also uses a Kerberos > error message. An attacker may attempt to downgrade a client to a > certificate using a weaker signing algorithm by forging a > KDC_ERR_DIGEST_IN_CERT_NOT_ACCEPTED error. It is a matter of local > policy whether a client accepts a downgrade to a weaker > certificate. This attack is only possible if the client device > possesses multiple client certificates of varying strength. > > In the KDF negotiation method described in Section 6, the client > supportedKDFs value is protected by the signature on the > signedAuthPack field in the request. If this signature algorithm > is weak to collision attacks, an attacker may attempt to downgrade > the negotiation by substituting an AuthPack with a different or > absent supportedKDFs value, using a PKINIT freshness token > [RFC8070] to partially control the legitimate AuthPack value. A > client performing anonymous PKINIT [RFC8062] does not sign the > AuthPack, so an attacker can easily remove the supportedKDFs value > in this case. Finally, the kdf field in the DHRepInfo of the KDC > response is unauthenticated, so could be altered or removed by an > attacker, although this alteration will likely result in a > decryption failure by the client rather than a successful > downgrade. It is a matter of local policy whether a client accepts > a downgrade to the old KDF. This all still sounds good. > Eric also wrote: > > I'm having a little trouble following the point in S 3. Is the idea > that the paChecksum is always SHA-1 and you don't add a way to > negotiate it, so you are instead folding the information into the > KDF? If so, I think we need to work through the chain of logic > here. As I understand it, the paRequest is included in the > AuthPack, which is signed. So presumably the idea is that the > AuthPack is signed with SHA-256 but because paChecksum is SHA-1, > the binding is weak, right? But can you safely send a SHA-256 > signature to a KDC which you have never talked to before? Can't you > just get downgraded by the attack I describe above? Can you help > unpack this for me? > > (I assume "paRequest" is a typo for "paChecksum".) > > I don't understand the last part of this question. If an attacker > substitutes an altered KDC-REQ-BODY via an attack on SHA-1 (either on > the paChecksum itself or on the CMS signature of the SignedAuthPack > containing the checksum), the KDC won't detect the substitution, but > the client will fail to decrypt the reply because the KDC will derive > the reply key with the altered KDC-REQ-BODY and the client will derive > the reply key with the original one. This protection does not apply > if the attacker manages to downgrade the exchange to the old KDF, of > course. (Added Eric to CC.) Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAly2SmoACgkQJTL5F2qV pEIf+xAAuxxuPhlxW7XT3VLr1TYHyUQehhYnYjAX0NL3iM02QyMLcKTwFSa5KQmS CneCdY/3N50awUa9uZZ9WQXNqNOGF6kirpLIMHRXJLVfrvGURsE7IA/Xe0rlVTeW QkVgAB/dPBtYeq4fvupwXTsueks5XUWveHDNJNsZfyPx3Km5S/3gq9+Uee7uRias p3rJvzLBF7Ex0sHASD+UkvY5bPA3BfbXkPtp46GTHZuUgiXlc7ajIJwDdHJP0qZ0 Sq9nnuoJ4S3NvpbhlF2nyrfd4zW7VK1NfdTNR7TkbSAvEEpV0+zr2LiGfWB/5mdm W9uVv/4Ri4NQUr7UxzGf/HfILCpqZcJBpuHo0JwMoVdL9hDOyzrEUS5UKgdh+uil k9nGr3+oBXo+HF/GEmZCNJ1yv0Kywbzdt8nUAKJm0YYCPkUSLEAv3hjNxAIxRJJl sfdKycAy+b7xxTLeCPj45D0mcHEDKspTU9xOBjrbLdt6Y1kKiZ/cvF/63bXSX+M5 NE3WIWusnENa16+5VrgSzR2PtoZQdY/3u7ym2nUEBsvDQLGH1F2TzTmJPfsr6VYg grUtKSjYxqTUJY3WJGV/Nc7VV0UkoR8w+VV+XVaG/7GNCGB7C8PJ72qREHB809aY OCg9ZZOCZyZddEWHbayxJkDnbmFEXntz6rQjKczGJWKE/6zwlG8= =kDx9 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 18 12:05:06 2019 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 F382A120187; Thu, 18 Apr 2019 12:05:04 -0700 (PDT) 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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <155561430480.25566.6975163425428950529@ietfa.amsl.com> Date: Thu, 18 Apr 2019 12:05:04 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 19:05:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. Title : PKINIT Algorithm Agility Authors : Love Hornquist Astrand Larry Zhu Margaret Wasserman Greg Hudson Filename : draft-ietf-kitten-pkinit-alg-agility-07.txt Pages : 20 Date : 2019-04-18 Abstract: This document updates the Public Key Cryptography for Initial Authentication in Kerberos standard (PKINIT) [RFC4556], to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-07 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-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 Apr 18 12:35:13 2019 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 E6FE012036D; Thu, 18 Apr 2019 12:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 qWZIpvj9iz5l; Thu, 18 Apr 2019 12:35:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CEE1120346; Thu, 18 Apr 2019 12:35:09 -0700 (PDT) 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 DD25DC069B2C; Thu, 18 Apr 2019 19:35:08 +0000 (UTC) Received: from localhost (ovpn-112-28.rdu2.redhat.com [10.10.112.28]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6FBBC60856; Thu, 18 Apr 2019 19:35:08 +0000 (UTC) From: Robbie Harwood To: Eric Rescorla , The IESG , Benjamin Kaduk Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org In-Reply-To: <155253481198.24861.15849658500473174931.idtracker@ietfa.amsl.com> References: <155253481198.24861.15849658500473174931.idtracker@ietfa.amsl.com> Date: Thu, 18 Apr 2019 15:35:08 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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.31]); Thu, 18 Apr 2019 19:35:09 +0000 (UTC) Archived-At: Subject: Re: [kitten] Eric Rescorla's No Objection on draft-ietf-kitten-pkinit-alg-agility-06: (with COMMENT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 19:35:12 -0000 --=-=-= Content-Type: text/plain Eric Rescorla via Datatracker writes: > IMPORTANT > > I think this document would benefit greatly from describing the > downgrade properties of each of the axes on which algorithms can be > negotiated against various forms of compromise in the digest function. > > The relevant case is one in which the client and KDC both support one > weak and one strong algorithm. Can the attacker either > > (1) force them to complete a handshake with a weak algorithm > or > (2) convince one side that the other side supports a weak algorithm > and then interpose itself as that side. > > Specifically it would be useful to know which attacks are possible > with a collision attack versus a preimage attack (though this can > sometimes be hard to know). > > > Here is one case of a potential real downgrade attack (though not a > very powerful one). > > The client sends a KRB-REQ signed with algorithm A, the attacker > forges KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED listing anly some > weaker algorithm. This causes the client to retry with that weaker > algorithm. Is this attack detectable? It's not clear to me how (though > it maybe could be if the message were folded into the transcript). > > OTOH, I don't think that the equivalent attack on the cert signer > algorithms is necessarily very useful because presumably the certs are > public already. OTOH, it might force the client into using some weaker > key. Hi, Greg has been kind enough to provide us with a -07 of this document that should address these concerns in the "Security Considerations" section. > I'm having a little trouble following the point in S 3. Is the idea > that the paChecksum is always SHA-1 and you don't add a way to > negotiate it, so you are instead folding the information into the KDF? > If so, I think we need to work through the chain of logic here. As I > understand it, the paRequest is included in the AuthPack, which is > signed. So presumably the idea is that the AuthPack is signed with > SHA-256 but because paChecksum is SHA-1, the binding is weak, right? > But can you safely send a SHA-256 signature to a KDC which you have > never talked to before? Can't you just get downgraded by the attack I > describe above? Can you help unpack this for me? Copying Greg's response from the other thread for completeness: (I assume "paRequest" is a typo for "paChecksum".) I don't understand the last part of this question. If an attacker substitutes an altered KDC-REQ-BODY via an attack on SHA-1 (either on the paChecksum itself or on the CMS signature of the SignedAuthPack containing the checksum), the KDC won't detect the substitution, but the client will fail to decrypt the reply because the KDC will derive the reply key with the altered KDC-REQ-BODY and the client will derive the reply key with the original one. This protection does not apply if the attacker manages to downgrade the exchange to the old KDF, of course. > MINOR > > I wish you were using HKDF, but I don't think this is a dealbreaker. Yeah, bit hard to change that now. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAly40WwACgkQJTL5F2qV pELplw//Y+YC0fPxKRA+lom0fPFdUT5BiRD9mPAkQ8TQw8396i8esGYZMOVvbSJl lxjHzgWCBaidKf11768oAPGlGGRcb7a0aqE2BZBK+5iATtkxs/sYEHHcEbYh8f6M xOw/+s6sX3soGz1TjMBtGpcysBGWYlWendkcAFKlVH+F/ZtN2CrhoN892QjgZAym fvXODzmFYexJVavwYidQmB658g5qDFhixoUI8SQPC3wv+XZzw8Y/jU7qJ8DIQjd3 gKEi+u6kYCOS7GPdBRaYVLnD0QGoF4o09vSCfTkOcebM0I8J5NgSjjttZm4yFS7S SCBy6ViKRq1GzT2R6LIs8TliGVn01M//K1mB3lq5f5YdHc8A+8e38j5PFc88896r QoVXluqnjLPgsqTTrUfgnSZuBUlMdw6du/PK/oiDkAtw6FUlmj81mWDFmtnIFd7A lde9iHdE/KJZIxvO82nTsi0a3eWa/iMUmAU1P+i/4Lxlk/YdkpDZ31mec2tn6tHk rOqtnpNFULjPBOjbxiyZrPTIkW0yk6jjct1AiSVx+x4moHKTACCJpcD4K5RscHEx 30Cy1cqkAABiR85IKAS4U9dSB6Bw/9dCzRPGd0YfLFc+DyBbW9WsRtqeaKIl+9Vr lV5qAsLNyGjSMmrtQAEz3Bg3h6TQFKJ/NLSpARYdmV9spDmn9Bo= =zBFc -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 18 20:27:24 2019 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 8AAE912009A for ; Thu, 18 Apr 2019 20:27:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 QeCVEDR1jiHQ for ; Thu, 18 Apr 2019 20:27:20 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 6FF80120043 for ; Thu, 18 Apr 2019 20:27:20 -0700 (PDT) Received: from kduck.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.14.7/8.12.4) with ESMTP id x3J3RG90018981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Apr 2019 23:27:18 -0400 Date: Thu, 18 Apr 2019 22:27:16 -0500 From: Benjamin Kaduk To: ghudson@mit.edu Cc: kitten@ietf.org Message-ID: <20190419032716.GD95327@kduck.mit.edu> References: <155561430480.25566.6975163425428950529@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <155561430480.25566.6975163425428950529@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 03:27:23 -0000 Thanks for the updates, Greg -- they really help the document out! (Thanks to Eric for spotting the needed changes.) Before I push this off for publication, I just wanted to check whether KDC policy had a role in providing downgrade protection in the discovery methods from Sections 4 and 5 -- would there be a case where the KDC knows to require the stronger CMS type/signing algorithm for a specific principal, so that even if the client is tricked into downgrade by an attacker, the exchange would still fail? Thanks, Ben On Thu, Apr 18, 2019 at 12:05:04PM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. > > Title : PKINIT Algorithm Agility > Authors : Love Hornquist Astrand > Larry Zhu > Margaret Wasserman > Greg Hudson > Filename : draft-ietf-kitten-pkinit-alg-agility-07.txt > Pages : 20 > Date : 2019-04-18 > > Abstract: > This document updates the Public Key Cryptography for Initial > Authentication in Kerberos standard (PKINIT) [RFC4556], to remove > protocol structures tied to specific cryptographic algorithms. The > PKINIT key derivation function is made negotiable, and the digest > algorithms for signing the pre-authentication data and the client's > X.509 certificates are made discoverable. > > These changes provide preemptive protection against vulnerabilities > discovered in the future against any specific cryptographic > algorithm, and allow incremental deployment of newer algorithms. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-07 > https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-07 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-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/ > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Apr 19 12:50:18 2019 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 BB3711200B1 for ; Fri, 19 Apr 2019 12:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 K81pppvH8vBi for ; Fri, 19 Apr 2019 12:50:10 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 DB02A12001B for ; Fri, 19 Apr 2019 12:50:09 -0700 (PDT) Received: from [18.101.8.161] (VPN-18-101-8-161.MIT.EDU [18.101.8.161]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3JJo7WA002720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 19 Apr 2019 15:50:08 -0400 To: Benjamin Kaduk Cc: kitten@ietf.org References: <155561430480.25566.6975163425428950529@ietfa.amsl.com> <20190419032716.GD95327@kduck.mit.edu> From: Greg Hudson Openpgp: preference=signencrypt Autocrypt: addr=ghudson@mit.edu; keydata= xsFNBFLMQYIBEADZLNv8Jpeo2d4XSLE+k6m1VD2iOyX66wErZKaQpYrGB/leWKfz8l6c3pWd iVUnCoyxKlhRuGVArszdh2wUSRgHnMl86JC/vIdawdOdbnlTVfOJTiP3EfycsMUUDG6GckLY e+xxo7sM/bpXpGkbIWc0Ec/vbQt67eeW2En1AqL+ezJdVN9XL8icH2Hu6HlqxGgleC5H0yAi kM4yvNjo5z2M/Dr/x63bLcIdKkSRPzd0OaBg2g0Yh651eYpPu0e1Gi6785ZBjV4bnv3K5oLo 5XsiHIZ60maHWTEyMO/byw4aS2cCWIovXurvz699KSF83B296+xhsFhhz4+kbQgXvJt4kIoI pdpX6xbIkeVlc+FuUbyE8MUGveA3TFHXZ4+0f2tvTekey/62FOeXnrqc4NsBViir3zGTXAqC 7PQTNnX/86jyW+9SnJo9XbSBB3NV0K5I2o1cDzqRPqy/4fsoq8SxQwRga0CSId1PzE9PUEUY V0FCldo9LvPsUK9YE7AuwC+bcQiVLah5TF+5Kk7yLSaRxzQ3fI5lcqk5UPUqMLa87cRBdnal niuHVg0u3W22RMPkWe2iPIYYdr4TQDzCkD2JXpXNaZ3KipVT5aqowwfPEt7b6ti0vjrOInij YzFmVNMGKYabwh2zxKWQQ8GO5mUVu09CSe33H4EW7pDP+zHr2wARAQABzR1HcmVnIEh1ZHNv biA8Z2h1ZHNvbkBtaXQuZWR1PsLBeAQTAQIAIgUCUsxBggIbAwYLCQgHAwIGFQgCCQoLBBYC AwECHgECF4AACgkQDLoIV1+Dct8dZBAA1Mtoq1RPuUQg6hL2qFjwTEXeonWq8czkQ1fNNzO9 x8I3VLn5L6CmWeAmxRU1DD0qZ5HL24+Mwnvy/eazp4/CSgiPC52KfbNsnQtg/E+8ruFQVHA/ 3HZXuCT/Nz4s06N3fMZrJLCGNEHRD0S43kb2GGboVY3ykO3FbPJB/DxDqtIMqt6B1SZ87UAR CVsRc296X3TsF9BgoQ/n54XfYAzrACkuIH9biHmH6wB1eykCeuhkCsu5Zf/tlSXJCFiuhvS+ CX2EbNKF+0MLcGAavSzbjTnQw3kv8unSgecbEQ7A8ibGx6Jwgnvy0gzu6w4prhR40pVYDcL+ sKsmQg6jo/uPvGdEqHISFSK8FxGGAonaAwg0014bXLaPo2MckcZ+szcHA/z4vpTdB1vChexL omM5ZTeSJaFfeYsspv8sq6EL1x21c7A+ngCmB70/OZR6dcgf9/ILmcjBiYfJHYukXTIvGT6y QJbok19So8RJKUYjzzHDKBweg8x6HdIrdy7HTcLzsqY9PFGg7/YlbLlGQwYXhK1b4uBmWyE7 I/402+57I1YpMYND7vsTmJuE13Gv5ZGhYn5pSzX9ZTWY13LgGymkWBXPxfefkHKTV9ROCGEL t7SV3Nf7ZsCGLRGmDT6oqLz75/IrhKEcHIfD4ct+QvIm6pvPNvikQMwPWSd52GazILLOwU0E UsxBggEQAKaz/wX8nsSUaivmwW4NVlbmTsErHUt9iNHm9CmieuoDv1o8qUqEV6RiONIs0q5Y +dcooazhHRNpjAST2rbQFBZebfpVRKYAGzHoZEQ6OV8Eao+NjAGazS8RuwIxpeZ36r3AyVhe TAIvIzwpQFDNKTIUNbXctHrZ157TlxDuKwZ3+Yw/bhQE5YGrSLm17wIMcY3UHiE1mO5X0ohR dDeTf93PignUUvWvRRQLyxRGsBLz/CCwmCJZeu/FjnDk8HkEbAlmFAJ+YZu9rQ40vU6Z40KY L5U9PIn0FdSxviK7mys+VbFYV6mXWXZN8dOkHuG6zSdmobE90G6ZzAPcI4cyql63N+kUOb3b hGI/Wvn6tUbWeIc8UvQGpYb0+eOKHQBNKUOq5RV98hZorZRCu2W2RzZSxiufyONvtonbUtYs BMdw+gqUpK0ir782lc3cKbj+X5iiyg3ZGvBmTU6FN/MiX6MnTyEwOScFboKe6vB8ZgwII85K n9qlSI3xH56JBXamMP0yqJf57q0WfP8V7lFtm8SmhU2NQyP3wRYDm2+bLTNCmRPJN2ZUgkTx c/Qjov8TeeiTfX9S3ea/GJOdgA1mQfSkmUoOWROnwDBbKGBXNzkkoJna8j/zWgo/mQ5gNdIu HXcIdDKbyyhVH3+DwxXYWyYP/pnIk3AVCss75dXcdStfABEBAAHCwV8EGAECAAkFAlLMQYIC GwwACgkQDLoIV1+Dct+oSA/9HyTkr+UQbaucXE9pP87yasObKCBxYhoeRjzBhgtYUtSDuH2o xl5M3wmTNOooQSa8R1ljhax9v02pqspIA9hyGjGjvZ6jPydDsANNcohdbMjCzXNdrCF5149w gbGQ07rkc5JNyajzxH4GE/BXclTzwTYAaHvYM5PEQLDhmubK3M/kBvjWpZxLAJAobMi/jVwQ cmai+N56X9Ht/FVIQlmCuXoMAE9ScVWFaq8JnCo9VZ0G045NcxdEoQXVUXb3E5cmZ0Ld9sUm SKSJKjYWjfE4c/8oylZuo9LDTwozBEp/jsASjL0g8F3QJsQUkFkKROd45xHcIkFulshS3xkG gMu6UduV2ypPz987f+0wdVwx+KYnmnUB83gxqVucFRxfZZXiUHUml4rJ7Ww2+//H9FFPfw9f aPMg7nLFm2T0to3pwgyisLH/aThzW3TY7CZ7gkvMDtbo9EHrN4Nl3onuOtOKQpIMbFVqX4YZ m6znSLuUiWDUd8rvQfz+4ndZKIFOG1YIKwQBV8tN1RYBGY9bhv2Wtt5X6SKIzkUhDdgeyzci MC1M3N0Pqoqrms7FdBKAd0BE7puhQ24U42APss+Ur6WyRZMQTKc41SZWfrWV30agytUVdtRu gxERw74qeGAz6o3if42vI6u30SR6OCLMMSobqKc7HQvJ2qv3Z6j9kt1zXiE= Message-ID: Date: Fri, 19 Apr 2019 15:50:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20190419032716.GD95327@kduck.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-07.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 19:50:16 -0000 On 4/18/19 11:27 PM, Benjamin Kaduk wrote: > Before I push this off for publication, I just wanted to check whether KDC > policy had a role in providing downgrade protection in the discovery > methods from Sections 4 and 5 -- would there be a case where the KDC knows > to require the stronger CMS type/signing algorithm for a specific > principal, so that even if the client is tricked into downgrade by an > attacker, the exchange would still fail? In any of the three downgrade scenarios the KDC could refuse the use of the weak hash function as well. I can add clauses about that: It is a matter of local policy whether a client accepts a downgrade to a weaker CMS type, and whether the KDC accepts the weaker CMS type. It is a matter of local policy whether a client accepts a downgrade to a weaker certificate, and whether the KDC accepts the weaker certificate. It is a matter of local policy whether a client accepts a downgrade to the old KDF, and whether the KDC allows the use of the old KDF. Independent of anything described in the draft, an attacker could try to impersonate the KDC to the client by forging the dhSignedData signature using a weak hash algorithm, if the client allows that algorithm when verifying the KDC signature. Even if the client insists on a newer KDF using a strong hash function, the attacker could do the key derivation step using SHA-256 and the new KDF, and just sign the KDCDHKeyInfo with SHA-1. An attacker could conceivably do this via a SHA-1 collision (in order to get the legitimate KDC to sign the same hash as the forged reply) because KDCDHKeyInfo contains a nonce controlled by the client when DH keys are not reused--but in that case the legitimate KDC places a random subjectPublicKey into KDCDHKeyInfo, which might make the attack impractical. From nobody Sat Apr 20 10:49:52 2019 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 285B712015C; Sat, 20 Apr 2019 10:49:42 -0700 (PDT) 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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <155578258209.10327.10622879743046748005@ietfa.amsl.com> Date: Sat, 20 Apr 2019 10:49:42 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-pkinit-alg-agility-08.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 17:49:42 -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 : PKINIT Algorithm Agility Authors : Love Hornquist Astrand Larry Zhu Margaret Wasserman Greg Hudson Filename : draft-ietf-kitten-pkinit-alg-agility-08.txt Pages : 20 Date : 2019-04-20 Abstract: This document updates the Public Key Cryptography for Initial Authentication in Kerberos standard (PKINIT) [RFC4556], to remove protocol structures tied to specific cryptographic algorithms. The PKINIT key derivation function is made negotiable, and the digest algorithms for signing the pre-authentication data and the client's X.509 certificates are made discoverable. These changes provide preemptive protection against vulnerabilities discovered in the future against any specific cryptographic algorithm, and allow incremental deployment of newer algorithms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-pkinit-alg-agility-08 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-pkinit-alg-agility-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-pkinit-alg-agility-08 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/