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

"Paul Miller (NT)" <> Mon, 28 November 2016 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 98CFE129FC5; Mon, 28 Nov 2016 13:53:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id e23NUhI7UJoz; Mon, 28 Nov 2016 13:53:38 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6D74E129FC4; Mon, 28 Nov 2016 13:53:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W3qiSCyn3CbMaCMdN2AG9mXkIXNzYET3u5bQ+uuR2VA=; b=IsEGmYZi6BN5P3+kZt95SxBY6xZHE1nQL9Ab9HuKeSBtG6xaNxF5lPAmLK03O5DDRfdqx9QRd7kD0pwTNrUkuIAsE6kMUWS9p4LBjMkx7SahwHn36U1iTmsgHhzaGmy599UJVIp0FDus987ybLIFfHI2cAb04/rxNB7H0r05MiU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.10; Mon, 28 Nov 2016 21:53:36 +0000
Received: from ([]) by ([]) with mapi id 15.01.0747.015; Mon, 28 Nov 2016 21:53:36 +0000
From: "Paul Miller (NT)" <>
To: Michiko Short <>, Russ Housley <>, "" <>
Thread-Topic: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07
Thread-Index: AQHSSOim1TwCSurl2UuK6ymWpnp7B6Dun6CAgABQlLA=
Date: Mon, 28 Nov 2016 21:53:35 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: [2001:4898:80e8:4::465]
x-ms-office365-filtering-correlation-id: 688fd98a-7707-48b8-c3fa-08d417d9012a
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2317;
x-microsoft-exchange-diagnostics: 1; SN2PR03MB2317; 7:kmWDAlgTmmjipE9XreOKE/aFpeJMIjwyeVTSU59CyqdOjfIdzzejiktSSbROmjGj2hchYfoD1BBs+RAycJnVCNQopyG56fsKhn6UWvr0dLTfSmqFr9ugAynv98pe8jeRN6kjo00GrtNyaohv8kKR/FUREPw/lA+MM0IvI5NEJcs1fkJd8WFO1zYTeLbhYc4eYP/8VZed9G98x3oQM1FHlrrCu51sOqNkYq1G5jqU3JmlmYbmYYSGSev6ipGnWSP29e1UIejYWr2j0gUpEaQxgN+Z2DwLAN3ujXunq9oJ351TmXNzl47CURv9FqHj4uOUukCMuuUHLUI4riv20J0yWgXgOHJ2ItihBeOxa9GG9cZN5zLvufUkX7nzR2/hZ1yaPIaQ77y1TFTCBxPC102l3Es30dyqD18rTbL2CGd0N8PC/uozhsW4iab1c0YGOc1K/jo+W9QYuj8AiYogE1YKQajcvdFxA3Pm1/aveYZE3eE=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045199)(6060326)(6040361)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6061324)(6041248)(6046074)(20161123562025)(20161123564025)(20161123555025)(20161123558021)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2317; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2317;
x-forefront-prvs: 01401330D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(13464003)(189002)(377454003)(377424004)(230783001)(81166006)(10290500002)(6506003)(5005710100001)(81156014)(5660300001)(8990500004)(5001770100001)(8676002)(7736002)(7846002)(2561002)(39450400002)(33656002)(77096006)(76576001)(7696004)(92566002)(3280700002)(68736007)(105586002)(106356001)(102836003)(99286002)(86362001)(86612001)(4326007)(2900100001)(101416001)(2950100002)(106116001)(189998001)(6116002)(38730400001)(122556002)(9686002)(1511001)(305945005)(74316002)(39380400001)(3660700001)(229853002)(2906002)(39410400001)(8936002)(39400400001)(54356999)(2421001)(4001150100001)(50986999)(97736004)(10090500001)(76176999)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR03MB2317;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 21:53:35.9082 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2317
Archived-At: <>
Cc: IETF Gen-ART <>
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Nov 2016 21:53:40 -0000

Minimum length is a problematic topic due to the fact that we intentionally did not specify the format of the freshness token.  Since the structure of the freshness token is left up to the KDC, there is no good way to determine a minimum size.  If the freshness token is a nonce then the size is determined by the birthday problem.  If it is based on symmetric cryptography, then there are different length considerations.  If it is based on asymmetric crypto then there is a third set of size considerations.

A maximum size makes sense as a way to avoid processing messages that are clearly bad.  Is there an accepted value for a worst case CMS signature?

-----Original Message-----
From: Michiko Short [] 
Sent: Monday, November 28, 2016 8:59 AM
To: Russ Housley <>;
Cc: IETF Gen-ART <>
Subject: RE: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

The size issue a is big one for this late in the process as it never came up before. We would have to bring it up to the WG for discussion. Is this required? 

Happy to submit an updated version with the client & KDC flipped, first reference of KDC in abstract spelled out, and 2.1 PA_AS_FRESHNESS referencing 4. Just tell me when I can make the updates.

-----Original Message-----
From: Russ Housley [] 
Sent: Sunday, November 27, 2016 11:55 AM
Cc: IETF Gen-ART <>
Subject: Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

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


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