Re: [HOKEY] Last Call: draft-ietf-hokey-reauth-ps

Alan DeKok <aland@deployingradius.com> Mon, 11 February 2008 07:47 UTC

Return-Path: <hokey-bounces@ietf.org>
X-Original-To: ietfarch-hokey-archive@core3.amsl.com
Delivered-To: ietfarch-hokey-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B49A3A6ACD; Sun, 10 Feb 2008 23:47:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.484
X-Spam-Level:
X-Spam-Status: No, score=-1.484 tagged_above=-999 required=5 tests=[AWL=-1.047, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVm0OGMMILdf; Sun, 10 Feb 2008 23:47:10 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77F9E3A6AB8; Sun, 10 Feb 2008 23:47:10 -0800 (PST)
X-Original-To: hokey@core3.amsl.com
Delivered-To: hokey@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7003A6ABD for <hokey@core3.amsl.com>; Sun, 10 Feb 2008 23:47:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRbZ-GI55Bk1 for <hokey@core3.amsl.com>; Sun, 10 Feb 2008 23:47:07 -0800 (PST)
Received: from deployingradius.com (www.deployingradius.com [216.240.42.17]) by core3.amsl.com (Postfix) with ESMTP id D04C23A68ED for <hokey@ietf.org>; Sun, 10 Feb 2008 23:47:07 -0800 (PST)
Received: from [192.168.0.14] (pas38-1-82-67-71-238.fbx.proxad.net [82.67.71.238]) by deployingradius.com (Postfix) with ESMTP id 7DB2FA704E; Sun, 10 Feb 2008 23:48:22 -0800 (PST)
Message-ID: <47AFFD2A.5030209@deployingradius.com>
Date: Mon, 11 Feb 2008 08:45:46 +0100
From: Alan DeKok <aland@deployingradius.com>
User-Agent: Thunderbird 2.0.0.6 (X11/20071022)
MIME-Version: 1.0
To: Charles Clancy <clancy@cs.umd.edu>
References: <479F4056.2070000@deployingradius.com> <47AF73F5.40306@cs.umd.edu>
In-Reply-To: <47AF73F5.40306@cs.umd.edu>
X-Enigmail-Version: 0.95.0
Cc: hokey@ietf.org
Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-reauth-ps
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: hokey-bounces@ietf.org
Errors-To: hokey-bounces@ietf.org

Charles Clancy wrote:
> WRT AAA proxies, they were not discussed because the PS document makes
> no assumption that AAA will be used for key distribution.

  What else would be used?  This is not a theoretical question...

> WRT key hierarchies, the document says "If a key hierarchy is
> deployed..." so again we don't make any assumption about what the
> solution will be.  We only say that if a hierarchy is used it must not
> be susceptible to the domino effect.

  The document spends a lot of time explaining key hierarchies without
describing the problem that the hierarchies solves.

> Same thing for the architectural diagram... the goal was to minimize our
> influence on the solution -- we're just trying to state the problem.

  I have no idea what problem the document is solving, because it is
carefully not referencing existing definitions, practices or systems.

  The point of such references is not to constrain the solution, but to
define common terms for understanding.  It is not clear to me how this
system would be used in an AAA environment, which is the overwhelmingly
dominant use of EAP.  I don't think that the authors know either.

  As evidence, every attempt to ask questions about real-world (i.e.
AAA) uses of this solution results in discussions of key hierarchies.
You say "IF a hierarchy is used", yet the majority of discussion is
centered around such hierarchies.  This makes it seem like key
hierarchies are a requirement.

  I think the document needs a lot more clarity on WHO is doing WHAT and
WHY.

  Alan DeKok.
_______________________________________________
HOKEY mailing list
HOKEY@ietf.org
http://www.ietf.org/mailman/listinfo/hokey