Subject: [secdir] review of draft-ietf-hokey-arch-design-08

From: Ondřej Surý <[email-masked]>
Date: Mon, 14 Nov 2011 18:01:23 +0800

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

I haven't been following HOKEY at all, so the comments are basically
from innocent bystander who knows as much about EAP as needed to type
the password for WiFi in the 802.1x (and is user of eduroam network).

The HOKEY architectural document seems to be clearly written and can
be understood even by me.  It does not introduce neither any new protocol
nor security issues and is just a summary of existing standards or I-Ds,
so there are no security concerns in this particular document.  Some
security concerns are referenced to other RFCs (Section 7), but they
are just #includes from other documents and not something new introduced
by this document.

One minor nit:

- You suddenly start to use rRK and DSrRK in the tables (4 and 5) in section 5.
It would help readability to explain somewhere what these abbreviations mean.

O.
--
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Glen Zorn <[email-masked]>
Date: Tue, 22 Nov 2011 15:10:36 +0700

> It would help readability to explain somewhere what these abbreviations mean.

How's this:

2.  Terminology

   This document contains no normative language, hence [RFC2119]
   language does not apply.

   This document reuses terms defined in Section 2.2 of Ohba, et al.
   [RFC5836] and Section 2 of Wu, et al.  [I-D.ietf-hokey-rfc5296bis].
   In addition, it defines the following:

   DSrRK
      Domain-Specific reauthentication Root Key.

...

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 22 Nov 2011 09:35:38 +0100

>      Domain-Specific reauthentication Root Key.

That's fine by me.  My sole point was that you did a pretty good job
in explaining all the used terms in the document, so it was readable
even for outsider, with exception of these two.

O.