Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06

Greg Hudson <ghudson@mit.edu> Thu, 23 April 2020 17:33 UTC

Return-Path: <ghudson@mit.edu>
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 8A7A43A09DF; Thu, 23 Apr 2020 10:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 KVIhY1W3RhjL; Thu, 23 Apr 2020 10:33: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 33B613A09C4; Thu, 23 Apr 2020 10:33:03 -0700 (PDT)
Received: from [18.30.10.110] ([18.30.10.110]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03NHWq9w001785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 23 Apr 2020 13:33:02 -0400
To: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-kitten-krb-spake-preauth.all@ietf.org
Cc: kitten@ietf.org
References: <20190404235859.GM54777@kduck.mit.edu>
From: Greg Hudson <ghudson@mit.edu>
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: <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu>
Date: Thu, 23 Apr 2020 13:32:52 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.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: <https://mailarchive.ietf.org/arch/msg/kitten/YCwZaM6bPBHgX7Bm4A8Mw61g7oY>
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 <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 17:33:11 -0000

Ben sent feedback on the SPAKE preauth draft a little over a year ago.
I deferred acting on the smaller feedback items at the time, while
observing the CFRG's progress on PAKE algorithms.

The CFRG has selected CPace over SPAKE2 for a balanced PAKE.  As such I
doubt there will be a need for a CFRG SPAKE2 document.  At this time I
don't think there would be sufficient interest in retooling the Kerberos
preauth mechanism for CPace, or making breaking changes.  I have
prepared changes to draft-ietf-kitten-krb-spake-preauth to drop its
dependency on draft-irtf-cfrg-spake2, instead referring informatively to
the Abdalla/Pointcheval paper and describing the group operations
explicitly.

These changes, as well as updates addressing the smaller feedback items,
are at
https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7
.  I will update the draft unless it seems like there isn't WG consensus
on this direction.

Some responses to a few of the smaller feedback items:

On 4/4/19 7:58 PM, Benjamin Kaduk wrote:
>    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?

It's just the pubkey value.  The rest of the message is an encrypted
field, and we need to finalize the transcript hash before deriving a key
to encrypt with.
>    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.

Key derivation does a KRB-FX-CF2 with the initial reply key, for exactly
this reason.  I don't think we need to call it out.

>    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?

Client and server principal names are included in the KDC-REQ-BODY,
which is one of the hashed elements.

>    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?

First paragraph.  Admittedly it's just subcontracting out to the registry.

>                         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)?

I think it would be hard to say anything correct without descending into
a rathole.  There are some problems with unauthenticated plaintext in
KDC-REP, which are addressed by implementations in kind of a patchwork
way, and this preauth mechanism does not improve on that situation.

>    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".

That would be incorrect; as this section is talking about the factor
challenge, it is talking about an encryption or signing oracle for the
factor credentials, not for the long-term key.

> 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.

It does talk about that ("SHOULD prevent cookie values from being
applied to other pre-authentication mechanisms or other client
principals"), but I made it a little more explicit.

>    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"?

There isn't a big unknown supply of Kerberos preauth mechanisms.  This
is specifically about encrypted timestamp.

> 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.

draft-irtf-cfrg-spake explicitly forbade all reuse of ephemeral values,
but I think it is actually safe to reuse a public key for a client.
(That is, reusing the private multiplier x across clients is bad, but
reusing T=xP+wM for a specific client is okay.)  I didnt change this
section, but with the CFRG draft out of the picture, we could perhaps
suggest public key reuse as a load mitigation strategy.

> 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)?

I'm a little lost here.  The mailing list was Nathaniel's idea and I am
not attached to it.  There are hundreds of IANA registries; it seems
like we should be picking from a few best practices for update
procedures rather than breaking ground.

>    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)

Is there really any ambiguity in just saying "compressed"?  Terseness is
of value here.

[Regarding test vectors:]
> We use lowercase 'w' for both the PRF+ output and the reduced
> multiplier; could we maybe use the majuscule form for one to
> disambiguate?

We use uppercase letters for group elements, so that would be confusing.
 The PRF+ output is an intermediate value that I thought would be useful
to implementors.  I think the test vectors are pretty clear in their
current form.