IETF Logo Mail Archive

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

"Paul Miller (NT)" <paumil@microsoft.com> Tue, 22 March 2016 01:39 UTC

Return-Path: <paumil@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 377E812D111; Mon, 21 Mar 2016 18:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
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: 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 NROa7fu8-zHk; Mon, 21 Mar 2016 18:39:48 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0112.outbound.protection.outlook.com [65.55.169.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4231E12D0F3; Mon, 21 Mar 2016 18:39:48 -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=v2ifOo2DJCv4lKVZyx4bLivgC91NJsVhvZpCEhIc2f0=; b=AjDvmd22ZJQFx58uRFLTdnNPiyw9b8s40HgcTmjKM9RQPjeAQmINRmsrB4X1SNbowV5qkEMUo+3TFhxO+r3V98b7F1Z6lZR0zikx7g+gpf9NKPKVQQuUzGCoxE7Z/i9u1rDNh1zybOQc7JkRG3XyZ5vPGD0ZJe4kwj293MiXQ64=
Received: from BLUPR0301MB1953.namprd03.prod.outlook.com (10.164.21.23) by BLUPR0301MB1956.namprd03.prod.outlook.com (10.164.21.26) with Microsoft SMTP Server (TLS) id 15.1.443.12; Tue, 22 Mar 2016 01:39:46 +0000
Received: from BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) by BLUPR0301MB1953.namprd03.prod.outlook.com ([10.164.21.23]) with mapi id 15.01.0443.013; Tue, 22 Mar 2016 01:39:46 +0000
From: "Paul Miller (NT)" <paumil@microsoft.com>
To: Rick van Rein <rick@openfortress.nl>, "draft-ietf-kitten-pkinit-freshness@ietf.org" <draft-ietf-kitten-pkinit-freshness@ietf.org>
Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt
Thread-Index: AQHRg8GWtCp3jmD5Tk6ckYP7s1nvPZ9knzUAgAAPHEA=
Date: Tue, 22 Mar 2016 01:39:45 +0000
Message-ID: <BLUPR0301MB1953F7DDC9FD35D3139F4F20CD800@BLUPR0301MB1953.namprd03.prod.outlook.com>
References: <20160321223215.12211.35084.idtracker@ietfa.amsl.com> <56F0945E.5070804@openfortress.nl>
In-Reply-To: <56F0945E.5070804@openfortress.nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: openfortress.nl; dkim=none (message not signed) header.d=none;openfortress.nl; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2601:600:8600:6913:e926:5952:63fa:d2e6]
x-ms-office365-filtering-correlation-id: e4e3b11d-3ba4-4dc1-c98f-08d351f2d986
x-microsoft-exchange-diagnostics: 1; BLUPR0301MB1956; 5:9Wgd4gEir1KXxdxMnlS+WGPfLqmiHWbvYYX1nk2s4/JkVPf7XTUw9EYlUaqzWLOJzt2RnQ+9OEluz+sUP5UYxJP2zhcTsyK7yaPaHHHV/cBiPlBRNvbnUGAywDfv/JhWTDgk5C+7iLvRbp45Kq8jVA==; 24:VU0PRYmhLkd8rqWH0I2Q0YX+Ek6E7DNJbk21/yu2F7FpqnNJuXtbImcjxOlliCiysAaVPbOs+FNVfTyfz/QyRTS96s+GVmcrBlXmFN+boSo=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0301MB1956;
x-microsoft-antispam-prvs: <BLUPR0301MB19563EC6959E7848AC2C5567CD800@BLUPR0301MB1956.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR0301MB1956; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0301MB1956;
x-forefront-prvs: 08897B549D
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(10090500001)(230783001)(10290500002)(76576001)(86362001)(2906002)(551544002)(586003)(5005710100001)(1096002)(33656002)(4326007)(50986999)(3280700002)(10400500002)(1220700001)(54356999)(76176999)(5002640100001)(122556002)(92566002)(77096005)(3660700001)(8990500004)(106116001)(2950100001)(2501003)(5008740100001)(81166005)(102836003)(99286002)(6116002)(189998001)(87936001)(5003600100002)(19580405001)(5001770100001)(5004730100002)(2900100001)(86612001)(74316001)(11100500001)(19580395003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0301MB1956; H:BLUPR0301MB1953.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 01:39:46.0140 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0301MB1956
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/qwaLoskmigRleIlvHyAiRecVrCI>
Cc: "kitten@ietf.org" <kitten@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 01:39:50 -0000

The KDC is stateless, so as far as the KDC is concerned there is nothing to do about that cycle.  It is the responsibility of the client not to retry indefinitely.

It's really no different than the behavior already expected of clients with respect to KDC_ERR_TIME_SKEW and password.  If the client cannot agree with a KDC on a time then it needs to stop retrying.  The conditions to cause this are nearly identical as it would require that the client to round-robin different KDCs that have sufficient time skew from each other not to accept each other's time/freshness token for password/certificate respectively.

-----Original Message-----
From: Rick van Rein [mailto:rick@openfortress.nl] 
Sent: Monday, March 21, 2016 5:40 PM
To: draft-ietf-kitten-pkinit-freshness@ietf.org
Cc: kitten@ietf.org
Subject: Re: [kitten] I-D Action: draft-ietf-kitten-pkinit-freshness-05.txt

Hi,

> Abstract:
> This document describes how to further extend the Public Key 
> Cryptography for Initial Authentication in Kerberos (PKINIT) extension 
> [RFC4556] to exchange an opaque data blob that a KDC can validate to 
> ensure that the client is currently in possession of the private key 
> during a PKINIT AS exchange.
>
If I read the draft correctly, then failure of the client to comply with the KDC's idea of proper freshness quoting can end up in an infinite cycle of KRB-ERROR with freshness tokens?  There is a remark about receiving the second KRB-ERROR with a freshness token (not of the first) but nothing seems to be limiting the number of freshness token handling cycles.  Did I miss that?

-Rick

v2.23.0 | Report a Bug | By Email