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

[Benjamin Kaduk <[e-mail]>]

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.