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

From: Qin Wu <[email-masked]>
Date: Wed, 14 Apr 2010 16:57:29 +0800

Hi,

In Anaheim I volunteered to review this I-D. I would say I have no technical comments. See my initial comments inline Comments are prefixed with [Qin].
Hope it helps.
---------------------------------------------------------------------------------------------
In the Abstract

   HOKEY 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 reducing handover delay:
   ..................................
   
   [Qin]: s/reducing/reduce
   
   early authentication, and reuse of cryptographic material generated during an initial authentication to save time during re-
   authentication.  
   
   [Qin]: I am wondering what the best way is to describe the difference between
   Early authentication and Re-authentication. what is confusing here is each
   authentication comprise two part: 
   1. Authentication procedure
   2. Key Management
   So here it is a little bit strange for us to compare authentication part in early authentication 
   with key managment part in re-authentication. But from the handover optimization perspective,
   I think Early authentication is actually not used for save handover delay but complete authentication
   in advance before handover. Comparing with Early authentication, Re-authentication can be optimized 
   in two ways. One way is to what you said here, another way is to perform Re-authentication in the local
   domain without communciation with home server. Hope this clarify.
   
In the section 1:
   When a host (or "peer", the term used from this point onward) changes
   its point of attachment to the network, it must be re-authenticated.
   If a full EAP authentication must be repeated, several message round-
   trips between the peer and the home EAP server may be involved.  The
   resulting delay will result in degradation or loss of any service
   session in progress 
   [Qin]: I think the loss of any service only happens in the worse case.
   So I suggest here we can say 
   "
   The resulting delay will result in degradation or even loss of any ongoing 
   service session in the worse case.  
   "
   [RFC5169] describes this problem more fully and establishes design
   goals for solutions to reduce re-authentication delay for transfers
   within a single administrative domain.  [RFC5169] also suggests a
   number of ways to achieve a solution:
   
   [Qin]: I guess "achieve a solution" should be changed as "achieve a goal".

   [RFC5295] tackles the problem of reuse of keying material by
   specifying how to derive a hierarchy of cryptographically independent
   purpose-specific keys from the results of the original EAP
   authentication.  [RFC5296] specifies a method-independent re-
   authentication protocol (ERP) applicable to two specific deployment
   scenarios:
   o  where the peer's home EAP server also performs re-authentication;
      and
   o  where a local re-authentication server exists but is collocated
      with a AAA proxy within the domain.
   One of the objectives of this document is to generalize the HOKEY
   architecture beyond the specific cases dealt with by [RFC5296].
   
   [Qin]: Just for Clarification. I think the objectives of this document is
   not to introduce some new scenarios or use cases but identify  
   What the components of hokey architecture are? what is missing part in the 
   hokey architecture.How they can put together to work? This is what we are doing now
   in this document?

   Both EAP re-authentication and early authentication enable faster
   inter-authenticator handovers.  Early ER is also possible, combining
   the benefits of early authentication with the reduction in signalling
   offered by EAP re-authentication. 

   [Qin]: Early ER means using ERP to perform Early Authentication, not the
   other way around. So I am not sure it is appropriate to say Early ER combine
   the advantage of Early authentication and the advantage of Re-authentication.

In section 6.2.1
   +---------+       +-------------+       +----------+
   |         |       |  Serving    |       |    EAP   |
   |   Peer  +-------|Authenticator|-------|  Server  |
   |         |       |             |       |          |
   +---------+       +-------------+       +----------+
        |                                       | Pulled
          Moves                                 | keying
        |                                       | material
        V                                       V
   +---------+       +-------------+       +----------+
   |         |       |   Target    |  AAA  |   Home   |
   |   Peer  +-------|Authenticator|-------|    ER    |
   |         |       |             |       |  Server  |
   +---------+       +-------------+       +----------+

   Figure 4: EAP Re-authentication With ER Server Located In Home Domain

  [Qin]:I think Local ER Server can be located between Target Authenticator(TAP) and Home ER Server.

   This is a sketch only, put out for comment:
   1.  The peer discovers the existence of candidate authenticator, with
       support for ERP + Early auth, and the local (ERP) domain name of
       that authenticator (how TBD).
   2.  The peer initiates a new ERP exchange (i.e. new sequence number)
       with the acting ER server, with an indication of the new
       candidate authenticator inside (extension to ERP, TBD).  This is
       sent through the serving authenticator, which processes it as
       usual (encaps in AAA, send to ER server).
   3.  The ER server processes the message, and if successful derives a
       new rMSK. *But* it does not include this rMSK in the answer.
   4.  The ERP answer (success) is sent back to the peer through the
       serving authenticator, so that the peer can derive the same rMSK.
   5.  The new rMSK is sent with a different message to the candidate
       authenticator.
   From this point, the Secure Association Protocol may start between
   the peer and the candidate authenticator, should it choose to move
   there.

   [Qin]: Since the Early ERP is used in the intra-domain, the local domain
        name should be home domain name. We can derive the home domain name 
        based on The realm part of NAI. 
   [Qin]: Not sure the peer should support Early Auth. In this case, ERP is extended
       to perform Early Auth. So it is confusing to say the peer with the support for ERP
       + Early auth.
   [Qin]: Which early authentication scenario are you talking about?
   If you talk about Anticipatory Authentication Keying Model, you can refer to
   draft-ietf-hokey-erp-aak, if you talk about pre-authenticatin case, suggest to
   read draft-ietf-pana-preauth-09.