Subject: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

From: [email-masked]
Date: Wed, 3 Dec 2008 13:00:02 -0800 (PST)

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           : EAP Pre-authentication Problem Statement
	Author(s)       : Y. Ohba
	Filename        : draft-ietf-hokey-preauth-ps-05.txt
	Pages           : 17
	Date            : 2008-12-03

EAP (Extensible Authentication Protocol) pre-authentication is
defined as the use of EAP to pre-establish EAP keying material on a
target authenticator prior to arrival of the peer at the access
network managed by that authenticator.  This draft discusses EAP pre-
authentication problems in detail.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-05.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

---

From: Qin Wu <[email-masked]>
Date: Wed, 10 Dec 2008 14:56:04 +0800

Hi,Yoshihiro and all:
This draft is well written and Yosihiro does a good job.
May I have some comments on this new revised draft? (i.e., http://www.ietf.org/internet-drafts/draft-ietf-hokey-preauth-ps-05.txt)
All my comments are inline in the attached document marked with [WQ]:

Thanks!
-Qin
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 04, 2008 5:00 AM
Subject: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> implementation to automatically retrieve the ASCII version of the

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 10 Dec 2008 11:38:17 -0500

Hi Qin Wu,

Thanks for the comments.  Just for your information, this draft has
completed 2nd WG last call and chairs are planning to send this draft
to IESG.

Please see my response to your comments.  Please let me know if your
comments are addressed.

Best Regards,
Yoshihiro Ohba

> All my comments are inline in the attached document marked with [WQ]:

(snip)

> 
> 
> 1.  Introduction
> 
>    When a mobile device during an active communication session moves
>    from one access network to another access network and changes its
>    
>    [WQ]:General comment: the movement from one access network to another means inter access network handover, however the movement
>    between different subnets or authenticators belong to the same access network also causes service interruption. Is it necessary to reword it to make clear?

I think the current text is ok because a movement from one access
network to another generally covers inter-subnet or
inter-authenticator movement.

>    
>    point of attachment, it is subjected to disruption in the continuity
>    of service because of the associated handover operation.  The
>    performance requirement of a real-time application will vary based on
>    the type of application and its characteristics such as delay
>    tolerance and loss tolerance limit.  ITU-T G.114 [ITU] recommends 150
>    ms as the upper limit for VoIP applications and 400 ms as generally
>    unacceptable delay.  Similarly, a streaming application has a
>    tolerable packet (SDU) error rates ranging from 0.1 to 0.00001 and
>    the transfer delay of less than 300 ms.  Thus, any optimized handoff
>    mechanism will need to take these factors into consideration in order
>    to be able to support a heterogeneous handover that is agnostic to
>    link-layer technologies.
> 
>    As a mobile device goes through a handover process, it is subjected
>    to delay because of the rebinding of its association at several
>    layers of the protocol stack.  Delays incurred within each of these
>    
>    [WQ]:It is not clear from the above paragraph whether rebinding of its association means location in layer3 correlates with identifier in other layers?
>    in IP mobility scenario, home address can be viewed as identifier and care of address as location,these two address are both placed in layer 3.
>    If rebinding of its association does not mean binding between location and identifier, it is better to make it clear?

This is general text so it includes rebinding of its association
between location and identifier.

>    
>    layers affect the ongoing multimedia application and data traffic
>    within the client [WCM].
> 
>    Handover often requires authentication and authorization for
>    acquisition or modification of resources assigned to a mobile device
>    and the authentication and authorization needs interaction with a
>    central authority in a domain in most cases.  In some cases the
>    central authority may be placed far away from the mobile device.  The
>    delay introduced due to such an authentication and authorization
>    procedure adds to the handover latency and consequently affects
>    ongoing application sessions [MQ7].  We focus our discussion
>    highlighting the factors that affect the performance due to network
>    access authentication and authorization where EAP [RFC3748] is used
>    for network access authentication.
> 
>    This draft discusses EAP pre-authentication problems in detail where
>    EAP pre-authentication is defined as the utilization of EAP to pre-
>    establish EAP keying material on an EAP authenticator prior to
>    arrival of the mobile device that acts as an EAP peer, at the access
>    network served by that authenticator.
>   
>    [WQ]: It is not clear from the above paragrah whether pre-authentication is used in intra-authenticator scenario or inter-authenticator scenario?
>    From my understanding, preauthentication mechanism is only applicable to inter-authenticator scenario. So it is better to point out which authenticator is used here,target authenticator or serving authenticator?

Yes, pre-authentication is used only for inter-authenticator
movements.  Note that Section 1 including the above paragraph is
carefully written to avoid use of "target authenticator" and "serving
authenticator" because they are defined in Section 2.

(snip)

> 
> 3.  Problem Statement
> 
>    The basic mechanism of handover is a three-step procedure involving
>    i) discovery of candidate network points of attachment and their
>    authenticators, ii) network selection procedure to determine the
>    appropriate candidate network point of attachment and iii) handover
>    or setting up L2 and L3 connectivity to the target network point of
>    attachment.  Currently, as part of the third step, network access
>    authentication and authorization are performed directly with the
>    target network.  For example, in IEEE 802.11 wireless LANs [802.11],
>    
>    [WQ]:It is not clear from the above paragraph how the mobile device attaches to target network for the normal authentication? directly? or through serving network?
>    If my understanding is corret, during the authentication process in IEEE 802.11 wireless LANs, the mobile device has
>    already moved from the serving network to the target network.

The normal authentication goes directly with the target network.
Isn't this clear from the 2nd sentence of the above paragraph?

>     Also in some case when the mobile device moves between different subnets belong to the same network, network access authentication also happen and the target network and serving network is the same network.

It depends on what "the same network" means.  If it means the same
"access network", then pre-authentication does not deal with the case
of changing subnets without changing the access network.  If it means
the same "core network", pre-authentication deals with the case of
changing subnets without changing the core network but changing the
access network.

(snip)

> 
>    Optimized solutions for secure inter-authenticator handovers can be
>    largely seen as security context transfer: ERP [RFC5296] or EAP pre-
>    authentication.  
>    
>    [WQ]: It is neccessary to distinguish between ERP and EAP pre-authentication somewhere,
>    Actually there are two difference point:
>    1. ERP is not only applicable to the inter-authenticator scenario, but also applicable to the intra-authenticator,e.g.,
>    when key materials between the peer and AAA server are expired, Re-authentication can be performed again to renew the lifetime of those key materials.

This case is re-authentication without changing the serving
authenticator, and this is different from intra-authenticator
movement.  The draft considers inter-authenticator movement only.
Therefore, I don't think we should mention use of ERP for pure
re-authentication without movement in this draft.

>    2. In ERP scenario, the mobile device has already moved to the target authenticator while in Pre-authentication scenario,
>    the mobile device has not left the serving authenticator.

Yes, and this is described in the draft.

>    
>    Security context transfer involves transfer of
>    reusable key context to the new point of attachment.  However, the
>    recent AAA key management requirements [RFC4962] do not recommend
>    horizontal context transfer of reusable key context because of the
>    domino effect in which the compromise of an authenticator will lead
>    to the compromise of another authenticator.  ERP uses existing EAP
>    keying material for deriving a re-authentication key to be
>    distributed to an ERP server in a visited domain in order to reduce
>    the handover delay, which eliminates the need for running full EAP
>    authentication with the EAP server in the home domain for intra-
>    domain handovers. 
>    
>    [WQ]: Using ERP server in the a visited domain to distribute key materials actually is a local key management approach.
>    This mechanism also can be used for pre-authentication depending on the scenario we considered.

Yes, that is possible, but it does not seem to affect the above
sentence, right?

>    
>     On the other hand, there are certain cases where
>    ERP is not applicable or an additional optimization mechanism is
>    needed to establish a key for the candidate authenticator:
>    
>    [WQ]: I don't think pre-authentication is invented to solve what ERP can not solve. The key difference between ERP and Pre-authentication
>        is the current location of the mobile device. For ERP, the mobile device has already moved from serving authenticator and attached to the target authenticator.
>        For Pre authentication, the mobile device still stays in the serving authenticator.
>        So ERP and pre-authentication are two different ways to improve handover latency performance. 

Actually that makes a difference.  Authentication signaling including
ERP all the way to AAA server after the movement can affect session
continuity if AAA server is physicaly located far from the target
authenticator, and inter-domain handover is such a case.

>        
>    o  One case is an inter-domain handover with or without any trust
>       relationship between the home and visited AAA domains.  If there
>    
>    [WQ]: Is it true that pre-authentication can be applicable to the use case where there are no trust relationship between the visited domain and the home domain
>       do you assume there are absolutely trust relationship between two AAA domains for pre-authentication mechanism. why we should make such assumption? It seems not
>       logical to describe this case?

It is true that pre-authentication is applicable when there is no
trust relationship between the visited domain and the home domain.
However, in this case, different authentication credentials may be
used for the two AAA domains as described in the explanatory text for
Figure 1.

> 
>       is no trust relationship between the two AAA domains, ERP cannot
>       be used in the visited AAA domain, and the EAP server in the home
>       AAA domain is the only entity that can authenticate the peer.
>       Even if there is a trust relationship between the two AAA domains
>       and the visited AAA domain supports ERP, full EAP authentication
>       with the EAP server in the home AAA domain is still needed when
>       entering the visited AAA domain unless the security policy of the
>       home AAA domain allows the same re-authentication root key to be
>       shared with the visited AAA domain.
> 
>    o  Another case is an intra-domain, inter-authenticator handover
>       where the target authenticator or AAA domain do not support ERP,
>       
>     [WQ]:Also I can say where AAA domain does not support Pre-authentication, we can choose ERP.It also seems not logical here?

Yes, you can choose ERP if AAA domain does not support
pre-authentication, but if ERP needs to be performed proactively
before the peer arrives at the target authenticator, then seamless
handover may not be achieved.  So I think the bullet is logical.

>     
>       or ERP needs to be performed proactively before the peer arrives
>       at the target authenticator.
> 
> 

(snip)

> 
> 4.  Usage Scenarios
> 
>    There are two scenarios for how EAP pre-authentication signaling can
>    happen among a peer, serving authenticator, candidate authenticator
>    and AAA server, depending on how the serving authenticator is
>    involved in the EAP pre-authentication signaling.
>    
>    [WQ]: It seems two scenarios are not enough to describe pre authentication mechanism.  
>    e.g.,if AAA server can discover the candidate authenticator's IP address, it can pre-
>    establish EAP keying material on that authenticator beforehand.So it is reasonable to reconsider the existing two usage scenarios?

The two usage scenarios does not mention which entity is responsbile
for discoverying candidate authenticators, and cover the scenario
where AAA server discovers the candidate authenticator's IP address.

>    
>    It is assumed that 
>    in both scenarios there is no direct L2 connectivity between a peer
>    and a candidate authenticator. 
>    
>    [WQ]: So dual radio case is not considered here. Do you imply preauthentication is not applicable to dual radio case, so does ERP?

It's considered.  Even in dual-radio case, there may be no direct L2
connectivity between a peer and a candidate authenticator if the
target radio is turned off or in a dormant mode.

>    
>     No security association between the
>    serving authenticator and the candidate authenticator is required for
>    either pre-authentication scenario (see Section 7 for more detailed
>    discussion).
>    
>    [WQ]: Is it true there are no security association between two adjacent authenticators? Since they are both network side equipments,
>    pre establishment of security association is not difficult thing.

Yes, it is true.  No security association is required between two
adjacent authenticators for pre-authentication to work, regardless of
whether having such a SA is difficult or easy.

(snip)

> 
> 
>          Peer                    Serving                   Candidate
>                               Authenticator             Authenticator
>                                   (SA)                       (CA)
> 
>      +-----------+                                       +-----------+
>      |           |<- - - - - - - - - - - - - - - - - - ->|           |
>      | EAP Peer  |    +-----------------------------+    | EAP Auth- |
>      |           |    |Pre-authentication Forwarding|    | enticator |
>      +-----------+    +-----------+-----+-----------+    +-----------+
>      | Peer-SA   |    | Peer-SA   |     | SA-CA     |    | SA-CA     |
>      | Signaling |<-->| Signaling |     | Signaling |<-->| Signaling |
>      | Layer     |    | Layer     |     | Layer     |    | Layer     |
>      +-----------+    +-----------+     +-----------+    +-----------+
> 
>            Figure 4: Indirect Pre-authentication Layering Model
>     
>     [WQ]It is better to describe direct pre-authentication layering model for consistence in section 4.1. Also
>     is there any other scenario we have not considered?

Pre-authentication layering model for direct pre-authentication is
same as normal EAP layering model, so I don't think we need to
describe the model.  Also, I don't think there are any other scenarios
we have not considered.

> 
> 
> 5.  Architectural Considerations
> 
>    There are two architectural issues relating to pre-authentication:
>    authenticator discovery and context binding.
> 
> 5.1.  Authenticator Discovery
> 
>    In general, pre-authentication requires an address of a candidate
>    authenticator to be discovered either by a peer or by a serving
>    authenticator prior to handover.  An authenticator discovery protocol
>    
>    [WQ]: Is it the scope of hokey working group to define authenticator protocol?
>    if not, where?

This draft does not address who should solve the problem.

>    
>    is typically defined as a separate protocol from a pre-authentication
>    protocol.  For both intra-domain and inter-domain handover, the IP
>    address of a candidate authenticator must be reachable by the peer or
>    the serving authenticator that is performing the pre-authentication.
>    For example, IEEE 802.21 Information Service (IS) [802.21] provides a
>    link layer independent mechanism for obtaining neighboring network
>    information by defining a set of Information Elements (IEs), where
>    one of the IEs is defined to contain an IP address of a point of
>    attachment.  IEEE 802.21 IS queries for such an IE may be used as a
>    method for authenticator discovery.
> 
>    If IEEE 802.21 IS or a similar mechanism is used, an authenticator
>    discovery requires a database on the neighboring network information.
>    Provisioning of a server with such a database is another issue.
> 
> 5.2.  Context Binding
> 
>    When a candidate authenticator uses different EAP transport protocols
>    for normal authentication and pre-authentication, a mechanism is
>    needed to bind link layer independent context carried over pre-
>    authentication signaling to the link layer specific context of the
>    link to be established between the peer and the candidate
>    authenticator. 
>    
>    [WQ]: Do you mean authenticator will store this context binding information in the local database? where?why? Is it necessary?
>    From my understanding, authenticator just acts as pass through role and translates EAP message into AAA message. 

Context binding information needs to be stored in target
authenticator, and it's needed because pre-authentication is performed
through the serving access network instead of directly going through
the target access network.  For example, without context binding, the
target authenticator may not even know what the peer's identity that
will be used for secure assication after the movement to the target
access network is.

>    
>     The link layer independent context includes the
>    identities of the peer and authenticator as well as the MSK.  The
>    link layer specific context includes link layer addresses of the peer
>    and the candidate authenticator.  Such context binding can happen
>    before or after the peer changes its point of attachment.
> 
>    There are at least two possible approaches to address the context
>    binding issue.  The first approach is based on communicating the link
>    layer context as opaque data via pre-authentication signaling.  The
>    second approach is based on running EAP over the link layer of the
>    candidate authenticator after the peer arrives at the authenticator
>    using short-term credentials generated via pre-authentication.  In
>    
>    [WQ]: It is not clear from the above paragraph how context binding is performed after the peer moved to the target authenticator?
>    Can you clarify this?

I think that describing the two approaches in detail is entering the
solution space.  I would like to leave the details for solution
developers.

>    
>    this case, the short-term credentials are shared between the peer and
>    the candidate authenticator, where the candidate authenticator is
>    
>    [WQ]: It is not clear that how to generate the short term credentials?

Again it is entering the solution space.

>    
>    also the EAP server for the EAP method execution performed after the
>    peer arrives at the target authenticator resides in the
>    authenticator.  In both approaches, context binding needs to be
>    securely made between the peer and the candidate authenticator.
>    
>    Also, the peer is not fully authorized by the candidate authenticator
>    until the peer completes the link layer specific secure association
>    procedure with the authenticator using the link layer signaling.
> 
> 
> 6.  AAA Issues
> 
>    Most of the AAA documents today do not distinguish between a normal
>    authentication and a pre-authentication and this creates a set of
>    open issues:
>    
>    [WQ]:Is it necssary to distinguish re-authentication and pre-authentication here too?

I don't think so.  A re-authentication is part of a normal
authentication, with an already existing authorization state.

> 
>    Pre-authentication authorization:   Many users may not be allowed to
>       have more than one logon session at the time.  This means that
>       when such users actively engage in an active session (as a result
>       of a previously valid authentication), they will not be able to
>       perform pre-authentication.  The AAA server currently has no way
>       of distinguishing between a normal authentication request and a
>       pre-authentication request.
> 
>    Pre-authentication lifetime:   Currently AAA protocols define
>       attributes carrying lifetime information for a normal
>       authentication session.  Even when a user profile and the AAA
>       server supports pre-authentication, the lifetime for a pre-
>       authentication session is typically valid only for a short amount
>       of time because the peer has not completed its authentication at
>       the target link layer.  It is currently not possible for a AAA
>       server to indicate to the AAA client or a peer the lifetime of the
>       pre-authenticated session unless AAA protocols are extended to
>       carry pre-authentication session lifetime information.  In other
>       words, it is not clear to the peer or the authenticator when the
>       pre-authentication session will expire.
> 
>    Pre-authentication retries:   It is typically expected that shortly
>       following the pre-authentication process, the peer moves to the
>       new point of attachment and converts the pre-authentication state
>       to a normal authentication state (the procedure for which is not
>       the topic of this particular subsection).  However, if the peer
>       has not yet moved to the new location and realizes that the pre-
>       authentication is expiring, it may perform another pre-
>       authentication.  Some limiting mechanism is needed to avoid
>       unlimited number of pre-authentication tries.
> 
>    Completion of network attachment:   Once the peer has successfully
>       attached to the new point of attachment, it needs to convert its
>       authentication state from pre-authenticated to fully attached and
>       authorized.  There may need to be a mechanism within the AAA
>       protocol to provide this indication to the AAA server if the AAA
>       server needs to differentiate between pre-authentication and
>       normal authentication.  This is important from billing perspective
>       where the billing policy does not charge for a pre-authenticated
>       peer until the peer is fully attached to the target authenticator.
>       
>   [WQ]: Do you mean after pre-authention procedure, the peer can choose not to attach to the target authenticator, is it true?

Yes, the peer can choose not to attach to the target authenticator.
In fact it can happen when handover operation is withdrawn for
whatever reasons.

>   
>    Session Resumption:   In case the peer cycles between a network N1
>       with which it has a normal authentication state to another network
>       N2 and then back to N1, it should be possible to simply convert
>       the full authentication state to a pre-authenticated state.  The
>       problems around handling session lifetime and keying material
>       caching need to be dealt with.
> 
>    Multiple candidate authenticators:   There may be situations where
>       the peer may need to make a selection between a number of
>       candidate authenticators.  In such cases, it is desirable for the
>       peer to perform pre-authentication with multiple candidate
>       authenticators.  In such cases the AAA server may need to be aware
>       of the situation.
> 
>    Inter-technology support:   Current specifications on pre-
>       authentication mostly deal with homogeneous 802.11 networks.  The
>       AAA attributes such as Calling-Station-ID [I-D.aboba-radext-wlan]
>       may need to be expanded to cover other access technologies.
>       Furthermore, inter-technology handovers may require a change of
>       the peer identifier as part of the handover.  Investigation on the
>       best type of identifiers for peers that support multiple access
>       technologies is required.
>       [WQ]:aside from IP address, what else we can choose as the peer identifier?

I think NAI can be a peer identifier, but I don't think we should
mention anything in this document.

> 
> 7.  Security Considerations
> 
>    This section specifically covers threats introduced to the EAP model
>    by pre-authentication.  Security issues on general EAP and handover
>    are described in other documents such as [RFC3748], [RFC4962],
>    [RFC5169] and [RFC5247].
> 
>    Since pre-authentication described in this document needs to work
>    across multiple authenticators, any solution needs to consider the
>    following security threats.
> 
>    First, a resource consumption denial of service attack is possible,
>    where an attacker that is not on the same IP link as the legitimate
>    peer or the candidate authenticator may send unprotected pre-
>    authentication messages to the legitimate peer or the candidate
>    authenticator. As a result, they may spend their computational and
>    bandwidth resources on processing pre-authentication messages sent by
>    the attacker.  This attack is possible for both direct and indirect
>    pre-authentication scenarios.  To mitigate this attack, the candidate
>    network or authenticator may apply non-cryptographic packet filtering
>    so that pre-authentication messages received from only a specific set
>    of serving networks or authenticators are processed.  In addition, a
>    simple solution for the peer side would be to let the peer always
>    initiate EAP pre-authentication and not allow EAP pre-authentication
>    initiation from an authenticator.
> 
>    Second, consideration for the Channel Binding problem described in
>    
>    [WQ]: what's the relationship between channel binding and context binding?

Context binding is binding link layer independent context established
in pre-authentication signaling to the link layer specific context of
the link to be established between the peer and the candidate
authenticator.  Channel binding is binding authenticator's identity as
part of link layer specific context to the EAP keying material.
Having said that context binding and channel binding are orthogonal
types of binding.

>    It seems necessary to add a terminology of channel binding in this document.

I am not sure if we need to add a terminology of channel binding.  Why
the references are not sufficient?

>    
>    [RFC5247] is needed as lack of Channel Binding may enable an
>    authenticator to impersonate another authenticator or communicate
>    incorrect information via out-of-band mechanisms (such as via a AAA
>    or lower layer protocol) [RFC3748].  It should be noted that it is
>    relatively easier to launch such an impersonation attack for pre-
>    authentication than normal authentication because an attacker does
>    not need to be physically on the same link as the legitimate peer to
>    send a pre-authentication trigger to the peer.
> 

(snip)

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Dec 2008 15:19:17 +0800

Hi Yoshihiro:
Thank for your clarification. I have follow up questions to you, please see in line.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 11, 2008 12:38 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> completed 2nd WG last call and chairs are planning to send this draft
[Qin] I have just realized it. Am I welcome here, hope what i say does not disturb the progress.:)
> inter-authenticator movement.
[Qin] It depends how you define one access network. From my view, one access network can be split into couples of subnets. Each subnet 
has one authenticaor. In some case when the mobile device moves within one access network, pre-authentication is also necessary,e.g., the mobile device changes the authenticator/subnet but does not change the access network.. So what I concern is try to make difference between
inter access network handover and inter authenticator handover, what's more, it is also a problem about how to distinguish between inter-domain
handover and inter-access network handover. Since there are no clear scenarios, how to make solution at the next step.
What I suggest is to change like this:
When a mobile device during an active communication session moves within one access network or between access networks 

> between location and identifier.
[Qin] First what i confuse is location and identifier could be placed at the same layer of the protocol stack. But you say rebinding of its association at several layers, it is not exactly what you explain above.
Second besides binding between location and identifier , What else it include? What's the relationship between rebinding of its association and context binding? I am a little lost.:)

> authenticator" because they are defined in Section 2.
[Qin] Great, So it is clear to me.
> Isn't this clear from the 2nd sentence of the above paragraph?
[Qin] You have my point, thanks.
> movement.  
[Qin] But if we allow the mobile device move around within the same authenticator and key materials are expired meanwhile, this is intra-authenticator handover.
>The draft considers inter-authenticator movement only.

[Qin] I agree, what i intend is to clarify the scenario difference between ERP and Pre-authentication.

> Yes, and this is described in the draft.

[Qin] You are right.

> Yes, that is possible, but it does not seem to affect the above

[Qin] right, I am happy with that, it does no harm to the above text.

> authenticator, and inter-domain handover is such a case.

[Qin] What i argue here is I can't agree the purpose of pre-authentication is to fix what ERP can not solve. That's not real reason to convice people why we need pre-authentication. Pre-authentication and ERP is totally different optimized approaches to improve handover latency performance. They are applicable to different usage scenarios wherein the mobile device attaches to the different authenticator. If we only
consider inter-authenticator for ERP and pre-authenticator, the difference between ERP and Pre-authentication is which authenticator the mobile device attaches to. So my point is ERP and Pre-authentication solve totally different scenarios. I can understand the scenario ERP is 
applicable is appropriate for Pre-authentication. That's my concern.

> used for the two AAA domains as described in the explanatory text for

[Qin] I am a little confused. The reason is the case you explains here can not solve what we raise above.
First you have agreed it is one scenario that pre-authentication is applicable when there is no trust relationship between visited and home network. However this scenario is not considered in this draft for some reason. Actually what i understand is whether there is some trust
relationship between visited AAA and home AAA is beyond scope of this document. Normally there are some roaming agreement between them.
But the point is I am surprised to see that there are no key management for pre-authentication. Since derivation, delivery and management of EAP based keys can be used for Re-authentication, why not for pre-authentication?

Second, the authentication credentials used for the two AAA domains, I can not understand whether this authentication credentials are used to 
protect the relationship between the different authenticator and AAA or the relationship between the visited AAA and the home AAA? If it is latter, I think it is out of scope of this document, if it is first case, I think it is certain that each time the mobile device changes the authenticator,
the authentication credentials are definitly to be re-generated. What do you mean here?

> handover may not be achieved.  So I think the bullet is logical.

[Qin] As I said above, I think ERP and Pre-authentication can not solved the same scenario. For inter-authenticator handover, we can choose
ERP, also we can choose Pre-authentication, But we should understand the key difference between ERP and Pre-authentication is that:
For ERP, the mobile device has already moved from the serving authenticator to the target authenticator, The authenticator the mobile device attaches to is target authenticator.
For Pre-authentication, the mobile device is still attached to the serving authenticator and there is no layer 2 link between the mobile device and the target authenticator.
So ERP and Pre-authentication can not solve the same scenario.

> where AAA server discovers the candidate authenticator's IP address.

[Qin] No, you have said in section 5.1 authenticator discovery, the text is described as follows:
   In general, pre-authentication requires an address of a candidate
   authenticator to be discovered either by a peer or by a serving
   authenticator prior to handover.
That is why i raise this issue.

> target radio is turned off or in a dormant mode.

[Qin] No, what you understand is not dual radio case. Dual radio cases means one mobile device attaches to the serving authenticator and the target authenticator simutaneously. Actually in this case we require one mobile device to support at least two access technologies.
It is another ussage scenario you does not consider in this document I think,:)
Inter-technology handover does not mean inter authenticator handover.

> whether having such a SA is difficult or easy.

[Qin] Okay. Forget it.

> describe the model.  Also, I don't think there are any other scenarios

[Qin] Oh, I have not realized that. Is it true whether direct pre-authentication and indirect pre-authentication use the same model?
Is it that we have enumerated all the scenarios? Let me remind you at lease two cases you have not considered. dual radio case mentioned above and the case that allow message exchange between AAA and candidate authenticator.
What's more there are lots of terms define the similar thing but not exactly the same thing. e.g., inter-domain handover, intra-domain handover
inter-authenticator handover, inter-technologies handover, intra-technologies handover. Is it necessary to make it clear here?

> This draft does not address who should solve the problem.

[Qin] Sorry, I just wonder. But it is okay for your answer. Maybe it is the work at the next step of hokey working group?

> will be used for secure assication after the movement to the target

[Qin] I agree. But that is the different thing. What I understand is if the target authenticator want to know whose peer he is talking to, he can
ask the serving authenticator or the peer directly tells the target authenticator, afterthat, is it certain that target authenticator store the peer identifier in its local database?
For another example, I am one authenticator, one peer want to talk with AAA through me, am I storing this peer identifier in my pocket? That is my conern.
Another question is that is there any relationship between context binding and rebinding association mentioned above?

> solution space.  I would like to leave the details for solution

[Qin] I agree. Another concern is whether context binding will cause domino effect since MSK is included in context binding?

> Again it is entering the solution space.

[Qin] I think it is the scope of key management for pre-authentication even though the credentials is short term.
Because what we consider here is candidate authenticator is collocated with EAP server or AAA server. Since AAA
is involved, we definitely require key derivation and delivery mechanism here. I wonder why we don't define one suite of key management for pre-authentication?

> authentication, with an already existing authorization state.
[Qin] I don't think so, re-authentication is not one part of normal authentication. The reason is re-authentication has develop new
EAP message for operation, totally different from EAP signalling in the normal authentication. So normal authentication, pre-authentication,
re-authentication is totally different approaches to perform authentication. 
> In fact it can happen when handover operation is withdrawn for

[Qin] I can not image it, it seems a disaster.

> Having said that context binding and channel binding are orthogonal

[Qin] oh, I am coming to realize it after you explain to me. Thanks for your clarification.

> the references are not sufficient?

[Qin] You are right. I think it is not necessary now,:).

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Dec 2008 18:13:34 +0700

> completed 2nd WG last call and chairs are planning to send this draft

True.  OTOH, since there have been fewer than 10 total reviews of this
document (and no comments at all on the latest version), I think that it
would be a little silly to dismiss more than 10% of the comments made just
to stand on ceremony.  More review is better...

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 11 Dec 2008 17:27:39 -0500

Hi Qin Wu,

Seeing Glen's response, I guess we can revise the draft before it is
sent to IESG, if needed.

Please see my comments below.

> When a mobile device during an active communication session moves within one access network or between access networks 

First, if you want to define an access network to cover multiple
authenticators, then we already have a definition of Access Domain, so
such a defintion of access network is not needed.

Second, the draft intentionally does not describe relationship between
access network and IP subnet to focus on pre-authentication problem
(there was a comment on this), and for this reason the word "subnet"
was removed from the draft.  Note that pre-authentication is generaly
applicable to any relationship between between an access network and
IP subnet(s), and you don't have to worry about it.

> [Qin] First what i confuse is location and identifier could be placed at the same layer of the protocol stack. But you say rebinding of its association at several layers, it is not exactly what you…

What I meant is that a rebinding such an association can happen at
multiple layers that define layer-specific location and identifer.

> Second besides binding between location and identifier , What else it include? What's the relationship between rebinding of its association and context binding? I am a little lost.:)

For example, binding between QoS resource and identifier if the amount
of QoS resource changes depending on location.  Context binding is a
inter-layer binding (binding between pre-authentication signaling
layer and link-layer), so I think it's different.

> applicable is appropriate for Pre-authentication. That's my concern.

I think we are talking about the same thing in different way.

I agree that ERP and pre-authentication are two different approaches.

If the target network supports ERP, then the mobile can always perform
ERP via the target access network once the mobile is in the coverage
of the target access network.  However, such a reactive authentication
may affect session continuity if the connection via the serving access
network is not available during the handover and the AAA server is too
far from the target authenticator (and thus authentication latency is
not negligible).  In this case, pre-authentication is addressing the
issue that is not addressed by ERP, and that is my point.

> [Qin] I am a little confused. The reason is the case you explains here can not solve what we raise above.

Can you explain why can not?

> relationship between visited AAA and home AAA is beyond scope of this document. Normally there are some roaming agreement between them.

The scenario is implicitly considered for direct pre-authentication,
i.e., we have the inter-AAA-domain trust relationship assumption for
indirect pre-authentication scenario only, and there is such
assumption for direct pre-authentication.

> But the point is I am surprised to see that there are no key management for pre-authentication. Since derivation, delivery and management of EAP based keys can be used for Re-authentication, why no…

EAP-based key management is needed for pre-authentication because it
is based on EAP, and pre-authentication must follow RFC 5247.  We can
add explicit text on this requirement in Security Considerations
section.

> the authentication credentials are definitly to be re-generated. What do you mean here?

The authentication credentials are user credentials and not used to
protect the signaling between serving and candidate authenticators nor
the AAA protocol exchanges.

> [Qin] As I said above, I think ERP and Pre-authentication can not solved the same scenario. 
> For inter-authenticator handover, we can choose

Not sure this is correct.  In dual-radio case you explained below, the
mobile maintains the connections to both the serving and target access
networks simultaneously, right?

> That is why i raise this issue.

OK.  Then how about changing the text as follows?

"In general, pre-authentication requires an address of a candidate
authenticator to be discovered by a peer, a serving authenticator or
some other entity prior to handover."

> Inter-technology handover does not mean inter authenticator handover.

If you talk about simultanous use of multiple radios, we have
considered the case in Section 3 as follows:

"
   Also the
   effectiveness of EAP pre-authentication may be less significant for
   particular inter-technology handover scenarios where simultaneous use
   of multiple technologies is not a major concern.
"

> [Qin] Oh, I have not realized that. Is it true whether direct pre-authentication and indirect pre-authentication use the same model?

BTW, I did not say direct pre-authentication and indirect
pre-authentication use the same model.  

I am fine with adding a figure something like below for direct
pre-authentication if you like:

      Peer                                             Candidate
                                                     Authenticator
                                                         (CA)
  +-----------+                                       +-----------+
  |           |<- - - - - - - - - - - - - - - - - - ->|           |
  | EAP Peer  |                                       | EAP Auth- |
  |           |                                       | enticator |
  +-----------+                                       +-----------+
  | Peer-CA   |                                       | SA-CA     |
  | Signaling |<------------------------------------->| Signaling |
  | Layer     |                                       | Layer     |
  +-----------+                                       +-----------+

> Is it that we have enumerated all the scenarios? Let me remind you at lease two cases you have not considered. dual radio case mentioned above and the case that allow message exchange between AAA a…

As I mentioned above, dual radio case is considered in Section 3 (it's
not a much effective scenario for pre-authentication).  Message
exchange between AAA and candidate authenticator is covered in Figures
1 and 2.

> inter-authenticator handover, inter-technologies handover, intra-technologies handover. Is it necessary to make it clear here?

In Section 2, we have definitions for Inter-Access-Domain Handover,
Inter-ESS Handover, Intra-AAA-Domain Handover (Intra-Domain Handover),
Inter-AAA-Domain Handover (Inter-Domain Handover), Intra-Technology
Handover, Inter-Technology Handover Inter-Authenticator Handover.  

Can you please elaborate what is not clear in these defintions?

> [Qin] Sorry, I just wonder. But it is okay for your answer. Maybe it is the work at the next step of hokey working group?

There is a newly approved project (802.21a) under IEEE 802.21 WG
contains pre-authentication solution as one of its work items.

> For another example, I am one authenticator, one peer want to talk with AAA through me, am I storing this peer identifier in my pocket? That is my conern.

Yes, it is natural that the entity who is authenticating the peer
stores the identity of the peer.  Note that the identity does not have
to be a permanent identity.

> [Qin] I agree. Another concern is whether context binding will cause domino effect since MSK is included in context binding?

Domino effect does not happen since MSK sharing among mulitple
authenticators is prohibited in RFC 5247.

> is involved, we definitely require key derivation and delivery mechanism here. I wonder why we don't define one suite of key management for pre-authentication?

I agree that key management for pre-authentication is needed, but
difinition of actual key delivation and delivery mechanisms belong to
solution space, and this draft is not an appropriate place to define a
solution.

> re-authentication is totally different approaches to perform authentication. 

If you mean ERP by re-authentication, I agree that ERP is different
from normal authentication and pre-authentication in terms of EAP/AAA
signaling.  If they are different enough, we can differenticate
between ERP and pre-authentication, and there may be no special issue
here.

> [Qin] I can not image it, it seems a disaster.

This can just happen especially over unlicensed frequency band, e.g.,
strong interference can suddenly start over the target radio.

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Fri, 12 Dec 2008 15:01:50 +0800

Thanks for your reponse, I have follow up question to you. Please see in line.
Best regards.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 12, 2008 6:27 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> Seeing Glen's response, I guess we can revise the draft before it is
[Qin] I will be happy with that if this draft can be revised to cover all the necessary requirements and scenarios. 
Also I do think there are lots of work unsolved,e g., key mangement for pre-authentication, pre-authentication solution,
inter-technologies handover security, etc, in the future.
> such a defintion of access network is not needed.

[Qin]Oh, I nearly forgot it. However I can not agree this definition of access domain, the reason is that this definition adds too many restrictions,e.g., not change serving authenticator, therefore it can not cover all the useful usage scenarios. Actually the access network
mentioned in this defintion is exactly one subnet. If we make choice between them, I would rather revise the access network into subnet.
The reason is one access network has larger coverage than one subnet, so it is reasonable to have at least one authenticator in one access network, I can not image multiple visited access networks can share the same authenticator??????? 

> IP subnet(s), and you don't have to worry about it.

[Qin]Actually I really worry about the definition of one access domain. It misleads our carriers to apply one authenticator to manage a set of access netwoks. I would rather remove access network instead of subnet. 
What's more, I am realizing  intra-AAA-Domain handover, inter-AAA-Domain handover  are not appropriate used here. Let me give you an example, intra-AAA-domain handover can be further divided into intra-authenticator  and inter-authenticator handover, inter-AAA-domain is very similar to inter-authenticator handover, but not exactly the same thing. Why there are no extra scenario address the part in the inter-AAA domain handover different from inter-authenticator handover?

> multiple layers that define layer-specific location and identifer.
[Qin] What I understand is sometimes we need to setup binding at the same layers, e.g., binding of layer3 location and layer 3 identifier.
Sometimes we need to setup binding across different layers, e.g., binding of layer 2 identifier and layer3 location. if you think the rebinding of 
its association at several layers specified in the draft can cover all the cases, it will be okay for me, :).

> layer and link-layer), so I think it's different.

[Qin] What I concern is maybe context binding is one part of rebinding of its association. Rebinding indicates the mobile device moves around, context binding also indicates the mobile device moves around. It is true they are different, but they are relevant in some way.
Anyway if we want to distinguish between them, that's okay. But from the readers of perspective, they maybe ask the same question as me.:)

> I think we are talking about the same thing in different way.

[Qin]:Sorry, there is a typo in my comment mentioned above. My point is the scenario ERP is applicable is not appropriate for Pre-authentication. Yeah, we say the same thing, but what you said here distort what it is exactly somewhere.

> issue that is not addressed by ERP, and that is my point.
[Qin] It is true about what you said on ERP. What i argue here is they can not solve the same scenario. The reason is 
in the scenario for ERP, the mobile device has already moved to the new target network
in the scenario for Pre-authentication, the mobile device is still attached to the previous serving network.
That's my concern.
> Can you explain why can not?
[Qin] See below!
> assumption for direct pre-authentication.
[Qin] I am confused here.
First if the peer moves to the vistited network A from the home network and there are no trust relationship between the vistited AAA in the visited network A and the home AAA in the home network, I can not image how authentication between the peer and the home AAA is performed directly without visited AAA acting as proxy AAA functionality, In another words, if there are no roaming agreement between the visited AAA and the home AAA, inter-domain authentication will not happen.
Second, I can not establish the mapping between inter-domain handover and indirect pre-authentication or between intra-domain handover and direct pre-authentication? There are no clear relationship between them. Before that, I thought direct pre-authenction and indirect pre-authentication are both focused on intra-domain handover, am I wrong? 

So I suggest to further divide intra-AAA domain handover and inter-AAA domain handover into couples of usage scenarios  to enhance the section 4. It is not enough there to address all the possible and useful scenarios.

> add explicit text on this requirement in Security Considerations

[Qin] That will be better, what I concern here is since we have RFC5247, why we need to develop key management for ERP, i.e.,draft-ietf-hokey-key-mgm-04, the reason is draft-ietf-hokey-key-mgm-04 is specified for Re-authentication, Since that, why not develp key management for pre-authentication,  Before that, I think we need to identify more difference between re-authentication and pre-authentication. That's my suggestion.

> the AAA protocol exchanges.

[Qin]Sorry for my misunderstanding. However I am confused again. 
Normally the user credential is shared between the peer/user and the home AAA, although the peer changes visited AAA, the user credential
will not change. User credentials is relevant to roaming agreement I think. So you explaination does not happen actually.

> networks simultaneously, right?

[Qin]I think dual radio case is one special case for pre-authentication and re-authentication, actually this case has not been considered in the
draft, if my understanding is correct.

> some other entity prior to handover."
[Qin] It will be better.
>   of multiple technologies is not a major concern.
[Qin] oh, I realize it. From my understanding, dual radio case is one specific case for pre-authentication or ERP.

> pre-authentication if you like:
[Qin] That will be fine with me. However another issue needs to be raised here. 
I found the common thing for direct pre-authentication and indirect pre-authentication is that
signalling exchange beteen the peer and AAA/EAP server are both through candidate authenticator. Is that true?
why not through the serving authenticator　ｔｏ　ｐｅｒｆｏｒｍ　ｐｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ？
Also the case when the peer moves from one visited AAA server to another is not considered here, i.e. inter AAA domain handover case
is missed here.
>                                                         (CA)

[Qin] How about the case when message exchange between AAA and the serving authenticator? And why not describe dual radio case in the section 4?

> Can you please elaborate what is not clear in these defintions?

[Qin] Although we have defined so many terms here, how many of them are used to sort the pre-authentication usage scenarios?
Some of useful scenarios are neglected here.
most of them are only simply mentioned in the section of terminology.
Also I have to point out one mistake in the defintion of inter-authenticator handover, it describes as follows:
   Inter-Authenticator Handover
      A handover across multiple authenticators.  An inter-authenticator
      handover includes an inter-access-domain handover, an inter-ESS
      handover, an inter-AAA-domain handover, an inter-technology
      handover, and any possible combination of them.
If my understanding is correct, inter-technolgy handover is one kind of inter-authenticator handover, but you can not say inter-authenticator handover  is one kind of inter-technology handover. The reason in the inter-authenticator scenario, two adjacent authenticators may support the same access technology. Also i don't agree inter-authenticator handover includes inter-access domain handover, one access domain can contain serverals authenticators. But the definition of access domain handover totally misleads us to the wrong direction.

> contains pre-authentication solution as one of its work items.

[Qin]: Thank for your reminding, that will be okay.

> to be a permanent identity.
So your conlusion is authenticator will record the peer information if the peer pass through him? okay, I am sure about it.
But it is okay for me.
> authenticators is prohibited in RFC 5247.
[Qin]But In indirect pre-authentication case, the context binding information the peer send to the target authenticator is through serving
authenticator, it means context binding information will be relayed by sering authenticator to the target authenticator, thus, domino effect
will happen, is it true?

> solution space, and this draft is not an appropriate place to define a

[Qin] I have been aware of the status of hokey working group. So we'd better leave the this work to soution space.

[Qin] You are right.

> strong interference can suddenly start over the target radio.
[Qin] So you mean it will never happen in 3GPP, WiMAX access network. I wonder whether movement over unlicensed frequecy band can be view as handover or normadicity? Do you have any experiment data demonstrate this case?:)

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 12 Dec 2008 16:48:42 -0500

Hi Qin,

I am glad to see the size of email is reducing :)

On Fri, Dec 12, 2008 at 03:01:50PM +0800, Qin Wu wrote:
(snip)
> mentioned in this defintion is exactly one subnet. If we make choice between them, I would rather revise the access network into subnet.

There is misunderstanding here.  The defition of access domain is not
tied to any specific mapping between access network and subnet, and
it's not correct to mention that the access network is exactly one
subnet.

> The reason is one access network has larger coverage than one subnet, so it is reasonable to have at least one authenticator in one access network, I can not image multiple visited access networks…

I agree that access network may have larger coverage than one subnet
(in fact the draft does not say anything about mapping between access
network and subnet).  OTOH, I would like to clarify that whether an
authenticator serves only one access network or multiple access
networks is independent of the relationship between access network and
subnet.

> [Qin]Actually I really worry about the definition of one access domain. It misleads our carriers to apply one authenticator to manage a set of access netwoks. I would rather remove access network i…

I think there is some misunderstanding here.  The current definition
of access domain does not say there is only one authenticator in the
access domain.  The definition just says that a peer is allowed to
change its network points of attachment without changing its serving
authenticator.  Actually there can be multiple authenticators in the
access domain and the MN may use just one of them as its serving
authenticator.

> What's more, I am realizing  intra-AAA-Domain handover, inter-AAA-Domain handover  are not appropriate used here. Let me give you an example, intra-AAA-domain handover can be further divided into i…

Inter-AAA-domain handover is covered in Figure 1:

"
   Figure 1 shows the functional elements that are related to EAP pre-
   authentication.  These functional elements include a peer, a serving
   authenticator, a candidate authenticator and an AAA/EAP server or
   AAA/EAP servers.  When the serving and candidate authenticators
   belong to different AAA domains, the candidate authenticator may use
   a different AAA server and user credentials than those were used by
   the serving authenticator to authenticate the peer.
"

We also describe the relationship between inter-authenticator handover
and inter-AAA-domain handover (and other types of handovers):

"

> its association at several layers specified in the draft can cover all the cases, it will be okay for me, :).

OK, how about revising the sentence to cover both intra-layer and
inter-layer bindings as follows?

"
   As a mobile device goes through a handover process, it is subjected
   to delay because of the rebinding of its association at or across
   several layers of the protocol stack.
"

(This text covers context binding.)

> in the scenario for Pre-authentication, the mobile device is still attached to the previous serving network.

As I mentioned your description of the ERP scenario stating that the
mobile device has already moved to the new target network is not
correct.  In the case of simultaneous use of multiple radios, it is
possible for the mobile to run ERP with the target network while it is
still using the serving network for its application sessions (i.e.,
the mobile has not already moved to the target network).

> First if the peer moves to the vistited network A from the home network and there are no trust relationship between the vistited AAA in the visited network A and the home AAA in the home network, I…

In the case of direct pre-authentication, it is assumed that there is
L3 connectivity between the peer in the serving network and the CA in
the candidate network.  All that is needed for direct
pre-authentication to work is passing IP packets between the domains
to realize Peer-CA signaling.  This does not require trust
relationship between the domains, and this is essentially same as
Mobile IP HA in home domain can communicate with its MN in any visited
domain.  Of course, in a deployment where such an assumption does not
hold, pre-authentication will not work.

> Second, I can not establish the mapping between inter-domain handover and indirect pre-authentication or between intra-domain handover and direct pre-authentication? There are no clear relationship…

Both direct and indirect pre-auth can work with both inter-domain and
intra-domain handover (and indirect pre-auth requires trust
relationship between domains as described in Section 4.2).

> [Qin] oh, I realize it. From my understanding, dual radio case is one specific case for pre-authentication or ERP.

Right.  The text means that if simultaneous use of multiple
technologies is a major concern, pre-authentication can be effective.

> signalling exchange beteen the peer and AAA/EAP server are both through candidate authenticator. Is that true?

Yes.

> why not through the serving authenticator　ｔｏ　ｐｅｒｆｏｒｍ　ｐｒｅ−ａｕｔｈｅｎｔｉｃａｔｉｏｎ？

This is because EAP is designed to run between the owners (peer and
authenticator) of a link to which EAP keying material is installed,
and the serving authenticator is not an owner of the target link.  So
making the serving authenticator a AAA signaling gateway for
pre-authentication does not fit EAP model.

> Also the case when the peer moves from one visited AAA server to another is not considered here, i.e. inter AAA domain handover case

It's considered in text for Figure 1:

   "When the serving and candidate authenticators
   belong to different AAA domains, the candidate authenticator may use
   a different AAA server and user credentials than those were used by
   the serving authenticator to authenticate the peer."

> If my understanding is correct, inter-technolgy handover is one kind of inter-authenticator handover, but you can not say inter-authenticator handover  is one kind of inter-technology handover. 
>The reason in the inter-authenticator scenario, two adjacent authenticators may support the same access technology. 

The above defition does not say that inter-authenticator handover is
one kind of inter-technology handover.  It's the other way around.

> Also i don't agree inter-authenticator handover includes inter-access domain handover, one access domain can contain serverals authenticators. But the definition of access domain handover totally misleads us to the wrong direction.

As I mentioned above, one access domain can contain multiple
authenticators.

> authenticator, it means context binding information will be relayed by sering authenticator to the target authenticator, thus, domino effect

With the following requirement in Section 5.2 , domino effect for
context binding will not happen:

  "In both approaches, context binding needs to be securely made
  between the peer and the candidate authenticator."
 
> [Qin] So you mean it will never happen in 3GPP, WiMAX access network. I wonder whether movement over unlicensed frequecy band can be view as handover or normadicity? Do you have any experiment data…

I did not say it will never happen in licensed frequency band.  I have
a lot of experiences of dropping phone calls when driving car and
riding on a train, with entering bad radio coverage, e.g., tunnels.

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Mon, 15 Dec 2008 11:39:05 +0800

Thank for your response, I have follow up question to you, please see inline!
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, December 13, 2008 5:48 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> I am glad to see the size of email is reducing :)
[Qin] That's a good news. 
> it's not correct to mention that the access network is exactly one
[Qin] However the defintion of access domain is totally wrong, what I suggest here is to try to help you fix this mistake. In this definition, it said:
   Access Domain
      A set of access networks of a specific link layer technology among
      which a peer is allowed to change its network points of attachment
      without changing its serving authenticator.  An IEEE 802.11r
      mobility domain [802.11r] is an access domain.
it means a set of access networks share the same authenticator, however it is not true. The reason is there is at least one authenticator in each access network. When a peer moves from one access network to another, it is certain to change authenticator. I can't image a set of access network shares the same authenticator, it is not one general scenario we expect in this defintion. So this definition is totally wrong. 
The only way to put it right is to change a set of  access networks in this definition to a set of subnets. 
If you insist on keeping no change, I will suggest to delete it from the WG draft, because there are no place to refer this defintion actually.
> networks is independent of the relationship between access network and
[Qin] True. However whether an authenticator serves one access network or multiple access networks is a pragamatic problem in this draft.
actually the scenario that only on authenticator serves multiple access network is seldom adopted in practice. e.g., a peer moves from 3GPP
access network to WiMAX access network, two access networks has its own authenticator, In WiMAX access network, ASN-GW will act as authenticator while in 3GPP access network, S-GW will be viewed as authenticator, So the conclusion is normally two access networks do not share the same authenticator. If pre-authentication draft focus on some scenarios that are seldom used, it seems this draft does something meaningless.  
> access domain and the MN may use just one of them as its serving
[Qin] I don't think so. I have no objection that  MN uses one of authenticator to be its serving authenticator. However in the definition of access domain, it is not one access network but a set of access networks to share this authenticator, it seldom happens to make multiple access networks to share the same authenticator in real application and deployment. 
So there are two ways to put it right, one way is to change a set of access network into one access network, the second way is to change a set of access network into a set of subnets within one access network. 

>   the serving authenticator to authenticate the peer.
[Qin] The figure is probably okay except some texts describing this figure
There are one place that needs to be reconsidered and modified:
It said:
 When the serving and candidate authenticators belong to different AAA domains, the candidate authenticator may use
  a different AAA server and user credentials than those were used by the serving authenticator to authenticate the peer.
---------------------------------------------------------------------------------------------------------
I agree in this situation, the different authenticator may use the different AAA server for authentication, But the user credentials may keep the same, e.g.,a mobile node share the user credentials with its home AAA servers in the home network, when this mobile node moves 
between two visited access network, although the mobile node changes visited AAA servers, but the user credentials does not change.
So my suggestion is to remove user credentials from the above specification.

>      handover, and any possible combination of them.
[Qin] It is not enough to describe the relationship between them. The more important thing is to specify these useful scenarios in section 4.
Actually when I read the two scenarios you specify in section 4, I thought you just describe some intra-AAA domain handover. The reason is
there are only one AAA/EAP server in these two scenarios, So it is better to add more scenarios and separate AAA/EAP server into the serving AAA and the target AAA someting like that. In this way, people will understand you have already considered all the cases.
The other thing in your two scenarios is why only candidate authenticator can communicate with AAA/EAP server, why not the serving authenticator communicate with AAA/EAP server during the pre-authentication? If possible, I hope this case can be reflected in your two scenarios.

> (This text covers context binding.)
[Qin] It will be better. Thanks!
> the mobile has not already moved to the target network).
[Qin] I agree dual radio case can be applicable to ERP scenarios. But dual radio case is only a special case, not general case. 
the reason is you can view dual radio case as ERP case, also you can view dual radio case as pre-authentication case. So my suggestion is to
distinguish dual radio case with your two scenarios in section 4. Before we talk about dual radio case, I thought the direct pre-authentication case and indirect pre-authentication case are both single radio case. If you have no objection, I suggestion to restructure the section 4 as follows:
4 Usage Scenarios
 4.1 Dual radio case
 4.2 Single radio case
  4.2.1Intra-AAA domain handover case
    4.2.1.1 Direct pre-authentication case
    4.2.1.2  Indirect pre-authentication case
  4.2.2 Inter-AAA domain handover case
or we don't concentrate on dual radio case in section 4, it is just a special case for both re-authentication and pre-authentication.
>> First if the peer moves to the vistited network A from the home network and there are no trust relationship between the vistited AAA in the >>visited network A and the home AAA in the home network, I can not image how authentication between the peer and the home AAA is >>performed directly without visited AAA acting as proxy AAA functionality, In another words, if there are no roaming agreement between the >>visited AAA and the home AAA, inter-domain authentication will not happen.
> 
[Qin] It is the different case, I can understand in direct pre-authentication, we need to setup trust relationship between the peer and the CA.
However in the inter-domain authentication,i.e. inter-AAA-domain authentication, maybe we don't need trust relationship between the visited AAA server in the previous visited access network and the visited AAA server in the new visited access network, but we definitely need the trust relationship between visited and home. Otherwise, handover will not happen or authentication will not be performed successfully due to no subscriber profile configured in the new visited AAA in the new visited access entwork. It only can be viewed as normadicity. 
Actually in ERP, it Allow EAP server pass the authentication information to local AAA server, so does pre-authentication, but the precondition is there are a trust relationship between the local AAA sever and EAP sever in the remote network,i.e., home network. 

>> Second, I can not establish the mapping between inter-domain handover and indirect pre-authentication or between intra-domain handover >>and direct pre-authentication? There are no clear relationship between them. Before that, I thought direct pre-authenction and indirect pre->>authentication are both focused on intra-domain handover, am I wrong? 
> 
[Qin] I always thought direct pre-authentication indirect pre-authenticaion are only applicable to intra-domain handover,
The reason is there is only one AAA/EAP server in direct/indirect pre-authentication scenarios.  The real inter-domain handover should
allow one serving AAA server and target AAA server exist in the same scenario. So it is better to add more text to address inter-AAA
domain handover which allows the peer move from one serving server to the target AAA server.
> technologies is a major concern, pre-authentication can be effective.
[Qin] okay, I can understand it.
> pre-authentication does not fit EAP model.
[Qin] However there are two phases for pre-authentication, one phase is for key materials derivation and delivery, the second phase is for 
authentication. During handover, the target link maybe has not obtained keying materials. It is one task of pre-authentication to help target link
to get key materals with the help of communication between the serving authenticator and AAA/EAP sever or between the target authenticator and AAA server. e.g., AAA server may be aware of several candiate authenticators with the help of the serving authenticator or the peer, then deliver relevant keying materials to the target authenticator. So it is necesary to consider performing keys materials derivation and delivery during the pre-authentication procedure. Also it is possbile to perform key materials delivery through sigalling exchange between the serving authenticator and AAA/EAP server.
>   the serving authenticator to authenticate the peer."
[Qin] It is necessary to expand inter-AAA domain handover case in section 4. Inter-AAA domain handover means the peer moves from one AAA 
domain to another AAA domain, each AAA domain has at least one AAA sever.
> one kind of inter-technology handover.  It's the other way around.
[Qin] Since you agree with me that inter-technology handover is one kind of inter-authenticator handover,  I think it is necessary to revise the defintion of inter-authentication handover. The reason is since intra-AAA -domain handover includes inter-autheticator and intra-authenticator handover and the inter-authenticator hanover can include inter-AAA-domain handover, we can get that inra-AAA-domain handover includes inter-AAA-domain handover, is it ridiculous conclusion? Hope you can understand.

> As I mentioned above, one access domain can contain multiple
Since intra-access domain can contain multiple authenticators and definitely intra-access domain handover include intra-authenticator handover and inter-authenticator handover, also inter-authentication handover includes inter-access domain handover as you specified in the definition of inter-authenticator handover, it is easy to get intra-access domain handover includes inter-access domain handover , is it contradict to get this conclusion?
>  between the peer and the candidate authenticator."
[Qin] Probably okay, but how? It is not easy to get solution i think.
> riding on a train, with entering bad radio coverage, e.g., tunnels.
[Qin] I agree. I am afraid you miss one point I raised above, i.e., I wonder whether movement over unlicensed frequecy band can be view as handover or normadicity?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 15 Dec 2008 16:01:24 -0500

Hi Qin, 

I am hoping we will be in full agreement within a few email exchanges.

On Mon, Dec 15, 2008 at 11:39:05AM +0800, Qin Wu wrote:
(snip)
> If you insist on keeping no change, I will suggest to delete it from the WG draft, because there are no place to refer this defintion actually.

We can remove the definition of Access Domain.  Since only the place
that uses of the term "access domain" is "inter-access-domain
handover" in Section 3, we can define the term "802.11 Mobility
Domain" instead, and revise Section 3 accordingly.

>   a different AAA server and user credentials than those were used by the serving authenticator to authenticate the peer.

The case you mentioned above is actually the case of a single AAA
server, so the same AAA server and the same user credentials are used
in both AAA domains to authenticate the mobile.  So I think the text
is still ok.

> there are only one AAA/EAP server in these two scenarios, So it is better to add more scenarios and separate AAA/EAP server into the serving AAA and the target AAA someting like that. In this way,…

The scenarios in section 4 applies to both intra-AAA-domain and
inter-AAA-domain handovers.  Instead of adding more scenarios, I would
suggest adding text for Figures 1 and 2 saying that the CA and AAA/EAP
server may belong to different AAA domains, and each AAA domain
typically owns its own AAA server but we only show the AAA server that
has authentication credentials for the particular peer.

> or we don't concentrate on dual radio case in section 4, it is just a special case for both re-authentication and pre-authentication.

I disagree with this restructuring.  Dual vs. single radio handovers
and intra vs. inter AAA-domain handovers are indendent of
direct/indirect pre-auth scenarios (but we say use of pre-auth for
dual radio handover is less effective in Section 3).  The draft does
not say anything like direct and indrect pre-auth are for single radio
and intra-AAA-domain handovers only.

> However in the inter-domain authentication,i.e. inter-AAA-domain authentication, maybe we don't need trust relationship between the visited AAA server in the previous visited access network and the…

We are in agreement here.  I never mentioned that there is no trust
relationship needed between home and visited AAA domains.  What I
mentioned is that trust relationship between the serving and candidate
networks (or domains) is not needed for direct pre-authentication, and
you agreed with it.

> domain handover which allows the peer move from one serving server to the target AAA server.

We will add more text to explain Figures 1 and 2 to mention the case
of multiple-AAA domains.  But there will be always a single AAA server
that authenticates a particular peer, and I don't think we don't need
to change the figures themselves.

> to get key materals with the help of communication between the serving authenticator and AAA/EAP sever or between the target authenticator and AAA server. e.g., AAA server may be aware of several c…

Now we agreed that authentication signaling of pre-authentication
always goes through CA.  MSK derivation and delivery in EAP usually
happens at the end of successful authentication key derivation and
delivery happens when EAP-Success message is sent to the authenticator
from the EAP server.  Since EAP pre-authentication only affects the
timing of EAP authentication, I don't see a need to do something
different from what is done for the currently deployed EAP for MSK
derivation and delivery other than academic exploration.

> [Qin] Since you agree with me that inter-technology handover is one kind of inter-authenticator handover,  I think it is necessary to revise the defintion of inter-authentication handover. The reas…

We don't lead to such a conclusion because we define intra-AAA-domain
and inter-AAA-domain hanodvers exclusively.  And there is nothing
wrong for both types of handovers to include inter-authenticator
handovers, meaning some inter-authenticator handover are
intra-AAA-domain and others are inter-AAA-domain.  However, we can
revise the definition to remove any ambiguity somethign like:

"

      A handover across multiple authenticators.  Some inter-authenticator
      handover may be an inter-access-domain handover, an inter-ESS
      handover, an inter-AAA-domain handover, an inter-technology
      handover, and any possible combination of them.

"

(And we can replace inter-access-domain with inter-mobility-domain if
you agree with my earlier suggestion.)

> [Qin] I agree. I am afraid you miss one point I raised above, i.e., I wonder whether movement over unlicensed frequecy band can be view as handover or normadicity? 

For example, 802.21 (Media-Independent Handover) supports a movement
over unlicensed frequency band as a handover.

Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Tue, 16 Dec 2008 14:59:20 +0800

Hi Yoshihiro:
Thank for your reply. please see my follow up comments below!
Best Regards!
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 16, 2008 5:01 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> I am hoping we will be in full agreement within a few email exchanges.
[Qin] I am believing you can fix what I have raised. After that, full agreement will be achieved.:)
> Domain" instead, and revise Section 3 accordingly.

[Qin] That will be better. Because we have already defined intra-AAA-domain and inter-AAA-domain which are enough to define various scenarios for pre-authentication. 
However as regarding definition of  802.11 Mobility Domain. If you still think the serving authenticator does not change when the mobile node
moves within 802.11 Mobility Domain which includes a set of access networks, I don't agree that.
I still think each access network has at least one authenticator. Don't change authenticator means intra-authenticator handover.

> in both AAA domains to authenticate the mobile.  So I think the text

[Qin] I can't agree they are the same things. The reason is 
In handover case, the mobile node usually moves out of the home AAA domain and roams to the visited AAA domain. In this situation, the mobile node will share the same user credentials with home AAA domain. The visited AAA domain may comprise various of authenticators and visited proxy AAA servers. the Visited proxy server is responsible for relay AAA message from authenticator to the home AAA server.
Sometimes the serving and candidate authenticators belong to the same AAA domains, it means the serving and candidate authenticators 
exchange message with the same visited AAA server, This case can be viewed as the case of a single AAA server, i.e., intra-AAA domain handover case.
Sometimes the serving and candidate authenticators belong to different AAA domains, it means the serving authenticator and the candidate authenticators exchange message with the different visited AAA server respectively. This case should be viewed as inter-AAA domain handover case.
In spite of either case above, the mobile node will share the same user credentials with the home AAA.
So the problem here is how to understand user credentials? who owns the user credentials. who uses the user credentials?
Let me give you one exmaple on how to use user credentials:
The AAA server compares a user's authentication credentials with other user credentials stored in a database. If the credentials match, the user is granted access to the network. If the credentials are at variance, authentication fails and network access is denied.
So the problem is, in our document, it is not the user and AAA server but the candidate authenticator who uses user credentials. Is it true?
Isn't it consistent with the example I give?  

> has authentication credentials for the particular peer.

[Qin] It sounds a good idea, However additional texts you suggest will distort/kill the direct pre-authentication scenario and indirect pre-authentication scenario. Suppose we agree the additional text you mentioned above, and when CA and AAA/EAP server A in the direct pre-authentication scenario belong to different AAA domains, e.g., CA will interact with AAA/EAP server B different from AAA/EAP sever A in the direct pre-authentication scenario,  I will confuse whether AAA/EAP server A or AAA/EAP server B interact with the CA? So it is better to distinguish these different scenarios from the existing two usage scenarios?

> and intra-AAA-domain handovers only.

[Qin] The problem is we mix all different level handover scenarios together.
I can agree to leave behind the dual radio case in section 3, However
Why should we merge the inter-AAA-domain handover with intra-AAA domain handover?
Do you think separation one AAA into two AAA servers will do harm to this WG draft?
>From my point, in order to achieve handover in more large coverage, it is necessary to separate all useful scenarios.
Otherwise pre-authentication is only applicable to some networks with limited coverage,e.g., 802.11 network.. We don't
want to see this happen, do we?

> networks (or domains) is not needed for direct pre-authentication, and

[Qin]Okay, I can understand. Thank for your clarification.

> to change the figures themselves.

[Qin] But what if additional texts do harm to the existing two usage scenarios? In that way, I prefer to separate new scenario to make it clear.
Otherwise, it is not approriate to say there are only two usage scenarios for pre-authentication.

> derivation and delivery other than academic exploration.
[Qin] I don't mean phase 2 happens after phase 1. What I said is there are two phases for preauthentication, one phase is for key management, the other phase is to perform authentication.
 I agree key management happens after successful authentication, and also pre-authentication should obey RFC5247 for the basic EAP based MSK derivation. What we can do is to enhance it to adapt to pre-authentication, draft-ietf-hokey-key-mgm-04 does the similar thing, i.e., expand RFC5247 to adapt to re-authentication. So the key derivation and delivery is one part of pre-authentication. The ultimate purpose of pre-authentication is to validate whether a user is allowed to access to network and configure relevant keying materials on the peer and the corresponding authenticator. So I do think AAA server delivery of key materails to the corresponding authenticator is one part of pre-authentication.

>      handover, and any possible combination of them.
[Qin] How about put it in this way, an inter-ESS handover, inter -AAA-domain handover, inter-technology handover can be viewed as 
inter-authenticator handover or is examples of inter-authenticator handover. 
I can't wholly agree the last sentence in the defintion of inter-authenticator handover, The reason is  "some" and"may be" we use in this sentence are a little ambiguous.
> you agree with my earlier suggestion.)
[Qin] I agree you replace inter-access-domain with inter-802.11 moblity domain. Inter-mobility domain does not make sense.
> over unlicensed frequency band as a handover.
[Qin] Actually how 802.21 can be used to perform inter-authenticator handover is not covered by hokey working group until now.
Since it is regarded as handover, it requires a home AAA server to store user subscription profile and user does not change home AAA server. Each intital authentication request in the intra-AAA domain or each authention request in the inter-AAA domain handover scenario will be forwarded through the proxy AAA server to the home AAA server. Otherwise, How authentication is performed successfully without user subscription profile?
On the other hand, The AAA domain in the inter-AAA-domain or intra-AAA-domain is actually a visited proxy AAA server.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 16 Dec 2008 08:38:28 -0500

> [Qin] I am believing you can fix what I have raised. After that, full agreement will be achieved.:)

Sure, and please see my comments below.

> I still think each access network has at least one authenticator. Don't change authenticator means intra-authenticator handover.

Since 802.11 Mobility Domain is defined in 802.11r without use of the
term "access network", it should be ok.

> Isn't it consistent with the example I give?  

The candidate authenticator does not use authentication credentials,
it only uses EAP key material such as MSK derived from authentication
credentials.  Perhaps the term "user credentials" is confusing.  We
can replace the term "user credentials" with "authentication
credentials used for EAP".

> [Qin] It sounds a good idea, However additional texts you suggest will distort/kill the direct pre-authentication scenario and indirect pre-authentication scenario. Suppose we agree the additional…

I believe AAA/EAP server B in your example is a AAA proxy that
forwards AAA message back and forth between CA and AAA/EAP server A.
We don't need to show such a AAA/EAP server B since it does not own
authentication credentials for the particular peer.  We can further
add text saying that AAA proxies are not shown in the figures.

> want to see this happen, do we?

The current structuring is not something like pre-authentication is
only applicable to some networks with limited coverage.  The main
purpose of the two pre-authentication scenarios (i.e., direct pre-auth
and indirect pre-auth) is to show possible ways of signaling between
peer, SA and CA.  The AAA signaling between CA and AAA server remains
same as current EAP/AAA deployment (except for AAA issues described in
Section 6).  And these pre-authentication scenarios are applicable
regardless of handover scenarios such as inter-AAA-domain handover and
intra-AAA-domain handover.  I do think separation of one AAA into two
AAA servers will lose generality and in that sense it does harm.  For
example, inter-AAA-domain handover is possible without use of a AAA
proxy in a scenario where CA and AAA server in different domains can
directly communicate.  If we add AAA proxy in the figures we don't
cover such a case.  Unless AAA proxy plays an important role for
pre-authentication, it does not make sense to add AAA proxy in the
figures.

> Otherwise, it is not approriate to say there are only two usage scenarios for pre-authentication.

Please see my comment above.

> inter-authenticator handover or is examples of inter-authenticator handover. 

I agree.

> [Qin] I agree you replace inter-access-domain with inter-802.11 moblity domain. Inter-mobility domain does not make sense.

OK.

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Wed, 17 Dec 2008 14:35:42 +0800

Hi,Yoshihiro:
Please see my follow up comments below!
Best Regards!
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 16, 2008 9:38 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> term "access network", it should be ok.
[Qin] It is okay with me.
> credentials used for EAP".

[Qin] I have no objection.Thank for your clarification.

> add text saying that AAA proxies are not shown in the figures.

[Qin] I truely believe AAA/EAP server A and AAA/EAP server B are both proxy AAA servers. They both communicate with the same home AAA server.
wherever the mobile node moves, it does not change the home agent in the home network, also it does not change the home AAA server in the home network.
So if you think the AAA server in the inter-AAA domain handover is the home AAA server, it means the mobile node will change from one home AAA server to another home AAA server.  it does not happen in reality. Because the authentication credentials does not move from one home AAA server to another, authentication will not be performed successfully, not less than handover/service uninterruption.
So Whether or not you add more text, it will not help.
To avoid conflict with direct pre-authentication and indirect pre-authentication, I suggest you to separate  a new scenario to address the case when the moves from one AAA/EAP server, the direct pre-authentication and indirect pre-authentication only can be viewed as the case when the mobile node moves between authenticators within the same AAA/EAP server, the AAA/EAP server in this case is actually a local AAA server.
> peer, SA and CA.  

[Qin] However there are the other possible way to classify  pre-authentication scenarios. e.g.,
As we know, the mobile node does not change the home AAA server , We may consider:
Case a: the mobile node moves between authenticators within the same visited AAA server
Case b: the mobile node moves between authenticators belong to different visited AAA domain
I think this way is a realistic way. I can not image the mobile node will frequently changes the home AAA sever during movement.
>From my understanding, the home AAA server is the only one, other AAA severs are called visited AAA for forwarding the AAA request to the home AAA server. If we consider the mobile node changes the home server in the inter-AAA-domain handover case,  i can not agree this movement is viewed as one kind of  handover. I also can not image the authentication credentials associated with the mobile node will be statically maintained in all the AAA servers in practice.

>The AAA signaling between CA and AAA server remains
> directly communicate.  
[Qin] When the mobile node moves across visited networks, I can not  image how the authenticator in the visited network exchanges message with the home AAA server without the help of the proxy AAA for forwarding messages. Actually authenticators can be categoried into two types:
one is pass through authenticaor and the other is standalone authenticator, in either of these two types when the mobile moves across the visited network, visited AAA server is required to forward the authentication request to the home AAA server. The difference is that in the standalone authenticator case, visited AAA server will collocated with this authenticator while in the pass throug authenticator case, the visited AAA is separated from the pass through authenticator.
So without the visited AAA server in the roaming/handover scenarios, the authentication does not work.

>If we add AAA proxy in the figures we don't

[Qin] Truely it plays the important role. If we don't distinguish between the proxy AAA and the home AAA, inter-AAA-domain handover does not make sense.
Because the mobile node never change the home AAA server. 

> Please see my comment above.

[Qin] Thanks, however one problem you neglected in the maillist is
 I don't agree that authentication signaling of pre-authentication is going through CA. 
>From my point, If we don't consider one particular case dual radios case(actually this case can be viewed as re-authentication case and pre-authentication case), the authentication signaling of pre-authentication should go through SA while the authentication signaling of Re-authentication should go through the target authenticator or CA  For the direct pre-authentication case, I wonder whether it belongs to pre-authentication case. Because there are no layer 2 connection between the mobile node and the CA,i.e., the mobile node has not attached to the CA. e.g., I use one mobile phone in Japan to make a phone call to a friend in America during I am moving  towards America, I can't believe my mobile phone will be authenticated through one candidate untrusted authenticator in America. It doesn't work without the help of  the trusted authenticator which the mobile node attaches to,i.e., serving authenticator. So I think it is a realistic and efficient way to consider performing pre-authentication through the serving authenticator, e.g. indirect pre-authentication does make sense. 
As regarding direct pre-authentication, it does not work well actually.
On the other hand, there are two purposes of pre-authentication 
1. Validate the mobile node  to access service
2. Configure the keying materails on the mobile node and the target authenticator.
If we perform pre-authentication through SA, these two purposes can be easily achieved through serving authenticator to which the mobile node attaches.

>> [Qin] I agree you replace inter-access-domain with inter-802.11 moblity domain. Inter-mobility domain does not make sense.
[Qin] Thanks!
> You got attachement! (https://www.codealias.info/~zrelli/attachements/)

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 17 Dec 2008 13:13:08 -0500

Hi Qin,

With regard to your proposed scenario on use of serving authenticator
instead of candidate authenticator to communicate with AAA/EAP server
for proactive delivery of EAP key material to candidate authenticator,
I don't think it's EAP pre-authentication.  Your proposed scenario
seems to be EAP-based proactive key distribution (please see RFC 5247
for proactive key distribution), and belong to a different problem
space than EAP pre-authentication.  More investigation on security
issues and AAA impacts would be needed for such a scenario.  Having
said that I kindly suggest you to create a separate email thread or
submit an I-D on your proposed scenario for more detailed discussions.

Please see my response below for your other comments.

> So Whether or not you add more text, it will not help.

The AAA/EAP server in Figures 1 and 2 indicates the AAA/EAP server who
is in charge of authenticating the peer.  Such a AAA/EAP server may be
located in the serving domain, target domain, or some other domain
depending on where the authentication credentials are stored.  I
believe the figures generally captures all possible AAA deployments.
You are right that an inter-AAA domain handover will use the same home
AAA server if the same authentication credentials are used for the
serving and target domains and there is a roaming agreement between
the domains.  This case is also covered in the figures, however, that
is not the only case to cover.

> To avoid conflict with direct pre-authentication and indirect pre-authentication, I suggest you to separate  a new scenario to address the case when the moves from one AAA/EAP server, the direct pr…

I don't understand why direct and indirect pre-auth should be
restricted to use the local AAA server, so I don't agree with your
suggestion.

> As we know, the mobile node does not change the home AAA server , We may consider:

This is not the only case as described in the draft, i.e., the mobile
can use different home AAA servers if there is no trust relationship
between the serving and target domains and the mobile uses different
authentication credentials for them.  So your classification below
does not work for me.

> From my understanding, the home AAA server is the only one, other AAA severs are called visited AAA for forwarding the AAA request to the home AAA server. 
>If we consider the mobile node changes the home server in the inter-AAA-domain handover case,  i can not agree this movement is viewed as one kind of  handover. I also can not image the authentication credentials associated with the mobile node will be statically maintained in all the AAA servers in practice.

There is no need for all the AAA servers to maintain the
authentication credentials for the mobile.

> [Qin] When the mobile node moves across visited networks, I can not  image how the authenticator in the visited network exchanges message with the home AAA server without the help of the proxy AAA for forwarding messages.

In the case of Diameter, the authenticator can use redirect to
directly communicate with the home AAA server, if the authenticator
can establish an end-to-end SA with the server.  Even redirect is not
used or an end-to-end SA is not available, a proxy is not needed and
relay agent can be used instead.

> Actually authenticators can be categoried into two types:

Why a standalone authenticator needs to be collocated with a AAA
server?  I also don't agree with the statement that the visited AAA
server is required to forward authentication requests to the home AAA
server, as I mentioned above.

> Because the mobile node never change the home AAA server. 

As long as the mobile can communicate with an AAA/EAP server who is in
charge of authenticating the mobile, I don't see a reason for caring
about how AAA messages are forwarded between CA and the AAA/EAP server
in this draft.

Best Regards,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 18 Dec 2008 14:21:01 +0700

Yoshihiro Ohba [mailto:[email-masked]] writes:

> I don't think it's EAP pre-authentication.  

Following this thread I've been impressed with how little it (& the draft
itself, for that matter) has to do with hokey.  It's almost as if RFCs 5295
& 5296 had never been published: there's lots of talk about generic AAA &
EAP but little to no discussion of the technology we've developed in this
WG, to the point where I've wondered if the document has actually been
drafted in anticipation of a BoF (or in support of work in another WG or
SDO).  We have defined an authentication protocol and (at least informally)
a service to support it, why are we not building upon that foundation?
Actually, I've been toying with an idea along these lines for some time &
have discussed with a couple of people; it seems that if we assume that the
peer can identify a CA in advance, a small extension to ERP could be used to
authenticate through the SA, while the hokey server could proactively ship
keying material to the AP specified by the peer in the ERP messaging.  This
scheme has the advantage that it builds upon the stuff we've already
defined, seems to avoid the security problems involved in RFC 5247 WRT
proactive key distribution and would be workable (at least in the
intra-domain case -- I haven't thought deeply about the inter-domain case
but it could work there, too).  However, I can't see where this model is
accommodated in your diagrams.

> Your proposed scenario
> for proactive key distribution), 

RFC 5247 says (in Section 4, Vulnerabilities -- gosh, that's unbiased! ;-)
about proactive key distribution: 'EAP is not needed, but the Discovery, and
Secure Association Protocol exchanges are still necessary.  Within the AAA
exchange, authorization and key distribution functions are typically
supported, but not authentication'.  However, Qin said: '...there are two
purposes of pre-authentication  1. Validate the mobile node to access
service  2. Configure the keying materails on the mobile node and the target
authenticator'.  If "[v]alidate the mobile node to access service" includes
authentication (which I would argue is only reasonable) then it seems to me
that the scheme qualifies as preauthentication rather than proactive key
distribution as RFC 5247 defines it.

> and belong to a different problem

Along those lines, I wonder if you would mind posting a summary of this
thread so far, from your POV?  I, for one, am finding it quite difficult to
follow...

...

> > [Qin] When the mobile node moves across visited networks, I can not
> image how the authenticator in the visited network exchanges message
> with the home AAA server without the help of the proxy AAA for
> forwarding messages.
> 
> can establish an end-to-end SA with the server.  

While possible, this is highly unlikely IMHO,

> Even redirect is not

I suspect that you are taking the word "proxy" a little too literally :-).

> > one is pass through authenticaor and the other is standalone
> authenticator, in either of these two types when the mobile moves
> across the visited network, visited AAA server is required to forward
> the authentication request to the home AAA server. The difference is
> that in the standalone authenticator case, visited AAA server will
> collocated with this authenticator while in the pass throug
> authenticator case, the visited AAA is separated from the pass through
> authenticator.
> 
> server?  

It's not.  I think that this is a terminology problem, along with the
popular and incorrect conflation of AAA servers & EAP "servers" (actually
part of the authenticator).

> I also don't agree with the statement that the visited AAA

I guess I missed the rationale for this interesting assertion.  Would you
mind explaining again?

...

---

From: Yoshihiro Ohba <[email-masked]>
Date: Thu, 18 Dec 2008 13:35:21 -0500

Glen,

This is a WG scope issue, isn't it?  We are working on EAP
pre-authentication problem statement that is a work item of the WG.
Qin's scenario is EAP-based proactive key distribution not EAP
pre-authentication.  Since proactive key distribution is not in the
scope of the WG, I don't see a point to including the scenario or even
discussing it in this thread, so I will refrain from commenting on the
scenario in this thread.

Responding to your last comment bolow, I meant redirect case where AAA
client can directly communicate with AAA server.

I'll send a separate email for summary of the discussion based on your
request.

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Dec 2008 11:32:53 +0800

Hi, Yoshihiro:
sorry but going through your comments I still don’t see the usage scenarios can cover inter-AAA-domain handover.Thank a lot for your patience.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, December 18, 2008 2:13 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> space than EAP pre-authentication. 

[Qin] In RFC 5169, the requirements on Reactive key management and Re-authentication are both addressed simutaneously. Why?
Because key mangement is one integral part of Re-authentication, after authentication, the key materials are allowed to be deployed.
In current draft draft-ietf-hokey-preauth-ps, proactive key managment is also a integral part of pre-authentication, after succesful
pre-authentication, the proactive key materials are allowed to be deployed. It is the same thing. What's wrong with that? Why we try to 
avoid proative key management to optimize pre-authentication procedure. It is because proactive key managment is beyond the scope of this document? Is it concrete? I agree without key materials delivery, handover latency caused by the pre-authenticaion will be greatly reduced.
But Pre-authentication does not make sense without key management. You can refer to problem statement for Re-authentication to see that.

 More investigation on security
> issues and AAA impacts would be needed for such a scenario.  

[Qin] Actually the EAP Pre-authentication and Proactive Key distribution have already been discussed in RFC5247, But they does not point out
the relationship between them. Is it the work we should do in hokey working group?

>Having
[Qin] Sure, if it is necessary, I will do that.
> depending on where the authentication credentials are stored.  
[Qin] In your scenarios, whether a AAA/EAP sever is located in the serving domain or target domain, it is the only one AAA server. It can not
cover inter-AAA-domain handover scenario which require two different AAA server to involve in.
>I believe the figures generally captures all possible AAA deployments.
> the domains.  

[Qin] I does not say there is a roaming agreement between the serving domain and target domain.
What I said is there is a roaming agreement between the serving domain and the home domain or between the target domain and the home domain. 

>This case is also covered in the figures, however, that
[Qin] What's inter-AAA-domain handover? what is intra-AAA-domain handover? The key difference is whether the authenticators share the same AAA server or different AAA servers, I think.
> restricted to use the local AAA server, so I don't agree with your

[Qin] In the intra-AAA-domain handover scenario, the serving authenticator and the target authenticator share the same local AAA server in the visited access network, also share the same home AAA server in the home network. Direct pre-authentication and indirect pre-authentication are both viewed as this scenario.
whereas in the inter-AAA-domain handover scenario, the serving authenticator and the target authenticator belong to the different AAA domain associated with  visited serving network and visited target network.
but they can share the same home AAA sever in the home network.

> authentication credentials for them.  
[Qin] I can not agree with you that the mobile can use different home AAA severs. Also your explaination is not clear.
because the the home AAA sever the mobile uses is not relevant to the trust relationship between the serving domain and target domain.
>So your classification below
> does not work for me.
[Qin] Normally they does not change the home AAA server in the homogeneous network. Even in the hetergenious network, if we allow two different network interwork with each other(e.g., 3GPP network interworking with WiMAX network), the home AAA server for the mobile node will not be relocated. There is only one home AAA sever for mobile.

> authentication credentials for the mobile.

[Qin] I agree. The only way to solve the problem is to introduce the key materials distribution mechanism during pre-authentication. However
proactive key delivery mechanism is neglected in the Draft-ietf-hokey-preauth-ps.

> relay agent can be used instead.

[Qin] I can not believe that in the handover scenario. Only standalone authenticator can cover this. You can refer to some work in WiMAX NWG
in which how NAI is extended to find the home AAA is addressed.

> server, as I mentioned above.
[Qin] That's the key problem we don't agree with each other.

> about how AAA messages are forwarded between CA and the AAA/EAP server
[Qin] That point is the Proxy AAA sever and the Home AAA server are both responsbile for authenticating the mobile.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Dec 2008 00:12:50 -0500

Qin,

Regarding key managment, I commented as follows:

"
  EAP-based key management is needed for pre-authentication because it
  is based on EAP, and pre-authentication must follow RFC 5247.  We
  can add explicit text on this requirement in Security Considerations
  section.
"

Please see below for other comments.'

On Fri, Dec 19, 2008 at 11:32:53AM +0800, Qin Wu wrote:

(snip)

> [Qin] Sure, if it is necessary, I will do that.

Please do it, execting more people will participate in the discussion.
You should describe detailed scenarios with sequence diagrams so that
people do not misunderstand your proposal.

> cover inter-AAA-domain handover scenario which require two different AAA server to involve in.

I already commented:

"The scenarios in section 4 applies to both intra-AAA-domain and
inter-AAA-domain handovers.  Instead of adding more scenarios, I would
suggest adding text for Figures 1 and 2 saying that the CA and AAA/EAP
server may belong to different AAA domains, and each AAA domain
typically owns its own AAA server but we only show the AAA server that
has authentication credentials for the particular peer."

I agree that in some cases AAA proxy is involved in the signaling such
as forwarding authentication messages to the home AAA server, but we
don't have to show it.  Not showing it in the figure does not mean
proxy is not participated in the communication.  We can further add
clarification text to say that an intermediary AAA node such as a AAA
proxy may also involve in the AAA signaling between CA and AAA/EAP
server.  I hope this helps.

> What I said is there is a roaming agreement between the serving domain and the home domain or between the target domain and the home domain. 

OK, and the figures also cover that case.

> [Qin] What's inter-AAA-domain handover? what is intra-AAA-domain handover? The key difference is whether the authenticators share the same AAA server or different AAA servers, I think.

No.  Even in inter-AAA-domain case the authenticators can use the same
(home) AAA server to authenticate the peer if there is a roaming
agreement between the serving domain and home domain and between the
target domain and home domain.

> but they can share the same home AAA sever in the home network.

This means they do not use the same local AAA server for
inter-AAA-domain handover, which I agree.  What I don't really
understand is why you think both direct and indirect pre-auth do not
work for inter-AAA-domain handover.  You need to explain it in
details.

> because the the home AAA sever the mobile uses is not relevant to the trust relationship between the serving domain and target domain.

What I meant is, the serving domain and target domain may not share
the same home AAA domain for the peer.  If the same home AAA domain is
not shared, this means that the mobile uses different home AAA servers
(and different credentials) to access the serving and target networks.

> [Qin] Normally they does not change the home AAA server in the homogeneous network. Even in the hetergenious network, if we allow two different network interwork with each other(e.g., 3GPP network…

You really missed one scenario.  The serving network can be an WiFi
network that is not managed by operators and the target network can be
cellular or WiMAX network manged by operators.

> in which how NAI is extended to find the home AAA is addressed.

Since this draft is not a WiMAX forum document, I don't think covering
only WiMAX is a good idea.  This problem statement should cover
possible AAA deployments as much as possible.

> [Qin] That point is the Proxy AAA sever and the Home AAA server are both responsbile for authenticating the mobile.

I don't agree.  When home AAA server is responsible for authenticating
the peer, proxies are just forwarding authentication messages.  How
proxies can authenticate the peer if they do not have the
authentication credentials for the peer?

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 19 Dec 2008 12:32:53 +0700

...

> people do not misunderstand your proposal.

A separate draft is unnecessary, however it would be a good idea to submit
text (or preferably XML) for inclusion in the existing WG draft (pending WG
consensus, of course).  BTW, not that I don't appreciate the unsolicited
help in chairing the WG ;-) but perhaps you could just stick to editing the
document & leave the determination of those things which are in and out of
scope to Charles & I.

...

---

From: Qin Wu <[email-masked]>
Date: Fri, 19 Dec 2008 16:13:37 +0800

Thanks for your response, please see my followup comments below.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 19, 2008 1:12 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

>  can add explicit text on this requirement in Security Considerations
[Qin] It will be better to separate one independent section to clarify how EAP-based key management
can be adopted to meeting the requirements for pre-authentication.
> people do not misunderstand your proposal.
[Qin] Actually my proposal is to distinguish the relationship between the authenticators and AAA/EAP server.
In intra-AAA-domain handover when the peer moves across different visited network,  all the authenticators belong to the same AAA domain and 
communicate with the same AAA server.
In the inter-AAA-domain handover when the peer moves across different visited network, the serving authenticator and the target authenticator belong to the different AAA domains and each authenticator communicate with each AAA server, 
I wonder whether it is beyond the scope of this document.
> has authentication credentials for the particular peer."
[Qin] As I said before, If we assume the CA and AAA/EAP server belong to different AAA domains in direct or indirect pre-authentication, 
it will bring up a big confusion whether the CA communicate with the AAA server same as which SA belongs to or different from which SA belongs to. In this way, the direct pre-authentication or indirect pre-authentication will be killed or harmed. So that's why I suggest to separate scenarios from the figure 2 and 3.

> as forwarding authentication messages to the home AAA server, but we
[Qin] Not some case but all the case which proxy AAA is required if we consider handover or mobility.

> server.  I hope this helps.
[Qin] It is better to add some clarification text for figure 1.
> OK, and the figures also cover that case.
[Qin] Let me clarify two cases:
1. When the mobile moves from the home network to visited network, in this scenario, the home network is viewed as seving domain and home domain, the visited network is viewed as target domain.
2. When the mobile moves from previsou visited network to the new visited network, in this scenario, the previous visited network is viewed as serving domain and the new visited network is viewed as the target domain.
> target domain and home domain.

[Qin] As I said before, in this sceanrio when the mobile moves from the home network to the visited network, the home server is not only viewed as home AAA server but also viewed as the serving AAA server, the AAA server in the visited netwok is  viewed as the target AAA server. The mobile will communicate with the home/serving AAA serving through the target AAA server in the visited network.

> work for inter-AAA-domain handover.  You need to explain it in
[Qin] In the inter-AAA-domain handover scenrios, at least four funtional entities are involved, i.e., the serving authenticator, the target authenticator, the previous AAA sever served by the serving authenticator, the new AAA server served by the target authenticator. In the case when the mobile moves from the home network to the visited network,
the previous AAA server also could be viewed as the home AAA server while in the case when the mobile moves between different visited network, the home AAA server is different from the four funtional entities mentioned above.

So at the next step, Let us see why both direct and indirect pre-auth do not work for inter-AAA-domain handover.
As you suggested before, you will add text for Figures 1 and 2 saying that the CA and AAA/EAP
 server may belong to different AAA domains, and each AAA domain typically owns its own AAA server
Then here is the problem, Since the CA and AAA/EAP server belong to different AAA domain, i.e., the CA the the prvious AAA server belong to different AAA domain, why CA communicate with the previous visited AAA server in direct or indirect preauthentication case? It is the new AAA server with which the CA need to communicate. So that's why I suggest to separate the scenarios from the figure 2,3.

> (and different credentials) to access the serving and target networks.
But it will never happen, because service continuity in the handover can not be achieved.
> cellular or WiMAX network manged by operators.
[Qin] what I said above has already covered this case.
> possible AAA deployments as much as possible.
[Qin] I just give you a example, not add WiMAX stuff in this draft.
> authentication credentials for the peer?
[Qin] If we can reuse the key materials for the intial authentication in the intra-AAA-domain handover or inter-AAA-domain handover cases,
It is not a big deal to download authentication credentials from the home AAA server. On the other hand, another role of proxy AAA is to forward authentication request to the home AAA, it is a part of authenticating the peer.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Dec 2008 09:52:22 -0500

Qin,

Please see my comments below..

> can be adopted to meeting the requirements for pre-authentication.

Since EAP pre-authentication only affects the timing of authentication
and does not expect to change the behavior on how keys are distributed,
I don't think separate section is needed.

> [Qin] Not some case but all the case which proxy AAA is required if we consider handover or mobility.

This is one thing that I don't agree.  

> 2. When the mobile moves from previsou visited network to the new visited network, in this scenario, the previous visited network is viewed as serving domain and the new visited network is viewed a…

These are covered in the figures.

> [Qin] As I said before, in this sceanrio when the mobile moves from the home network to the visited network, the home server is not only viewed as home AAA server but also viewed as the serving AAA…

This is covered by the figures.

> Then here is the problem, Since the CA and AAA/EAP server belong to different AAA domain, i.e., the CA the the prvious AAA server belong to different AAA domain, why CA communicate with the previou…

There is no need for CA to communicate with the serving AAA server in
figures 2 and 3.  The CA only needs to communicate with the home AAA
server of the peer (via proxies in some deployments which we don't
have to show in the figures).  In this case, the home AAA server is
the AAA server in the figures.

> [Qin] what I said above has already covered this case.

No.  It does not cover the case where there is no AAA server in the
serving network.

> It is not a big deal to download authentication credentials from the home AAA server. 

In this case, that AAA proxy will be the AAA server in the figures
once after the credentials are obtained from the home AAA server.

>On the other hand, another role of proxy AAA is to forward authentication request to the home AAA, it is a part of authenticating the peer.

In this case, the home AAA server will be the AAA server in the
figures.  But the proxy is not resonsible for authenticating the peer
even if it is part of AAA signaling.

So, I don't see a problem with the figures.

Regards,
Yoshihiro Ohba

---

From: Yoshihiro Ohba <[email-masked]>
Date: Fri, 19 Dec 2008 10:52:01 -0500

Glen,

All of my comments are as a technical contributor as well as an
editor, and as a technical contributor I really would like to see
detailed text from Qin, otherwise I can't agree with his comments.  I
am sorry if you feel otherwise, that's not my intent!

Regards,
Yoshihiro Ohba

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 21 Dec 2008 08:26:08 +0700

Yoshihiro Ohba [mailto:[email-masked]] writes:

> detailed text from Qin, otherwise I can't agree with his comments.  

That's fine.  

> I am sorry if you feel otherwise, that's not my intent!

The question of whether a topic is in or out of scope of the WG charter is
predominantly a procedural rather than a technical one.

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Dec 2008 14:39:59 +0800

Dear,Yoshihiro
Thank for your reply, I have some follow up coments below.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 19, 2008 10:52 PM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> I don't think separate section is needed.
[Qin]If my understanding is correct, in the draft-ietf-pana-preauth in PANA working group, PANA pre-authentication also
comprises the security association establishment phase. It implies the key materials should be distributed to establish the security association.
So do you think there is no change for key management during PANA pre-authentication?
Also I don't think we intend to change the behavior of key distribution. We just employ it to work with pre-authentication.
As we agreed before, the basic pre-authentication should consist of authentication phase and the key management phase. Key management is one integral part of pre-authentication.
> This is one thing that I don't agree.  
[Qin] For non-roaming case, the AAA proxy can be viewed as the home AAA server.
For the roaming case, the AAA proxy is separated from the home AAA server.
For scalability consideration and roaming requirements, the AAA in the inter-AAA-domain handover should be split into two, otherwise,
I can not see it is one kind of inter-AAA-domain handover.
> These are covered in the figures.
[Qin] The point is how to distinguish inter-AAA-domain handover and intra-AAA-domain handover?
Since the inter-AAA-domain handover can cover inter-authenticator handover and also intra-AAA-domain-handover consists of intra-authenticator handover and inter-authenticator handover,  it is very ambiguous to understand who play who in these two cases. 
Since the usage scenario and problem statement is not clear, how to design solution to meeting these in the future?
>From what you understand in this draft, I agree the usage scenarios in this draft is applicable to the case when the mobile moves between WLAN networks, however I can not see the usage scenarios work for the case when the mobile moves between 3GPP networks or 3GPP2 networks.

> This is covered by the figures.
[Qin]But it is ambiguous if you think the usage sceanrios in the draft can cover all the cases.
> the AAA server in the figures.
[Qin] However according to your understanding, here the serving AAA server is also the home AAA. Because for a mobile, the user subscription profile and authentication credentials are only maintained by the only one home AAA server. If you allow the mobile change the home AAA, how could you move the user subscription profile and authentication credentials for this mobile to another AAA server.It is totally ambiguous. 
On the other hand, suppose the scenarios you mentioned here does exists, how could you keep the session uninterruption?
> No.  It does not cover the case where there is no AAA server in the
[Qin] So what you consider in this draft only covers the case when the mobile moves from an WiFi network to the cellular network I think.
Even that, if we allow WLAN network interworking with cellular network, the AAA server in the cellular network can provide authentication to the 
mobile in the WiFi network.
On the other hand, have you consider the case when the mobile moves from one 3GPP access network to another 3GPP access network? I can not see in the draft.
> once after the credentials are obtained from the home AAA server.
[Qin] I agree.
> even if it is part of AAA signaling.
[Qin] Since we agree the AAA proxy can be a AAA server mentioned above, then the AAA proxy could be responsible for authenticating the peer.

---

From: Yoshihiro Ohba <[email-masked]>
Date: Mon, 22 Dec 2008 16:51:18 -0500

Hi Qin,

> So do you think there is no change for key management during PANA pre-authentication?

Right.  No change for AAA key management should be needed for it.

> Also I don't think we intend to change the behavior of key distribution. We just employ it to work with pre-authentication.

Right.  We don't intend to change the behavior of AAA key
distribution, including who is requesting which key from which entity
and how the key is distributed to the entity who requests the key.

> I can not see it is one kind of inter-AAA-domain handover.

There may no AAA proxy for both roaming and non-roaming cases.  I
understand AAA proxies are used in many cases, but not all cases.
What I don't understand is how relevant AAA proxies are in
pre-authentication scenarios while EAP pre-authentication only affects
the timing on EAP authentication, except that an AAA proxy can be in
charge of authenticating the peer as a AAA server if has obtained
authentication credentials from the home AAA server.  Please also see
my comments on this exception.

> [Qin] The point is how to distinguish inter-AAA-domain handover and intra-AAA-domain handover?

This is explained in the terminogy section, we agreed to revise the
text to reflect your comments.  If it is revised I don't see issues
with the figures themselves.

> From what you understand in this draft, I agree the usage scenarios in this draft is applicable to the case when the mobile moves between WLAN networks, however I can not see the usage scenarios wo…

If you agree that the scenarios works for handover between WLAN
networks, you are basically agreeing that inter-AAA-domain and
intra-AAA-domain cases are covered for WLAN in the scenarios, since
there can be multiple AAA domains even for WLAN handvoer.  So I don't
understand why you are saying that the scenarios do not work for 3GPP
or 3GPP2 handovers.

> [Qin]But it is ambiguous if you think the usage sceanrios in the draft can cover all the cases.

As I mentioned, we can add more text to explain the figures to remove
ambiguity.

> On the other hand, suppose the scenarios you mentioned here does exists, how could you keep the session uninterruption?

I thought we are discussing the case where the serving AAA domain is
different from the home AAA domain.  If not I am sorry about that.  If
the serving AAA domain is the same as the home AAA domain, then CA
will need to communicate with the serving AAA server which is the home
AAA server, again via proxies in some deployments which we don't have
to show in the figures.

> [Qin] So what you consider in this draft only covers the case when the mobile moves from an WiFi network to the cellular network I think.

It covers not only that case but also others.

> mobile in the WiFi network.

Yes, that's for sure, and the case is also covered.

> On the other hand, have you consider the case when the mobile moves from one 3GPP access network to another 3GPP access network? I can not see in the draft.

Definitely we considered other technologies as well, that is why we
have the following text in Section 3:

"Hence, the security optimization mechanisms for better handover
performance must be looked at from the IP level so as to make it a
common method over different access technologies."

If you like, we can explicitly mention 3GPP, 3GPP2 and WiMAX in the
above text.

> [Qin] Since we agree the AAA proxy can be a AAA server mentioned above, then the AAA proxy could be responsible for authenticating the peer.

Yes, and we can mention AAA proxy in the text that explains the
AAA/EAP server in the figures.

Regards,
Yoshihiro Ohba

---

From: Qin Wu <[email-masked]>
Date: Tue, 23 Dec 2008 15:24:11 +0800

Hi,Yoshihiro:
Please see the followup comments below.
-Qin
----- Original Message ----- 
From: "Yoshihiro Ohba" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 23, 2008 5:51 AM
Subject: Re: [HOKEY] I-D Action:draft-ietf-hokey-preauth-ps-05.txt

> and how the key is distributed to the entity who requests the key.
[Qin]: I just emphasize the key derivation and delivery is a integral part of pre-authentication.But I can not understand what you indicate here.
Of course, it is the peer who requests the key from the AAA/EAP server, of course, the AAA server will  distribute keying materials to the authenticator and the peer. In the intra-AAA-domain handover when the mobile moves within the AAA server, the AAA server serving the peer need not be separated. However in the inter-AAA-domain handover when the mobile moves between two different AAA server, the AAA server serving the peer should be separated. Also in either of cases, the purposes of the pre-authentication are to authenticate the peer whether it is allowed to access to the target authenticator and generate the keying materials shared between the peer and the candidate authenticator.
>> As we agreed before, the basic pre-authentication should consist of authentication phase and the key management phase. Key management is >one integral part of pre-authentication.
>> >> > 
>> >> > I already commented:
>> >> > 
> the timing on EAP authentication, 
[Qin] So what you focus here is the home AAA server is the only AAA server in the direct pre-authentication and indirect pre-authentication.
Then inter-AAA-domain-handover will not be supported or distorted. Actually in 3GPP access network, the AAA proxy is the first AAA server
serving the peer. Also the AAA proxy will interact with the home AAA server to get the keying materials which normally happens at the initial authentication in the one AAA domain.
>except that an AAA proxy can be in
[Qin]As your understanding, the inter-AAA-domain-handover is not supported in the draft-hokey-preauth-ps.
If you assume the authentciation credentials is static configured in the AAA/EAP server. It will limit the application of these scenarios.
However after successful authentication before the mobile moves to the target network, the authentication credentials 
can be dynamically pushed from the home AAA server or pulled by the AAA proxy. It is a part of pre-authentication.
> with the figures themselves.
[Qin] The figure 1 is okay. But the figure 2 and figure 3 can not cover the cases of inter-AAA-domain handover.
>> Since the inter-AAA-domain handover can cover inter-authenticator handover and also intra-AAA-domain-handover consists of intra->>authenticator handover and inter-authenticator handover,  it is very ambiguous to understand who play who in these two cases. 
>> From what you understand in this draft, I agree the usage scenarios in this draft is applicable to the case when the mobile moves between >>WLAN networks, however I can not see the usage scenarios work for the case when the mobile moves between 3GPP networks or 3GPP2 >>networks.
> 
[Qin] Sorry, what I actually said here is the scenaios only works for handover within the WLAN network. 
As regarding handover between WLAN network, it never happen in reality. Because the current WLAN network only support 
limited mobility. You can refer to the work in CAPWAP working group, there are no any progress to support layer 3 mobility for capwap.
So the practical scenarios are
1.Handover within WLAN
2.Handover between one  cellular network to antoher cellular network.
3. Handover between the WLAN network and Cellullar network. 
> As I mentioned, we can add more text to explain the figures to remove
[Qin] It depends what you add in the section. Before that, I would like to suggest to separate the AAA into two for inter-AAA-domain handover.
> AAA server, again via proxies in some deployments which we don't have
[Qin] So in the intra-AAA-domain handover, the SA and CA are served by the same Serving AAA, the Serving AAA can be viewed as the home AAA.
In the inter-AAA-domain handover, the SA and CA are served by the different AAA proxy, the AAA proxy is different from the home AAA.
> It covers not only that case but also others.
[Qin] This is one thing I can not agree.
> Yes, that's for sure, and the case is also covered.
[Qin] I have no objection on this.
[Qin] It will be better.
> AAA/EAP server in the figures.
[Qin] Okay. As I said, it depends on what you propose to add in the draft.