Subject: Re: [Last-Call] [kitten] Genart last call review of draft-ietf-kitten-krb-spake-preauth-07

From: Robbie Harwood <[email-masked]>
Date: Tue, 02 Jun 2020 17:57:48 -0400

Russ Housley <[email-masked]> writes:

>> On May 28, 2020, at 6:27 PM, Robbie Harwood <[email-masked]> wrote:
>> 
>> Signed PGP part
>> Russ Housley via Datatracker <[email-masked]> writes:
>> 
>>> Reviewer: Russ Housley
>>> Review result: Almost Ready
>>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed by
>>> the IESG for the IETF Chair.  Please treat these comments just like
>>> any other last call comments.
>> 
>> Hi Russ, thanks for the review.  Changes should be present in -08 unless
>> discussed further below.
>> 
>>> Major Concerns:
>>> 
>>> Does this align with draft-irtf-cfrg-spake2?
>> 
>> It's derived from it, though they no longer totally align.
>> 
>>> Are you aware of https://datatracker.ietf.org/ipr/4018/?
>> 
>> I have seen it, but as Watson Ladd put it in
>> https://mailarchive.ietf.org/arch/msg/cfrg/senXefqczpUZo26B35ekz8d3iLo/
>> 
>>    I’m not a patent lawyer, and cannot speculate on any IPR conflicts
>>    that may or may not exist.
>
> If these documents do not align, then another 3rd party disclosure
> should be made against this document, so the IPR holder can weigh in.

Having now reread RFC 8179, it's my understanding that this is both a
required action and does not indicate any further statement on our part.
Accordingly, I've filed a separate IPR, though the system tells me it
may take a day for it to appear.

>>> Minor Concerns:
>>> 
>>> Abstract: Please explain "FAST", perhaps just a pointer to RFC 6113.
>> 
>> We believe this is covered by the "Document conventions" section.
>
> In my opinion, something needs to be in the Abstract.  Otherwise, the
> Abstract is not stand alone.

That makes sense.  If I change

    Second, enable the use of second factor authentication without
    relying on FAST.

to

    Second, enable the use of second factor authentication without the
    need for a separately-established secure channel (FAST).

would that address your concerns?  I'd also be open to leaving out the
parenthetical mention of FAST entirely if you think that's more clear.

Thanks,
--Robbie

---

From: Robbie Harwood <[email-masked]>
Date: Wed, 10 Jun 2020 14:17:06 -0400

> parenthetical mention of FAST entirely if you think that's more clear.

I've opted to make this change, removing explicit mention of FAST
entirely.  It is part of -09.

Thanks,
--Robbie