IETF Logo Mail Archive

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

Robbie Harwood <rharwood@redhat.com> Tue, 02 June 2020 21:59 UTC

Return-Path: <rharwood@redhat.com>
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 53A8F3A1046 for <kitten@ietfa.amsl.com>; Tue, 2 Jun 2020 14:59:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 5X8AkVHp_Ytv for <kitten@ietfa.amsl.com>; Tue, 2 Jun 2020 14:59:39 -0700 (PDT)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8C53A103C for <kitten@ietf.org>; Tue, 2 Jun 2020 14:59:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1591135178; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EEIlnzd0QSQBCfuNLDSBNRjN4pJmPVp4CQX1IsKOdJ8=; b=EoPdGMW9FFjvBUX3afJVvcRgVYWcCW0sPSgGfsW627OGP/aKK3KAn6DlKYvJKh1uKBCMBo gDoUfRrCQaVZM+7G6qJKQ/U7hbMjdRmuVEIMNppwcGtg16lf+Tw21r+67trp8TxBFSdpaS j08589gjh61OilJ2dh0yIxFqFqglFHY=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-248-Og-1v3ZzMLinln2g0hv71g-1; Tue, 02 Jun 2020 17:57:53 -0400
X-MC-Unique: Og-1v3ZzMLinln2g0hv71g-1
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 051941856959; Tue, 2 Jun 2020 21:57:52 +0000 (UTC)
Received: from localhost (unknown [10.10.110.64]) by smtp.corp.redhat.com (Postfix) with ESMTP id C42495C28E; Tue, 2 Jun 2020 21:57:51 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Russ Housley <housley@vigilsec.com>
Cc: IETF Gen-ART <gen-art@ietf.org>, kitten@ietf.org, last-call@ietf.org, draft-ietf-kitten-krb-spake-preauth.all@ietf.org
In-Reply-To: <7B24DD80-0A21-41F1-8E6A-CDE6279F0350@vigilsec.com>
References: <158956185809.27642.15651397749101904532@ietfa.amsl.com> <jlgftbjelvc.fsf@redhat.com> <7B24DD80-0A21-41F1-8E6A-CDE6279F0350@vigilsec.com>
Date: Tue, 02 Jun 2020 17:57:48 -0400
Message-ID: <jlgr1uxdtb7.fsf@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/ZUUWUjq5h4eAXyMixRot3u0rNuM>
Subject: Re: [kitten] [Last-Call] Genart last call review of draft-ietf-kitten-krb-spake-preauth-07
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: Tue, 02 Jun 2020 21:59:40 -0000

Russ Housley <housley@vigilsec.com> writes:

>> On May 28, 2020, at 6:27 PM, Robbie Harwood <rharwood@redhat.com> wrote:
>> 
>> Signed PGP part
>> Russ Housley via Datatracker <noreply@ietf.org> 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

v2.23.0 | Report a Bug | By Email