Subject: Re: [HOKEY] New Version Notification for draft-hoeper-hokey-arch-design-03

From: "Hoeper Katrin-QWKN37" <[email-masked]>
Date: Fri, 16 Jul 2010 11:10:33 -0400

Tom, Thanks for the revision.

All, I believe the draft addresses the previous discussions and is ready
to be accepted as a WG item now.
 
Please find my comments below. 
 
Regards,
Katrin

 GENERAL COMMENTS
 I think the draft really improved, esp. Section 5.
 
 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 in-
 direct) 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 both approaches wrt the HOKEY architecture should
be
 explained in Section 1 as well, i.e. AAK does not require any
 authentication, only key distribution.

 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."
 
 Even though the first sentence refers to re-authentication *and* early
 authentication, the remainder of the paragraph only discusses why this
 HOKEY architecture draft is necessary for successful implementation of
EAP
 re-authentication. I suggest adding a sentence emphasizing why this
 document is also necessary for successful implementation of an early
 authentication solution.
 
 Secondly, I think a brief description of ER server needs to be included
 here replacing the reference.
 
 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."
 
 I suggest deleting the first sentence to focus on the actual design
goal.
 Review of ERP should be completed in Section 1.
 
 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
 The title of the section is "Functions That Must Be Supported". I am
 wondering if this contradicts the statement in Section 2 "This document
 contains no normative language, hence [RFC2119] language does not
apply."
 
 Isn't the MUST in the title to be meant in a normative way?
 
 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. May be add "candidate access
 point" after "at each".

 

> 
> > -----Original Message-----
> > From: IETF I-D Submission Tool [mailto:[email-masked]]
> > Sent: Monday, July 12, 2010 11:06 AM
> > To: [email-masked]
> > Cc: Hoeper Katrin-QWKN37; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: New Version Notification for
draft-hoeper-hokey-arch-design-03
> >
> >
> > A new version of I-D, draft-hoeper-hokey-arch-design-03.txt has been
> > successfully submitted by Tom Taylor and posted to the IETF
repository.
> >
> > Filename:	 draft-hoeper-hokey-arch-design
> > Revision:	 03
> > Title:		 Handover Keying (HOKEY) Architecture Design
> > Creation_date:	 2010-07-12
> > WG ID:		 Independent Submission
> > Number_of_pages: 18
> >
> > Abstract:
> > The Handover Keying (HOKEY) Working Group seeks to minimize handover
> > delay due to authentication when a peer moves from one point of
> > attachment to another.  Work has progressed on two different
> > approaches to reduce handover delay: early authentication (so that
> > authentication does not need to be performed during handover), and
> > reuse of cryptographic material generated during an initial
> > authentication to save time during re-authentication.  A starting
> > assumption is that the mobile host or "peer" is initially
> > authenticated using the Extensible Authentication Protocol (EAP),
> > executed between the peer and an EAP server as defined in RFC 3748.
> >
> > This document documents the HOKEY architecture.  Specifically, it
> > describes design objectives, the functional environment within which
> > handover keying operates, the functions to be performed by the HOKEY
> > architecture itself, and the assignment of those functions to
> > architectural components.  It goes on to illustrate the operation of
> > the architecture within various deployment scenarios that are
> > described more fully in other documents produced by the HOKEY
Working
> > Group.
> > The IETF Secretariat.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 19 Jul 2010 22:21:07 -0400

Thank you very much for the review. Basically I agree with you. I had some 
comments, marked with [PTT].

Hoeper Katrin-QWKN37 wrote:
> All, I believe the draft addresses the previous discussions and is ready to
> be accepted as a WG item now.
> 
> Regards, Katrin
> GENERAL COMMENTS I think the draft really improved, esp. Section 5.
> 
> 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 in- direct)
> 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
> both approaches wrt the HOKEY architecture should be explained in Section 1
> as well, i.e. AAK does not require any authentication, only key distribution.
> 
[PTT] OK
> 
> 
> 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"."

[PTT] OK, and here is where I spell out the difference between 
pre-authentication and AAK.
> 
> 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."
> 
> authentication, the remainder of the paragraph only discusses why this HOKEY
> architecture draft is necessary for successful implementation of EAP 
> re-authentication. I suggest adding a sentence emphasizing why this document
> is also necessary for successful implementation of an early authentication
> solution.

[PTT] Good point.
> 
> Secondly, I think a brief description of ER server needs to be included here
> replacing the reference.

[PTT] OK
> 
> 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."
> 
> I suggest deleting the first sentence to focus on the actual design goal. 
> 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."

[PTT] OK. I did have a bit of trouble with this objective because of the claim 
that it should be available at layer 2. As you can see later on, I waffled.
> 
> Section 4 The title of the section is "Functions That Must Be Supported". I
> am wondering if this contradicts the statement in Section 2 "This document 
> contains no normative language, hence [RFC2119] language does not apply."
> 

[PTT] I generally view normative language directed at specification writers 
(which is what this is) as outside the scope of RFC 2119.
> 
> 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.

[PTT] I suppose that's a good idea. I got into "subsystem" in the first place 
because you can't provide a sensible description without EAP authentication as 
part of it, even though that work pre-dates HOKEY.
> 
> Section 4.2 Have trouble parsing the first sentence. May be add "candidate
> access point" after "at each".

[PTT] OK
> 
> 
> 
> 
> 
> 
> 
> 
> 
>>> -----Original Message----- From: IETF I-D Submission Tool
>>> [mailto:[email-masked]] Sent: Monday, July 12, 2010 11:06 AM To:
>>> [email-masked] Cc: Hoeper Katrin-QWKN37; [email-masked];
>>> [email-masked]; [email-masked] Subject: New Version Notification
>>> for
>>> Filename:	 draft-hoeper-hokey-arch-design Revision:	 03 Title:		 Handover
>>> Keying (HOKEY) Architecture Design Creation_date:	 2010-07-12 WG ID:
>>> Independent Submission Number_of_pages: 18
>>> 
>>> Abstract: The Handover Keying (HOKEY) Working Group seeks to minimize
>>> handover delay due to authentication when a peer moves from one point of 
>>> attachment to another.  Work has progressed on two different approaches
>>> to reduce handover delay: early authentication (so that authentication
>>> does not need to be performed during handover), and reuse of
>>> cryptographic material generated during an initial authentication to save
>>> time during re-authentication.  A starting assumption is that the mobile
>>> host or "peer" is initially authenticated using the Extensible
>>> Authentication Protocol (EAP), executed between the peer and an EAP
>>> server as defined in RFC 3748.
>>> 
>>> architectural components.  It goes on to illustrate the operation of the
>>> architecture within various deployment scenarios that are described more
>>> fully in other documents produced by the HOKEY
> Working
>>> Group.
>>> 
>>> 
>>> 
>>> The IETF Secretariat.
>>> 
> 
> _______________________________________________ HOKEY mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/hokey
> 
>