Subject: [HOKEY] Deployment scenario for Hokey Architecture//Re: I-D Action:draft-ietf-hokey-arch-design-00.txt

From: Qin Wu <[email-masked]>
Date: Sat, 16 Oct 2010 11:27:31 +0800

Hi,
It is not clear to me what kind of deployment scearnio we may look at in the draft-ietf-hokey-arch-design-00?
e.g.,  when we discuss ERP, we allow four different use cases:
case 1: Peer -> ER authenticator -> Local ER server
case 2: Peer -> ER authenticator -> home ER server
case 3: Peer -> EAP authenticator/ER authenticator ->Local ER server -> Home EAP server 
case 4: Peer -> ER authenticator -> local ER server -> home ER server 
when we discuss AAK, draft-ietf-hokey-erp-aak extend ERP to support Early authentication. Currently it allows three differnt use cases:
case 5: Peer- > AAK authenticator ->local  AAK ER server
case 6: Peer -> AAK authenticator -> home AAK ER server
case 7: Peer->EAP authenticator/AAK authenticator-> local AAK ER server -> home EAP server

In my opinion,  case 4 may introduce too much complexity to the deplyment and may be not neccessary. 
becos ER authenticator has been allowed to communicate with home ER server directly. 
comparing the case 1,2,3 with case 5,6,7, they have many commonalities and therefore I propose to take them
into account in the hokey architecture draft.

 Commments!

Regards!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, September 10, 2010 11:15 PM
Subject: [HOKEY] I-D Action:draft-ietf-hokey-arch-design-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Handover Keying Working Group of the IETF.
> 
> 
> Title           : Handover Keying (HOKEY) Architecture Design
> Author(s)       : K. Hoeper, et al.
> Filename        : draft-ietf-hokey-arch-design-00.txt
> Pages           : 18
> Date            : 2010-09-09
> 
> 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.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hokey-arch-design-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>

--------------------------------------------------------------------------------

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