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

[Glen Zorn <[e-mail]>]

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
< http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.