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

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Sun, 13 Aug 2017 12:24:19 -0700

First of all, I find the content compelling and I support moving forward. This draft seems to have been “worked over” pretty well.

The precise form of pake specified is apparently unique in some details. I wonder if we should get the cfrg to review and comment on it. 

There are a number of TBDs which need finalizing. (pp 6, 9, 12, & 16)

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.

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

Personal email.  [email-masked]

---

From: Greg Hudson <[email-masked]>
Date: Mon, 14 Aug 2017 11:13:24 -0400

Thanks very much for the review.  I know that this draft is a bit denser
than some.

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

> 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 rfc412…

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.

> [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 t…

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

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Mon, 14 Aug 2017 10:30:23 -0700

> On Aug 14, 2017, at 8:13 AM, Greg Hudson <[email-masked]> wrote:
> 

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.

> substantive parts of the document.

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

>    specified in [RFC4120] section 5.2.7.5.

Good. Thanks.

>    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 […]

???

---

From: Greg Hudson <[email-masked]>
Date: Mon, 14 Aug 2017 14:01:48 -0400

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

Perhaps using "then" instead of next will help?  Current proposed
wording (with some minor edits to the later sentences):

    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. The client will then choose one of
    the second factor types listed in the factors field of the challenge
    message and gather whatever data is required for the chosen second
    factor type, possibly using the associated challenge data. Finally,
    the client will send an AS-REQ containing a PA-SPAKE PA-DATA
    element using the response choice.

---

From: "Henry B (Hank) Hotz, CISSP" <[email-masked]>
Date: Mon, 14 Aug 2017 14:39:40 -0700

> On Aug 14, 2017, at 11:01 AM, Greg Hudson <[email-masked]> wrote:
> 

That’s good. 

I did put the forward reference in because of what I said at the beginning of my last email, but I’m not hard over. I’m also no longer the best judge.  Any other opinions?

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Aug 2017 20:48:22 -0500

> wording (with some minor edits to the later sentences):

I don't think "next" vs. "then" is a big difference, it's more a question
of whether the first sentence is giving an overview of what will happen
in the section, or just the first step in what happens.  (When Henry
first mentioned it, I thought it was the former, but now see it's the latter.)

>     element using the response choice.

I think that's more clear, thanks.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 16 Aug 2017 20:51:37 -0500

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

I marked up a few more places in addition to the couple you mentioned already,
in my first pass through it.  (Actual review email to come soon, I hope.)

[in separate mail]

> The precise form of pake specified is apparently unique in some details. I
> wonder if we should get the cfrg to review and comment on it.

I do plan to mention it to Kenny Paterson, as we had talked about this
work in a general sense previously.  He is of course well-qualified to
assess whether seeking full CFRG input is merited.

-Ben