Subject: [HOKEY] Review of draft-hoper-hokey-arch-design-02

From: Mark Jones <[email-masked]>
Date: Tue, 20 Apr 2010 14:58:00 -0400

I volunteered to review this I-D at IETF77.

---

General Comments:

It is fair to say that this is still very much a work-in-progress
(lots of TBDs). I think it does a reasonable job of describing the
architecture but it is sometimes unclear which components/functions
are already adequately specified by existing RFCs and which require
new specification work.
In its current state, I think it probably serves more as a "TODO list"
for the HOKEY WG than a complete architecture document. That said, I
like the structure (esp. section 4) and it will eventually provide a
much needed roadmap through the various HOKEY RFCs and drafts.
I suggest adding editor's notes to clearly identify where new
specification work is required.

Abstract:

Expand HOKEY and EAP acronyms.

1. Introduction

   "Section 5.4 of [RFC5169] points out requirements related to
   authorization that must be satisfied by a solution providing improved
   re-authentication performance.  "

   Section 5.4 appears to discuss vulnerabilities and I can't find any
requirements in the section.

2. Design Goals

Are these in addition to the goals expressed in RFC5169?
In the following subsections, it is difficult to determine which goals
are already addressed by existing RFC and which require new
specifications.

3.4.  Enabling Protocol Interoperability

I did not understand this section. An expanded example might help here.
s/authe ntication/authentication

4.3.1.  Local Domain Name (LDN) Discovery

Presumably this mechanism is only required when the local domain name
can not be learned via the lower layer.  Is the intention to define
the mechanism in this document? Or simply flag that it is missing?

4.3.2.  Authentication Capability Discovery

s/configurations/deployment scenarios/

4.3.3.  Authenticator Discovery

Section 7.1 in the ietf-hokey-preauth-ps draft also describes a
"link-layer-independent mechanism for obtaining neighboring network
information". Is this insufficient? If not, why?

4.4.  HOKEY Local ER Server Authorization

s/currently implemented/implemented/

6.1.  Early Authentication Scenarios

   "An obvious preliminary remark is that the three models require
   different protocols and procedures, and it would be desirable to
   standardize just one of them to avoid redundant implementation
   effort."

This sounds like a Design Goal and should be stated in section 3. The
6.1.x subsections look like they belong in the pre-auth problem
statement draft.

6.2.1.  ER Server Located In the Home Domain

IMO this scenario is sufficiently well described in RFC5296 (except
for LDN Discovery but that is not resolved here either). If you decide
to keep the procedure here then I suggest adding the step numbers to
figure 4.

6.2.2.  ER Server In the Local Domain

Add the step numbers to figure 5.

6.3.  EAP Early Re-authentication

How does this sketch relate to the hokey-erp-aak draft? I suggest this
sketch be posted to the list for discussion rather that included for
review in an architecture document.

---

Regards
Mark

---

From: Tom Taylor <[email-masked]>
Date: Thu, 22 Apr 2010 11:15:26 -0400

Thanks a lot for this review. I'll discuss this with my co-authors and get back 
to you.

Mark Jones wrote:
> _______________________________________________
> HOKEY mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hokey
> 
>