Subject: [HOKEY] comments draft-ietf-hokey-arch-design-00

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Fri, 10 Sep 2010 11:48:58 -0400

Hello,

I have some editorial comments that didn't make it into the -00 version.

GENERAL COMMENTS

While the missing (architecture) pieces of EAP re-authentication have
been well identified and discussed, I think there is still some
inconsistency for the "early authentication". Section 1 talks about
"early authentication", while most of the remainder focuses on (direct
and indirect) pre-authentication. Then AAK is mentioned in Section 4. I
suggest for better readability and consistency, pre-auth and AAK should
be mentioned in the introduction (Section 1) and defined in Section 2.
The differences between these approaches wrt the HOKEY architecture
should be explained in Section 1 as well.

SPECIFIC COMMENTS

Section 1, 1st paragraph on page 5

"[RFC5749] provides an abstract mechanism for distribution of keying
material from the EAP server to re-authentication servers.  (The stated
scope is more general, but is restated in terms consistent with the
present summary.) [RFC5836] contrasts the EAP re-authentication (ER)
strategy provided by [RFC5296] (which [RFC5836] calls "vertical context
transfer") with an alternative strategy called "early authentication"."

Suggest changing to something like:

 "For the purpose of this draft, [RFC5749] provides an abstract
mechanism for distribution of keying material from the EAP server to re-
authentication servers. [RFC5836] contrasts the EAP re-authentication
(ER) strategy provided by [RFC5296] with an alternative strategy called
"early authentication"."

Section 1, 3rd paragraph on page 5

"Both EAP re-authentication and early authentication enable faster
inter-authenticator handovers.  However, it is currently unclear how the
necessary handover infrastructure for ER is deployed and can be
integrated into existing EAP infrastructures.  In particular, previous
work has not described how ER servers (as defined below) should be
integrated into local and home domain networks."

Suggest changing to:

"Both EAP re-authentication and early authentication enable faster
inter-authenticator handovers.  However, it is currently unclear how

the necessary handover infrastructure is deployed and can be integrated
into existing EAP infrastructures.  In particular, previous work has not
described how ER servers that act as endpoints in the re-authentication
process should be integrated into local and home domain networks.
Furthermore, it is currently unspecified how EAP infrastructure can
support the timely triggering of early authentications and aid with the
selection of candidate access points.

 Section 3.1.2

 "3.1.2  Integrated Local Domain Name (LDN) Discovery  Ideally, whenever
a peer performs a handover, ERP is executed between the  peer and a
local ER server, thus, reducing handover latency by avoiding a  full EAP
authentication with the peer's home EAP server. For this to work, ERP
bootstrapping must occur before (implicit) or during (explicit) a
handover to transport the necessary re-authentication root keys to the
local ER server involved.  Implicit bootstrapping is preferable because
it does not require communication with the home ER server during
handover (see previous section), but it requires the peer to know the
domain name  of the ER server in order to derive the necessary
re-authentication keying  material. [RFC5296] does not specify such a
domain name discovery mechanism and suggests that the peer may learn the
domain name through the EAP-Initiate/Re-auth-Start message or via lower
layer announcements.  To allow more efficient handovers, a HOKEY
architecture should support an efficient domain name discovery mechanism
and allow its integration with  ERP implicit bootstrapping.  Even in the
case of explicit bootstrapping, local domain name discovery should be
optimized such that it does not  require contacting the home AAA server,
as is currently the case."

 Change to:

"3.1.2.  Integrated Local Domain Name (LDN) Discovery  ERP bootstrapping
must occur before (implicit) or during (explicit) a  handover to
transport the necessary re-authentication root keys to the  local ER
server involved.  Implicit bootstrapping is preferable because it  does
not require communication with the home ER server during handover  (see
previous section), but it requires the peer to know the domain name  of
the ER server in order to derive the necessary re-authentication keying
material.

 [RFC5296] does not specify such a domain name discovery mechanism and
suggests that the peer may learn the domain name through the EAP-
Initiate/Re-auth-Start message or via lower layer announcements.  To
allow more efficient handovers, a HOKEY architecture should support an
efficient domain name discovery mechanism and allow its integration with
ERP implicit bootstrapping.  Even in the case of explicit bootstrapping,
local domain name discovery should be optimized such that it does not
require contacting the home AAA server, as is currently the case."

Section 4.1

I personally find it confusing to sometimes talk about "HOKEY
architecture", then about "authentication subsystem" and then also throw
network access authentication in the mix. After reading the draft for
the second time I see the value of using "authentication subsystem" but
may be this terminology should be  introduced earlier on. Because
frankly when we say architecture we only focus on the authentication
part, no? So may be this should be clarified  in Section 1 and not
introduced in Section 4.

Section 4.2

Have trouble parsing the first sentence. Suggest adding "candidate
access point" after "at each".

Section 11 Informative References

Remove [RFC5247] because there is no reference to it.

Regards,

Katrin