IETF Logo Mail Archive

Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

Michiko Short <michikos@microsoft.com> Tue, 22 March 2016 17:20 UTC

Return-Path: <michikos@microsoft.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 9585A12D19A; Tue, 22 Mar 2016 10:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 KRvZ-rgBfa3D; Tue, 22 Mar 2016 10:20:30 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0763.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:763]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C60812D199; Tue, 22 Mar 2016 10:20:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GkIh/iX88Te8kGEf172N+TDdmH6fet4aRN8mP3m4Dtw=; b=k55iC8mRLxIsTma+whoe7W1Flb7vJXo50+v36VSCyvyx4eoPKsP6AIZrs6wBtZpNKrOAXbiJUnqy66bhy51GOIQz35H99wI9iDnlOr5lNVhigtCBVOEoDziwOnRijyO327iWt8R3dKKkHHFmfw96Qh6/21PpgbgXduRUiAFV0Pg=
Received: from BY1PR03MB1417.namprd03.prod.outlook.com (10.162.127.147) by SN1PR0301MB1966.namprd03.prod.outlook.com (10.163.224.28) with Microsoft SMTP Server (TLS) id 15.1.434.16; Tue, 22 Mar 2016 17:20:12 +0000
Received: from BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) by BY1PR03MB1417.namprd03.prod.outlook.com ([10.162.127.147]) with mapi id 15.01.0434.021; Tue, 22 Mar 2016 17:20:12 +0000
From: Michiko Short <michikos@microsoft.com>
To: Greg Hudson <ghudson@mit.edu>, Rick van Rein <rick@openfortress.nl>, "Paul Miller (NT)" <paumil@microsoft.com>
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt
Thread-Index: AQHRg8GWvlYn3zxL8kKg64f1UsNf8J9knzUAgAAQtICAAFw4gIAAXmSAgABI8fA=
Date: Tue, 22 Mar 2016 17:20:11 +0000
Message-ID: <BY1PR03MB1417EBB6878983B57073528CD0800@BY1PR03MB1417.namprd03.prod.outlook.com>
References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl> <BLUPR0301MB1953F7DDC9FD35D3139F4F20CD800@BLUPR0301MB1953.namprd03.prod.outlook.com> <56F0EFBD.90800@openfortress.nl> <56F13EEB.70502@mit.edu>
In-Reply-To: <56F13EEB.70502@mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:1::409]
x-ms-office365-filtering-correlation-id: 2723d4e2-326d-4f43-0a6d-08d3527639f5
x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1966; 5:FJNwaeop99ePqi9LlX5TyI5y0r6YT5+/3YoDHEEYU9hDVHyFvS1FG57/BVjUgK5FsDQ6zyfC4G+bqDDIkWrA4e/r1rhlfPxwrtywtjWNyeQs36f/IeZMaaw4VluSdLMfEbSGBtOqvlwAPBaT2LRMuA==; 24:FOVmUkjWmHzdctBs2qWm0j9QIBjJmI5IaiHNX8PhefQV7xIfN40CL9Z9Bm2OLs0mfE/VJrW5ThvjFfn5rj0fKFXB8FK8Mhf0sYFrcpuYzks=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1966;
x-microsoft-antispam-prvs: <SN1PR0301MB1966B2AB4520FABE3BD9B03CD0800@SN1PR0301MB1966.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:SN1PR0301MB1966; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1966;
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(52314003)(24454002)(5001770100001)(122556002)(3660700001)(74316001)(10290500002)(5008740100001)(11100500001)(3280700002)(8990500004)(189998001)(5005710100001)(2900100001)(77096005)(5002640100001)(81166005)(2950100001)(93886004)(5003600100002)(2906002)(10400500002)(4001450100002)(10090500001)(4326007)(2561002)(19580395003)(102836003)(76176999)(99286002)(19580405001)(6116002)(5004730100002)(1096002)(230783001)(586003)(92566002)(76576001)(33656002)(54356999)(106116001)(1220700001)(86362001)(2171001)(87936001)(2421001)(50986999)(86612001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0301MB1966; H:BY1PR03MB1417.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Mar 2016 17:20:11.9788 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1966
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/uTHYz65okwN6oXhpGYwykWyi0V8>
Cc: "kitten@ietf.org" <kitten@ietf.org>, "draft-ietf-kitten-pkinit-freshness@ietf.org" <draft-ietf-kitten-pkinit-freshness@ietf.org>
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.17
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, 22 Mar 2016 17:20:32 -0000

Since the infinite loop problem exists for Kerberos clients already, I would prefer to not specify something since this is an extension to an extension.

However, the must is valid. Not sure how we all missed that. 
"If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it SHOULD retry using the new freshness token."

I would really like to get this to last call and get the official IANA number

-----Original Message-----
From: Greg Hudson [mailto:ghudson@mit.edu] 
Sent: Tuesday, March 22, 2016 5:48 AM
To: Rick van Rein <rick@openfortress.nl>; Paul Miller (NT) <paumil@microsoft.com>
Cc: kitten@ietf.org; draft-ietf-kitten-pkinit-freshness@ietf.org
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

On 03/22/2016 03:09 AM, Rick van Rein wrote:
>> It is the responsibility of the client not to retry indefinitely.
> 
> May I suggest that you state that in the text?  The current draft is a procedure, and could benefit from invariant statements to clarify the cases that fall outside of the intended procedure.

If I understand correctly, we are worried about an infinite loop of AS-REQ -> KDC_ERR_PREAUTH_EXPIRED -> AS-REQ -> ... due to the section 2.5.

If we need to alter this text anyway, I don't like the requirement that "If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that includes a freshness token, it MUST retry using the new freshness token."  MUSTs are to be used when behavior "is actually required for interoperation or to limit behavior which has potential for causing harm" (RFC 2119 section 6).  A client which implements RFC 6113 could respond to KDC_ERR_PREAUTH_EXPIRED the same way it already does, by retrying from the beginning, without affecting interoperability or causing harm.

I suggest the following text:

  If a client receives a KDC_ERR_PREAUTH_EXPIRED KRB_ERROR message that
  includes a freshness token, it SHOULD retry the PKINIT-authenticated
  AS-REQ using the new freshness token.  The client MAY restart the
  conversation instead.  The client MUST limit the number of retries to
  avoid looping forever in case of a misbehaving KDC.

v2.23.0 | Report a Bug | By Email