[Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Russ Housley <housley@vigilsec.com> Sun, 27 November 2016 19:58 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8F80C12953C for <gen-art@ietfa.amsl.com>; Sun, 27 Nov 2016 11:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id wMjDvjmdEts0 for <gen-art@ietfa.amsl.com>; Sun, 27 Nov 2016 11:58:34 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0A612951B for <gen-art@ietf.org>; Sun, 27 Nov 2016 11:58:33 -0800 (PST)
Received: from localhost (localhost []) by mail.smeinc.net (Postfix) with ESMTP id 55C78300AEF for <gen-art@ietf.org>; Sun, 27 Nov 2016 14:48:16 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([]) by localhost (mail.smeinc.net []) (amavisd-new, port 10026) with ESMTP id 3PanmimfPqNN for <gen-art@ietf.org>; Sun, 27 Nov 2016 14:48:15 -0500 (EST)
Received: from [] (pool-108-45-101-150.washdc.fios.verizon.net []) by mail.smeinc.net (Postfix) with ESMTPSA id E68AD300429; Sun, 27 Nov 2016 14:48:14 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com>
Date: Sun, 27 Nov 2016 14:54:42 -0500
Content-Transfer-Encoding: 7bit
Message-Id: <0AD0BB5E-1539-4C38-99A4-B40AD4E9D9A1@vigilsec.com>
References: <EE7359A5-ACD3-4CD1-B1B0-E01579203FFE@gmail.com>
To: draft-ietf-kitten-pkinit-freshness.all@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/_54sO6OSM1T2H4KU_aiB0K86djk>
Cc: IETF Gen-ART <gen-art@ietf.org>
Subject: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 27 Nov 2016 19:58:35 -0000

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 wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-kitten-pkinit-freshness-07
Reviewer: Russ Housley
Review Date: 2016-11-27
IETF LC End Date: 2016-11-03
IESG Telechat date: 2016-12-01

Summary: Almost Ready

Major Concerns

I understand that freshness tokens provide corroboration that the
client had access to the private key at the time that the AS-REQ
was constructed.  I also understand that the freshness tokens do not
have to be single use tokens for specific AS exchanges.  However,
some guidance on the minimum size of the freshness token seems to be
appropriate.  If the freshness token is too small, then the client
could be generate signatures using all of the possible token values
at when it does have access to the private key, offering the one that
matches the freshness token during the exchange with the KDC.  Please
specify a minimum size for the freshness token.

Please add a discussion of the minimum freshness token size to
Section 7 (Security Considerations).

Question: Is there a reson to specify a maximum size for the freshness
token?  If an implementor knows that the freshness token will be under
some maximum, then the code can incorporate that information into the
buffer management and easily discard any KRB-ERROR messages that exceed
that maximum.

Minor Concerns

In the Abstract and Section 1 (Introduction), please spell out KDC the
first time the acronym is used.

In Section 2.2 (Generation of KRB_ERROR Message), please give the reader
a heads up that PA_AS_FRESHNESS is defined in this document.  I went
looking for it in RFC 4120; a pointer could have avoided this wild goose


In Figure 1, since the client begins the conversation, it would read
better if the Client were on the left side of the figure.