Re: [kitten] Comments on draft-ietf-kitten-krb-spake-preauth-00

["Henry B (Hank) Hotz, CISSP" <[e-mail]>]

> On Aug 14, 2017, at 8:13 AM, Greg Hudson <[e-mail]> wrote:
> 
> Thanks very much for the review.  I know that this draft is a bit denser
> than some.

The density is whatever it needs to be for the subject. The material is well organized, and clear per se, but the reader needs to know that some material needed to appreciate the early sections is in later sections. 

If we can get someone else new to go through it and see if more forward references are needed . . .

I do not think this issue justifies holding up publication. This is just wordsmithing and clarity, not substance.

> On 08/13/2017 03:24 PM, Henry B (Hank) Hotz, CISSP wrote:
>> There are a number of TBDs which need finalizing. (pp 6, 9, 12, & 16)
> 
> I can assign padata and key usage numbers, but if the draft changes
> incompatibility they might then need to be reassigned.  So I plan to
> wait until it looks like there is working group consensus on the
> substantive parts of the document.

No prob. I’m sure the RFC editor will hold your feet to the fire on that one. ;-)

>> Section3 should include pointers to where the prerequisites are specified. In the case of PA-FX-COOKIE and KDC_ERR_MORE_PREAUTH_DATA_REQUIRED that is rfc6113, section 5.2.  PA-ETYPE-INFO2 is rfc4120, section 3.1.3.
> 
> I will add those.  In the first prereq, this is a little
> awkward--ETYPE-INFO2 support is old hat, but we require the relatively
> new behavior (from RFC 6113) of sending only a single entry.  My
> proposed new text for that prereq is:
> 
>    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. PA-ETYPE-INFO2 is
>    specified in [RFC4120] section 5.2.7.5.

Good. Thanks.

>> [NIT] Section 4.3, para 2: Delete the word “Next”. On my first reading that led me to think it was describing what to do after “the client completes. . .”. It actually describes the *first* thing to do (in the third pass). I’ve now read it enough times that I’m no longer qualified to say how important that is.
> 
> The word "Next" is intended, but I can see that "will complete its part
> of the SPAKE process" is too vague--it is not clear that it is
> describing a computation step with no protocol messages.  I propose this
> wording, combining the first two paragraphs:
> 
>    Upon receipt of the challenge message, the client will complete
>    its part of of the SPAKE algorithm, generating a public key and
>    computing the shared secret K. Next, the client chooses one of the
>    second factor types [...]

Hmmm. I still wasn’t interpreting it right. If you say “next” I wonder what the preceding “first” or “next” was. I didn’t have an explicit referent to halt my mental search. In this case I think it’s:

   Upon receipt of the challenge message, the client will first complete
   its part of of the SPAKE algorithm in accordance with section 7, 
   generating a public key and computing the shared secret K. 

   Next, the client chooses one of the second factor types […]

???

Personal email.  [e-mail]