Re: [HOKEY] Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)

Glen Zorn <> Thu, 29 December 2011 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D70621F8669; Thu, 29 Dec 2011 01:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fFQzpIck8v7g; Thu, 29 Dec 2011 01:53:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B99C521F861E; Thu, 29 Dec 2011 01:53:35 -0800 (PST)
Received: by iabz21 with SMTP id z21so1510643iab.31 for <multiple recipients>; Thu, 29 Dec 2011 01:53:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=JUMysqFcA9fZT6GVIK0sd43VuOEB5ZEPrEzqITnJNng=; b=n2XodmTadRoukLXfGPRucjT7hpdzyRekTWZtarqGa072i8BYcU6+RZKx8xkn4qh0Ay FwS/abr2Mg8DI/zg1rAKnmQq/Y0XZkzghwJUJczn5ToB3XG7Nzo7C2d1NiTNliY7WvuQ xA+yLQk1mnjSLr+tNtlqKD1q1xA2lW5EbDHAo=
Received: by with SMTP id qo1mr40404029igc.22.1325152415340; Thu, 29 Dec 2011 01:53:35 -0800 (PST)
Received: from [] ( []) by with ESMTPS id l35sm113164775ibj.0.2011. (version=SSLv3 cipher=OTHER); Thu, 29 Dec 2011 01:53:33 -0800 (PST)
Message-ID: <>
Date: Thu, 29 Dec 2011 16:53:27 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: Russ Housley <>,
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: The IESG <>, "" <>,
Subject: Re: [HOKEY] Russ Housley's Discuss on draft-ietf-hokey-arch-design-10: (with DISCUSS)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: HOKEY WG Mailing List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Dec 2011 09:53:36 -0000

Sorry for the delayed reply; I have been ill.  In any case, the gen-art
review is reproduced below, with comments.

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

> Document:  draft-ietf-hokey-arch-design-03
> Reviewer:  Richard Barnes
> Review Date: 2011-11-23
> IETF LC End Date:
> IESG Telechat date: 2011-12-01
> Summary:  Largely complete, but hard to use
> Major issues:
> The document seems to make several architectural assumptions that are
> not clearly stated.  For example, both this document and the HOKEY
>  problem statement [RFC5169] make reference to "home" and "visited"
> networks, terms which are defined in neither document.  It would be
> helpful if this document could clarify some of these issues that are 
> left vague by the problem statement.

The terms "home network" and "visited network" have been in common usage
in the roaming community for at least 10 years.

> Likewise, the document states the architecture in terms of several "
> functions" that are performed by "components".  For a reader
> unfamiliar with the history of this document, it is not clear how
> these functions work together to solve the problems laid out in RFC
> 5169.

Since this document attempts to describe the entire hokey architecture
of which re authentication and key management (the subjects of RFC 5169)
are only portions (the other major component being early authentication,
discussed in RFC 5836), I don't think that it is particularly surprising
that there is not a one-to-one mapping.  That said, however, I find this
comment quite amorphous, bordering upon "I don't understand", and not
very useful.  Some specific, actionable suggestions would be much
appreciated; note that 'add an (unspecified) reference" is not part of
that set.

> The components are also given suggestive names, but not defined.  For
> example, there are components named "serving authenticator" and
> "candidate authenticator", whose names seem to imply that they play
> particular roles in the protocol or occupy particular places in the
> network.  But the document never explains this beyond the names.

"Candidate Authenticator" is defined in Section 2 of RFC 5836 (see
below), which is referenced in Section 2 of the document under
discussion.  I can add the following definition to Section 2 of the
draft if necessary:

   Serving Authenticator (SA)
      The EAP authenticator on the SAP [RFC5826].

Minor issues:

Editorial nits:

Version -10 appears to have introduced the term "DSrRK", which appears
nowhere else in the document.

"DSrRK" appears in Tables 4 and 5.