Subject: Re: [HOKEY] WGLC: draft-ietf-hokey-preauth-ps-02

From: Rafa Marin Lopez <[email-masked]>
Date: Tue, 01 Apr 2008 20:44:51 +0200

Hi Charles, all

I have reviewed this version (v02) after my previous review on v01. And 
everything  is ok for me with the new version.

Thanks.

Charles Clancy wrote:
> This serves as the Working Group Last Call (WGLC) for the EAP 
> Pre-authentication Problem Statement:
>
> 	http://tools.ietf.org/html/draft-ietf-hokey-preauth-ps
>
> Please send any comments on the document to the list by April 7, 2008.
>
>   

-- 
------------------------------------------------------
Rafael Marin Lopez
Dept. Information and Communications Engineering (DIIC)
Faculty of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34968398501    e-mail: [email-masked]
------------------------------------------------------

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

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 1 Apr 2008 16:16:24 -0400

Hi Preetida,

Thank you for reviewing the draft.  I have a comment on your comment #2.

On Mon, Mar 31, 2008 at 08:48:06AM +0300, [email-masked] wrote:
> >> 
> >> 2. In indirect pre-autnetication, it is asusmed that there will be
> >> pre-exisitng trust between SA and CA. To me this scenario is 
> >analogus to
> >> fast handover in MIP, with proxy-solicitation msg. However 
> >keeping MIP
> >> aside, even if MN receives IP level details of CA through SA, the
> >> performed pre-authentication can be partial as MN still needs to
> >> associate CA first before using IP level security. Any comments?   
> >
> >AD. The draft does not make any assumption regarding 
> >pre-established  SA 
> >between SA and CA, as SA (Serving Authenticator) acts like a proxy and 
> >forwards the packets to CA (Candidate Authenticator). MN does not 
> >directly communicate with CA, but SA does communicate with CA 
> >in case of 
> >indirect pre-authentication. So the role of CA and SA are little 
> >different than PAR and NAR that you have mentioned for FMIPv6.
> >
> >I do not understand quite well about the partial pre-authentication of 
> >MN. Could you please clarify it little more?
> >
> 
> [Preeti] Parital authentication -> In above scenrio, Preauthentication
> involves direct IP level communication between SA and CA, Although
> resulted pre-authentication is for MN, it does not include MN's layer 2
> authentication. Hence it is partial. If layer 2 authentication fails
> then success of layer 3 may not bring any value or underutilization of
> reserved resources. 

Direct pre-authentication and indirect pre-authentication are the same
in that both happen before MN performs L2 secure association to CA.
Context Binding, described in Section 5.2, will create binding between
link-layer independent context and link-layer specific context, so
that L2 secure association can succeed when L2 handover happens.

Yoshihiro Ohba

---

From: <[email-masked]>
Date: Wed, 2 Apr 2008 14:54:17 +0300

Hi Yoshi:

Thanks for response. Inline pl 

Regds
Preeti
>pre-established  
>> >SA between SA and CA, as SA (Serving Authenticator) acts 
>like a proxy 
>> >and forwards the packets to CA (Candidate Authenticator). 
>MN does not 
>> >directly communicate with CA, but SA does communicate with 
>CA in case 
>> >of indirect pre-authentication. So the role of CA and SA are little 
>> >I do not understand quite well about the partial pre-authentication 
>> >of MN. Could you please clarify it little more?
>> >
>> 
>> resulted pre-authentication is for MN, it does not include 
>MN's layer 
>> 2 authentication. Hence it is partial. If layer 2 
>authentication fails 
>Direct pre-authentication and indirect pre-authentication are 
>the same in that both happen before MN performs L2 secure 
>association to CA.
>Context Binding, described in Section 5.2, will create binding 
>between link-layer independent context and link-layer specific 
>context, so that L2 secure association can succeed when L2 
>handover happens.

[Preeti] I.e. context bidning is carrying link specific or independent
authentication pareamters. However what I mean by partial authentication
is that with proper context binding perhaps L3 authentication can be
successful, but one can only be sure about such successful
authentication if L2 authetnication is also successful. Do you agree?

---

From: Yoshihiro Ohba <[email-masked]>
Date: Wed, 2 Apr 2008 09:02:41 -0400

On Wed, Apr 02, 2008 at 02:54:17PM +0300, [email-masked] wrote:
(snip)
> authentication if L2 authetnication is also successful. Do you agree? 

If I understand your point correctly, any pre-authentication including
media-specific pre-authentication such as 802.11i pre-authentication
might have the same characteristic, i.e., one can only be sure about
successful authentication if 802.11i 4-way handshake is also
successful.

Yoshihiro Ohba

---

From: Subir Das <[email-masked]>
Date: Tue, 08 Apr 2008 02:06:00 -0400

Put my comments on the document and is attached herewith.  Search for  
'SD'. 
The draft describes the problem nicely with issues but it requires a 
good amount
of editing. Some parts of the draft may not be required for example, 
Appendix.
Also a lot of abbreviations need to be expanded. May be a good idea
to add a terminology section.

regards,
_Subir

> Please send any comments on the document to the list by April 7, 2008.

Network Working Group                                   Y. Ohba (Editor)
Internet-Draft                                                   Toshiba
Expires: August 25, 2008                               February 22, 2008

                EAP Pre-authentication Problem Statement
                     draft-ietf-hokey-preauth-ps-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   EAP pre-authentication is defined as the utilization of EAP to pre-
   establish EAP keying material on an authenticator prior to arrival of
   the peer at the access network managed by that authenticator.  
   
   SD> Instead of ?on an authenticator? it may be appropriate to say ?on a target authenticator?. Also ?use? may be better than ?utilization? 

   This
   draft discusses EAP pre-authentication problems in details.

Ohba (Editor)            Expires August 25, 2008                [Page 1]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

Table of Contents

   1.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Specification of Requirements  . . . . . . . . . . . . . .  4
   3.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Direct Pre-authentication  . . . . . . . . . . . . . . . .  7
     4.2.  Indirect Pre-authentication  . . . . . . . . . . . . . . .  8
   5.  Architectural Considerations . . . . . . . . . . . . . . . . .  9
     5.1.  Authenticator Discovery  . . . . . . . . . . . . . . . . .  9
     5.2.  Context Binding  . . . . . . . . . . . . . . . . . . . . . 10
   6.  AAA Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Performance Requirements  . . . . . . . . . . . . . . 14
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Intellectual Property and Copyright Statements . . . . . . . . . . 17

Ohba (Editor)            Expires August 25, 2008                [Page 2]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

1.  Contributors

   The following people contributed to this document.

        Yoshihiro Ohba ([email-masked])

        Ashutosh Dutta ([email-masked])

        Srinivas Sreemanthula ([email-masked])

        Alper E. Yegin ([email-masked])

        Madjid Nakhjiri ([email-masked])

        Mahalingam Mani ([email-masked])

2.  Introduction

   When a mobile during an active communication session moves from one
   access network to another access network and changes its point of
   attachment it is subjected to disruption in the continuity of service
   because of the associated handover operation.  During the handover
   process, when the mobile changes its point-of-attachment in the
   network, it may change its subnet or administrative domain it is
   connected to.  We provide in Appendix A some performance requirement
   that are needed to support an interactive real-time communication
   such as VoIP and thus can serve as the guidelines for handover
   optimization. 

   SD> General comment: Word ?mobile? is used in several places and ?mobile 
   node? is used in other places. I think it should be ?mobile node? everywhere.

   SD> It is not clear from the above paragraph whether the mobile node is performing a handover using a single radio interface or always active dual radio interface. The performance requirement in Appendix A seems to be out of context here. The information in Appendix is valuable for a problem statement draft but needs to find the appropriate place to refer it. 

   Handover often requires authentication and authorization for
   acquisition or modification of resources assigned to a mobile and the
   authorization needs interaction with a central authority in a domain.
   In many cases an authorization procedure during a handover procedure
   follows an authentication procedure that also requires interaction
   with a central authority in a domain.  The delay introduced due to
   such an authentication and authorization procedure adds to the
   handover latency and consequently affects the ongoing multimedia

   SD> Why only ?multimedia? sessions? 

   sessions [MQ7].  The authentication and authorization procedure may
   include EAP authentication [RFC3748] where an AAA server may be
   involved in EAP messaging during the handover. 

 SD> I assume the draft is about using EAP. So it should not use the term ?may? in the above sentence. 

 Depending upon the
   type of architecture, in some cases the AAA signals traverse all the
   way to the AAA server in the home domain of the mobile as well before
   the network service is granted to the mobile in the new network.

   Real-time communication and interactive traffic such as VoIP is very
   sensitive to the delay.  Thus it is desirable that interactions
   between the mobile and AAA servers must be avoided or be reduced

Ohba (Editor)            Expires August 25, 2008                [Page 3]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   during the handover.

   This draft discusses EAP pre-authentication problems in details where
   EAP pre-authentication is defined as the utilization of EAP to pre-
   establish EAP keying material on an authenticator prior to arrival of
   the peer at the access network served by that authenticator.

2.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

3.  Problem Statement

   Basic mechanism of handover is a three-step procedure involving i)
   discovery of potential points of attachment and their authenticators,

   SD> ?target? may be better than ?potential? above 

   ii) network selection procedure to determine the appropriate
   candidate network point of attachment and iii) handover or setting up
   of L2 and L3 connectivity to the target network point of attachment.
   Currently, security mechanisms for authentication and authorization
   are performed as part of the third step directly with the target
   network.  For example, in basic IEEE 802.11 based wireless networks,
   the security mechanism involves performing a new IEEE 802.1X message
   exchange with the authenticator in the target AP (Access Point) to
   initiate an EAP exchange to the authentication server [WPA].
   Following a successful authentication, a secure association protocol
   named four-way handshake with the wireless station derives a new set
   of the session keys for use in data communications.  Unless PMK
   (Pairwise Master Key) is not cached in the target AP, this mechanism
   is same as the initial setup to the AP with no particular
   optimizations for the handover scenario.  The handover latency
   introduced by this security mechanism has proven to be larger than
   what is acceptable for some handover scenarios [MQ7]. 

   SD> May be appropriate to say that ?The handover latency
   introduced by this security mechanism has proven to be larger than
   that is acceptable for real time applications as described in [MQ7].?

   Hence,
   improvement in the handover latency performance due to security
   procedures is a necessary objective for such scenarios.

   For example, if a mobile only needs 250 ms for "fast reconnect" then
   if it is moving at 60 mph (87 feet/second), then the mobile will have
   moved roughly 22 feet during the EAP authentication process.  This is
   larger than the average coverage overlap of a wireless LAN (WLAN).

   SD> The above paragraph seems to be not relevant here. The roaming problem within 802.11 networks is addressed by 802.11 task groups. Is the above example related to between wi-fi networks or between wi-fi and other networks?

   There is relevant work undertaken by various standards organizations.
   But these efforts are scoped to a specific access technology.  IEEE
   802.11f has defined context transfer between APs.  IEEE 802.11i

Ohba (Editor)            Expires August 25, 2008                [Page 4]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   defines a pre-authentication mechanism for use in 802.11 variant
   wireless networks.  

   SD> What does the ?variant? mean above?
 
   This mechanism allows mobile devices to pre-
   authenticate using EAP to one or more candidate authenticators over
   the wired medium, by way of the serving authenticator.  IEEE 802.11r
   [802.11r] defines Fast BSS transition mechanisms involving a
   definition of key management hierarchy and setup of session keys
   before the re-association to the target AP.  These mechanisms, as
   indicated before, are defined for IEEE 802.11 technologies and are
   only applicable within a certain access domain and fall short when it
   comes to inter-access technology handovers.  They also require L2
   (e.g., Ethernet) connectivity for transfer of encapsulated signaling

    SD> What ? encapsulating signaling?? 

   to a candidate or the target AP.  Especially, a solution is needed to
   enable EAP pre-authentication in IEEE 802.11 to work even if the
   station and AP are not members of the same VLAN.

   As various flavors of wireless technologies are increasingly
   available, there is a growing demand for seamless inter-access
   technology mobility and handovers.  This is particularly beneficial
   in the presence of high bandwidth wireless technologies (e.g., IEEE
   802.11a/b/g) with only hotspot like coverages while the overlay
   licensed wireless/cellular coverages are expensive and relatively
   lower bandwidth.  There is a strong motivation to allow seamless
   inter-technology handovers for all kinds of data communications.
   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. 

   SD> Some parts of the above paragraph are already mentioned earlier and can be removed. 

   Solutions for inter-authenticator mobility security optimizations can
   be largely seen as security context transfer, handover keying or EAP
   pre-authentication.  Security context transfer involves transfer of
   reusable key context in the new point of attachment.  However, the
   recent AAA key management requirement [RFC4962] does not recommend
   horizontal context transfer of reusable key context because of domino
   effect in which a compromise of an authenticator will lead to a
   compromise of another authenticator.  

   SD> Reference on domino effect may be good. 

   Handover keying and re-
   authentication [I-D.ietf-hokey-reauth-ps] uses an existing EAP-
   generated key for deriving a re-authentication key to be distributed
   to a HOKEY server in a visited domain in order to reduce the handover
   delay, which eliminates the need for running a full EAP
   authentication with the EAP server in the home domain for handovers
   within the visited domain.  On the other hand, there are certain
   cases where an EAP-generated key does not exist or is not usable for
   handover keying at the time of handover and an EAP run is not
   avoidable to generate a key for the candidate authenticator.  One
   case is an inter-domain handover without any trust relationship
   between domains.  Another case is an intra-domain handover where the
   access networks and/or the AAA infrastructure in the visited domain
   do not support handover keying and low-latency re-authentication.

Ohba (Editor)            Expires August 25, 2008                [Page 5]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   EAP pre-authentication discussed in this document is mainly to deal
   with an environment where the mobile device and candidate
   authenticators are not in the same subnet or of the same link-layer
   technology.  

   SD> The above assumption needs to be consistent across the draft. Some earlier texts need to be reworded accordingly.
   
   Such use of EAP pre-authentication would enable the
   mobile device to authenticate and setup keys prior to connecting to
   one of the candidate authenticators.

   This framework has general applicability to various deployment
   scenarios in which proactive signaling can take effect.  In other
   words, applicability of EAP pre-authentication is limited to the
   scenarios where candidate authenticators can be easily discovered, an
   accurate prediction of movement can be easily made.  

   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 or where there is
   sufficient radio-coverage overlap among different technologies. 

   SD> The above paragraph is not very clear. Is it the case of using multiple radio interfaces? If the overlapping radio coverage is not there how the seamless handover would be possible? Does EAP pre-authentication assume that it is only applicable where overlapping coverage is not available?   

   Note that EAP pre-authentication problem for intra-technology intra-
   subnet handover could be solved by each link-layer and is thus out of
   the scope of this document while a general solution developed at IETF
   can be used for intra-technology and intra-subnet scenarios as well.

   In EAP pre-authentication, AAA authentication and authorization for a
   candidate authenticator is performed while ongoing data
   communications are in progress via the serving network.  The goal of
   EAP pre-authentication is to avoid AAA signaling for EAP when or soon
   after the device moves.  There are several AAA issues related to EAP
   pre-authentication.  The pre-authentication AAA issues are described
   in Section 6.

   Figure 1 shows the functional elements that are related to EAP pre-
   authentication.

     +------+         +-------------+     +------+
     |Mobile|---------|   Serving   |    /        \
     | Node |         |Authenticator|---/          \
     +------+         +-------------+  /            \
        .                             /              \    +----------+
        . Move                       +    Internet    +---|AAA Server|
        .                             \              /    +----------+
        v             +-------------+  \            /
                      |  Candidate  |---\          /
                      |Authenticator|    \        /
                      +-------------+     +------+

           Figure 1: EAP Pre-authentication Functional Elements 

SD> What is the ?Internet? bubble in Figure 1? It may not be a good example. Instead it may show the core network. Normally AAA servers are not just connected to the Internet like this? 

   A mobile node is attached to the serving access network.  Before the

Ohba (Editor)            Expires August 25, 2008                [Page 6]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   mobile node performs handover from the serving access network to a
   candidate access network, it performs EAP pre-authentication with a
   candidate authenticator, an authenticator in the candidate access
   network, via the serving access network.  The mobile node may perform
   EAP pre-authentication with one or more candidate authenticators.  It
   is assumed that each authenticator has an IP address when
   authenticators are on different IP links.  

   SD> Does it mean that authenticators will not have an IP address when they are on the same IP link. Does it mean to say that authenticators have separate IP address when they are on different IP links?

   It is assumed that there
   is at least one candidate authenticator in each candidate access
   network while the serving access network may or may not have a
   serving authenticator.  

  SD> Is it true that serving network may not have a serving authenticator? 
  If it is true, how come in the first case it enters into the network? Is serving network is an open network? If so, is it a valid handover scenario and is EAP pre-authentication applicable there? Also use case scenario does not cover it. 

  The serving and candidate access networks may
   use different link-layer technologies.

   Each authenticator has the functionality of EAP authenticator which
   is either standalone EAP authenticator or pass-through EAP
   authenticator.  When an authenticator acts as a standalone EAP
   authenticator, it also has the functionality of EAP server.  On the
   other hand, when an authenticator acts as a pass-through EAP
   authenticator, it communicates with EAP server typically implemented
   on a AAA server using a AAA protocol such as RADIUS and Diameter.

   SD> May be appropriate to say that ?using AAA transport protocol such as Radius and Diameter?

   If the candidate authenticator is of an existing link-layer

   SD> What is the meaning of ?existing? here? It is better to delete it. 

   technology that uses an MSK (Master Session Key)
   [I-D.ietf-eap-keying] for generating lower-layer ciphering keys, EAP
   pre-authentication is used for proactively generating the MSK for the
   candidate authenticator.

4.  Usage Scenarios

   There are two scenarios on how EAP pre-authentication signaling can
   happen among a mobile node, a serving authenticator, a candidate
   authenticator and a AAA server, depending on how the serving
   authenticator is involved in the EAP pre-authentication signaling.
   No security association between the serving authenticator and the
   candidate authenticator is required for both pre-authentication
   scenarios (see Section 7 for more detailed discussion).

4.1.  Direct Pre-authentication

   Direct pre-authentication signaling is shown in Figure 2.

Ohba (Editor)            Expires August 25, 2008                [Page 7]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

    Mobile             Serving              Candidate             AAA
     Node           Authenticator         Authenticator          Server
     (MN)                (SA)                 (CA)
      |                   |                    |                   |
      |                   |                    |                   |
      |           MN-CA Signaling (L3)         |       AAA         |
      |<------------------+------------------->|<----------------->|
      |                   |                    |                   |
      |                   |                    |                   |

                    Figure 2: Direct Pre-authentication

  SD> Does the MN-CA Signaling always needs to happen via L3? It may be worth mentioning the underlying assumption here. 
  
   In this type of pre-authentication, the serving authenticator
   forwards the EAP pre-authentication traffic as it would any other
   data traffic or there may be no serving authenticator at all in the
   serving access network.

   [I-D.ietf-pana-preauth] is identified as a protocol to realize direct
   pre-authentication.

4.2.  Indirect Pre-authentication

   Indirect pre-authentication signaling is shown in Figure 3.

    Mobile             Serving              Candidate             AAA
     Node            Authenticator        Authenticator          Server
     (MN)                (SA)                 (CA)
      |                   |                    |                   |
      |                   |                    |                   |
      |   MN-SA Signaling |   SA-CA Signaling  |       AAA         |
      |    (L2 or L3)     |        (L3)        |                   |
      |<----------------->|<------------------>|<----------------->|
      |                   |                    |                   |
      |                   |                    |                   |

                   Figure 3: Indirect Pre-authentication

   With indirect pre-authentication, the serving authenticator is
   involved in EAP pre-authentication signaling.  Indirect pre-
   authentication is needed if the MN cannot discover the CA's IP
   address or if IP communication is not allowed between the candidate
   authenticator and unauthorized nodes for security reasons.

   SD> IP communication may not even be possible even if mobile node is authorized, say, because of topology. 

   Indirect pre-authentication signaling is spliced into mobile node to
   serving authenticator signaling (MN-SA signaling) and serving
   authenticator to candidate authenticator signaling (SA-CA signaling).

   SA-CA signaling is performed over L3.

Ohba (Editor)            Expires August 25, 2008                [Page 8]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   MN-SA signaling is performed over L2 or L3.

   The role of the serving authenticator in indirect pre-authentication
   is to forward EAP pre-authentication signaling between the mobile
   node and the candidate authenticator and not to act as an EAP
   authenticator, while it acts as an EAP authenticator for normal
   authentication signaling.  This is illustrated in Figure 4.

        Mobile                   Serving                   Candidate
         Node                  Authenticator             Authenticator
         (MN)                     (SA)                       (CA)

     +-----------+                                       +-----------+
     |           |<- - - - - - - - - - - - - - - - - - ->|           |
     | EAP Peer  |    +-----------------------------+    | EAP Auth- |
     |           |    |Pre-authentication Forwarding|    | enticator |
     +-----------+    +-----------+-----+-----------+    +-----------+
     | MN-SA     |    | MN-SA     |     | SA-CA     |    | SA-CA     |
     | Signaling |<-->| Signaling |     | Signaling |<-->| Signaling |
     | Layer     |    | Layer     |     | Layer     |    | Layer     |
     +-----------+    +-----------+     +-----------+    +-----------+

           Figure 4: Indirect Pre-authentication Layering Model

5.  Architectural Considerations

   There are two architectural issues relating to pre-authentication,
   i.e., authenticator discovery and context binding.

SD> Is context binding an architectural issue or a general issue? Location of target authenticator may have some architectural implications. How about transport? 

5.1.  Authenticator Discovery

   In general, pre-authentication requires an address of a candidate
   authenticator to be discovered either by a mobile node or by a
   serving authenticator prior to handover.  An authenticator discovery
   protocol is typically defined as a separated protocol from a pre-
   authentication protocol.  

  SD> Replace ?separated? by ?separate? 

   When pre-authentication is used for inter-
   technology or inter-subnet handover, a candidate authenticator needs
   to have a global IP address and a mechanism for discovering the
   candidate authenticators IP address is needed. 

   SD> Does it always require to have a global IP address even if serving and candidate authenticators are  within one operator?s domain 

   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. 

  An authenticator discovery mechanism requires a database on the

Ohba (Editor)            Expires August 25, 2008                [Page 9]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008 

neighboring network information.  Provisioning of a server with such
   a database is another issue.

  SD> The above is a solution and does it require to have in the problem statement document? 

5.2.  Context Binding

   When a candidate authenticator uses different EAP transport protocols
   for normal authentication and pre-authentication, a mechanisms 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 mobile node and the candidate
   authenticator.  

   SD> Is it true that this context binding needs to happen after the handover? 
   If so it may be appropriate to reflect that in the last sentence of the above paragraph. 

   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
   mobile node and the candidate authenticator.

   There are two possible approaches to address the context binding
   issue.  The first approach is based on communicating the lower-layer
   context as opaque data via pre-authentication signaling and perform
   the link-layer specific secure association procedure after handover.
   The second approach is based on running EAP over the link-layer of
   the candidate authenticator after handover using short-term
   credentials generated via pre-authentication, followed by the link-
   layer specific secure association procedure.  In this case, the
   short-term credentials are shared between the mobile node and the
   candidate authenticator, and hence the EAP server for the post-
   handover EAP resides in the candidate authenticator.  
   
 SD> Last part of the above sentence is not clear. 

   In both
   approaches, the binding needs to be securely made between the peer
   and the candidate authenticator using a security association
   established via pre-authentication.

6.  AAA Issues

   Most of the AAA documentations today do not distinguish between a
   full authentication and a pre-authentication and this creates a set
   of open issues:

   Pre-authentication authorization:   Many users may not be allowed to
      have more than one logon session at the time.  This means, 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 full authentication request and a pre-
      authentication request. 

  SD> The assumption here seems to me that mobile node has performed the network access authentication in the first place. Therefore, the earlier statement saying that serving network may or may not have an authenticator is not correct. Pl. refer to earlier comment on this as well. 

Ohba (Editor)            Expires August 25, 2008               [Page 10]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   Pre-authentication life time:   Currently AAA protocols define
      attributes (AVPs) carrying life time information for a full
      authentication session.  Even when a user profile and the AAA
      server support pre-authentication function, after the pre-
      authentication of a peer is complete, since the pre-authentication
      may be accompanied with a pre-authorization, the pre-
      authentication is typically valid only for a short amount of time.

      SD> The above sentence may need to be rephrased. 

      It is currently not possible for a AAA server to indicate to the
      AAA client or a peer what the life time of the pre- authenticated
      session is.  

     SD> May be appropriate to add ?unless extended?

      In other words, it is not clear to the peer or the
      NAS, when the pre-authentication will expire.

   Pre-authentication retries:   It is typically expected that shortly
      following the pre-authentication process, the mobile entity moves
      to the new point of attachment and converts the pre-authentication
      state to a full authentication state (the procedure for which is
      not the topic of this particular subsection).  However, if the
      peer has yet not moved to the new location and realizes that the
      pre-authentication is expiring, it may perform another pre-
      authentication.  In order to avoid unlimited number of pre-
      authentication tries, it is quite possible that the network policy
      sets a limit on the maximum number of pre-authentication attempts.

    SD> The last part of the above paragraph seems to provide a solution rather than issue while all other bullet point describe the issue only. Needs to be uniform across the draft. 

   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.

   Session Resumption:   In case the peer ping pongs between a network
      N1 with which it has a full 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 life time and keying
      material caching needs to be dealt with. 

   Multiple candidate authenticators:   There may be situations where
      the mobile node may need to make a selection between a number of
      candidate attachment points.  In such cases, it is desirable for
      the mobile to perform pre-authentication with multiple
      authenticators.  In such cases the AAA server may need to be aware
      of the situation.

   Roaming support:   In case the pre-authentication is being performed
      through a serving network that is foreign to the MN's home AAA
      server, the AAA server needs to obtain the information about the
      serving network in addition to the information about the candidate
      network, so that the AAA server can make authorization decisions

     SD> Is not correct that this information will be available to the home AAA when MN first attaches a foreign network in the first place? 

Ohba (Editor)            Expires August 25, 2008               [Page 11]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

      accordingly, e.g., depending on the authorization policy, the home
      AAA server may not allow pre-authentication via a particular
      serving network.

   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, heterogeneous handovers may require a change of the
      MN identifier as part of the handover.  Investigation on the best
      type of identifiers for MNs that support multiple access
      technologies is required.

   Network controlled handovers:   It is becoming quite common for the
      network operators to maintain the control over the handovers for
      various reasons including load balancing and performance.  Hence
      the network may need to direct the MN to perform pre-
      authentication to a set of candidate authenticators in an
      anticipation for a handover.  The AAA protocol extensions for
      carrying out such procedures need to be provided. 

  SD> Not clear how the above is related to AAA protocol extensions. This could be handover policy and may be obtained via different means. 

7.  Security Considerations

   Since pre-authentication described in this document needs to work
   across multiple authenticators, any solution for this problem needs
   considerations on the following security threats.

   First, a possible resource consumption denial of service attack where
   an attacker that is not on the same IP link as the mobile node or the
   candidate authenticator may send unprotected pre-authentication
   messages to the mobile node or the candidate authenticator to let the
   legitimate mobile node and candidate authenticator spend their
   computational and bandwidth resources.  This attack is possible for
   both direct and indirect pre-authentication scenarios.  To mitigate
   this attack, the candidate network or authenticator should apply non-
   cryptograhpic 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
   authenticator side.

   SD> Again the last part provides a solution not an issue?

   Second, consideration for the Channel Binding problem described in
   [I-D.ietf-eap-keying] 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, when

Ohba (Editor)            Expires August 25, 2008               [Page 12]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   normal authentication uses link-layer EAP transport, 

   SD> The statement ?when normal authentication uses link-layer EAP transport,? 
may be redundant. 

  it would be
   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.

8.  IANA Considerations

   This document has no actions for IANA.

9.  Acknowledgments

   The authors would like to thank Bernard Aboba, Jari Arkko, Ajay
   Rajkumar and Maryna Komarova for their valuable input.

10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4962]  Housley, R. and B. Aboba, "Guidance for Authentication,
              Authorization, and Accounting (AAA) Key Management",
              BCP 132, RFC 4962, July 2007.

   [I-D.ietf-eap-keying]
              Aboba, B., Simon, D., and P. Eronen, "Extensible
              Authentication Protocol (EAP) Key Management Framework",
              draft-ietf-eap-keying-22 (work in progress),
              November 2007.

10.2.  Informative References

   [I-D.ietf-hokey-reauth-ps]
              Clancy, C., Nakhjiri, M., Narayanan, V., and L. Dondeti,
              "Handover Key Management and Re-authentication Problem
              Statement", draft-ietf-hokey-reauth-ps-08 (work in
              progress), February 2008.

   [I-D.aboba-radext-wlan]

Ohba (Editor)            Expires August 25, 2008               [Page 13]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

              Malinen, J. and B. Aboba, "RADIUS Attributes for IEEE 802
              Networks", draft-aboba-radext-wlan-06 (work in progress),
              July 2007.

   [I-D.ietf-pana-preauth]
              Ohba, Y., "Pre-authentication Support for PANA",
              draft-ietf-pana-preauth-02 (work in progress),
              November 2007.

   [802.21]   IEEE, "Draft Standard for Local and Metropolitan Area
              Networks: Media Independent Handover Services", LAN MAN
              Standards Committee of the IEEE Computer Society 802.21
              D9.0 2008.

   [802.11r]  IEEE, "Information technology - Telecommunications and
              information exchange between systems - Local and
              metropolitan area networks - Specific requirements - Part
              11: Wireless LAN Medium Access Control (MAC) and Physical
              Layer (PHY) specifications - Amendment 2: Fast BSS
              Transition", LAN MAN Standards Committee of the IEEE
              Computer Society 802.11r D9.0 2008.

   [ITU]      ITU-T, "General Characteristics of International Telephone
              Connections and International Telephone Circuits: One-Way
              Transmission Time", ITU-T Recommendation G.114 1998.

   [ETSI]     ETSI, "Telecommunications and Internet Protocol
              Harmonization Over Networks (TIPHON) Release 3: End-to-end
              Quality of Service in TIPHON systems; Part 1: General
              aspects of Quality of Service.", ETSI TR 101 329-6 V2.1.1.

   [WPA]      The Wi-Fi Alliance, "WPA (Wi-Fi Protected Access)", Wi-
              Fi WPA v3.1, 2004.

   [MQ7]      Lopez, R., Dutta, A., Ohba, Y., Schulzrinne, H., and A.
              Skarmeta, "Network-layer Assisted Mechanism to Optimize
              Authentication Delay During Handoff in 802.11 Networks",
              ACM Mobiquitous 2007.

Appendix A.  Performance Requirements

   In order to provide the desirable quality of service for interactive
   VoIP and streaming traffic during handoff, one needs to limit the
   value of end-to-end delay, jitter and packet loss to a certain
   threshold level.  ITU-T and ITU-R standards define the acceptable
   values for these parameters.  For example for one-way delay, ITU-T
   G.114 [ITU] recommends 150 ms as the upper limit for most of the

Ohba (Editor)            Expires August 25, 2008               [Page 14]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

   applications, and 400 ms as generally unacceptable delay.  One way
   delay tolerance for video conferencing is in the range of 200 to 300
   ms.  Also if an out-of-order packet is received after a certain
   threshold, it is considered lost.  The performance requirement will
   vary based on the type of application and its characteristics such as
   delay tolerance and loss tolerance limit.  Interactive traffic such
   as VoIP and streaming traffic will have different tolerance for delay
   and packet loss.  For example, according to ETSI TR 101 [ETSI] a
   normal voice conversation can tolerate up to 2% packet loss.
   Similarly there are other factors such as Transmission Rating Factor
   (R) standardized within ITU-T G.107, End to End delay (one way mouth-
   to-ear) and call blocking ratio that determine the QoS metrics.  An R
   value of 50 is considered to be poor and a value of 90 can be
   considered as the best that provides most user satisfaction.  As an
   example, a class B QoS which is equivalent to cellular telephony has
   a R factor that is greater than 70, E2E delay of less than 150 ms and
   call blocking ratio which is less than or equal to 0.15.  Class A QoS
   that is the highest and is equivalent to fixed phone quality has an R
   value that is more than 80 and an end-to-end delay that is less than
   100 ms.  Similarly, 3GPP TS23.107 defines 4 application classes:
   conversational, streaming, interactive and background each with
   different set of end-to-end delay and QoS requirement.  The streaming
   class has the tolerable packet (SDU) error rates ranging from 0.1 to
   0.00001 and the transfer delay of less than 300ms.  In short, the
   delay and packet loss tolerance value will depend upon the type of
   application and different standard bodies and vendors provide
   different specification for each type of application and thus any
   optimized handoff mechanism will need to take these values into
   consideration.

   It is desirable to support a heterogeneous handover that is agnostic
   to link-layer technologies in an optimized and secure fashion without
   incurring unreasonable complexity while providing seamless handover
   experience to the user.  As a mobile goes through a handover process,
   it is subjected to handover delay because of the rebinding of
   properties at several layers of the protocol stack, such as layer 2,
   layer 3 and application layer.  There are several common properties
   that contribute to the re-establishment or modification of these
   layers during handover.  These properties can mostly be attributed to
   things such as access characteristics (e.g., bandwidth, channel
   characteristics, channel scan, access point association), physical-
   layer access methods (e.g., CDMA, TDMA), MAC layer protocols (e.g.,
   CSMA/CA), configuration of layer 3 parameters such as IP address
   acquisition, re-authentication, re-authorization, rebinding of
   security association at all layers, binding update etc.  Although
   each of the components during the handover process that contributes
   to the handover delay needs to be optimized, we focus our discussion
   on optimizing the delay due to authentication and authorization.

Ohba (Editor)            Expires August 25, 2008               [Page 15]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

Author's Address

   Yoshihiro Ohba
   Toshiba America Research, Inc.
   1 Telcordia Drive
   Piscataway, NJ  08854
   USA

   Phone: +1 732 699 5365
   Email: [email-masked]

Ohba (Editor)            Expires August 25, 2008               [Page 16]

Internet-Draft  EAP Pre-authentication Problem Statement   February 2008

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Ohba (Editor)            Expires August 25, 2008               [Page 17]

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 8 Apr 2008 14:40:12 -0400

Subir,

Thank you very much for your detailed review.  Please see my comments below.

On Tue, Apr 08, 2008 at 02:06:00AM -0400, Subir Das wrote:
> 'SD'. The draft describes the problem nicely with issues but it requires 
> a good amount

>    SD> Instead of ?on an authenticator? it may be appropriate to say ?on a target authenticator?. Also ?use? may be better than ?utilization? 

Agreed.

>    node? is used in other places. I think it should be ?mobile node? everywhere.

We will fix the terminology problem.

>    SD> It is not clear from the above paragraph whether the mobile node is performing a handover using a single radio interface or always active dual radio interface. The performance requirement in…

Charles has a similar comment on Appendix A.  We will work on
shortening Appendix A and move the content to the main body, perhaps
in this section.

>    SD> Why only ?multimedia? sessions? 

How about s/multimedia/application/?

>  SD> I assume the draft is about using EAP. So it should not use the term ?may? in the above sentence. 

I agree not to use 'may' here.

>    SD> ?target? may be better than ?potential? above 

or 'candidate'.

>    that is acceptable for real time applications as described in [MQ7].?

OK.

>    SD> The above paragraph seems to be not relevant here. The roaming problem within 802.11 networks is addressed by 802.11 task groups. Is the above example related to between wi-fi networks or be…

This is for handovers between wi-fi networks.  I think we can remove
this paragraph.

>    SD> What does the ?variant? mean above?

Since 802.11i pre-authentication is already part of IEEE Std 802.11 - 2007, 
we can revise the sentence to:

"IEEE 802.11 [802.11] defines a pre-authentication mechanism for use in
802.11 wireless networks."

>     SD> What ? encapsulating signaling?? 

We can revise the sentence to:

"They also require L2 (e.g., Ethernet) connectivity for transfer of key
management signaling ..."

>    SD> Some parts of the above paragraph are already mentioned earlier and can be removed. 

OK, we will work on that.

>    SD> Reference on domino effect may be good. 

It is in [RFC4962].

>    SD> The above assumption needs to be consistent across the draft. Some earlier texts need to be reworded accordingly.

OK.

>    SD> The above paragraph is not very clear. Is it the case of using multiple radio interfaces? If the overlapping radio coverage is not there how the seamless handover would be possible? Does EAP…

I think we should remove "or where there is sufficient radio-coverage
overlap among different technologies" as some overlapping coverage
would be still needed for seamless handover.

>    Figure 1 shows the functional elements that are related to EAP pre-

Charles have the same comment.  We will revise Figure 1.

>    SD> Does it mean that authenticators will not have an IP address when they are on the same IP link. Does it mean to say that authenticators have separate IP address when they are on different IP…

It means that each authenticator has an IP address.  We will revise
the sentence accordingly.

>   If it is true, how come in the first case it enters into the network? Is serving network is an open network? If so, is it a valid handover scenario and is EAP pre-authentication applicable there?…

The serving network could be an open access L2 network and may be
using http authentication.  Also there may be no roaming agreement
between the serving and target networks.  EAP pre-authentication is
applicable to such scenarios.

>    SD> May be appropriate to say that ?using AAA transport protocol such as Radius and Diameter?

OK.

>    SD> What is the meaning of ?existing? here? It is better to delete it. 

OK.

>       |           MN-CA Signaling (L3)         |       AAA         |

The assumption is that there is no direct L2 connectivity between MN
and CA.  We can add the assumption.

>       |   MN-SA Signaling |   SA-CA Signaling  |       AAA         |

We can add the topology reason here.

> SD> Is context binding an architectural issue or a general issue? Location of target authenticator may have some architectural implications. How about transport? 

The context binding issue is specific to L3 pre-authentication, and
not a general issue.  Transport (direct or indirect) does not have
architectural implications in terms of context binding.

>   SD> Replace ?separated? by ?separate? 

OK.

>    SD> Does it always require to have a global IP address even if serving and candidate authenticators are  within one operator?s domain 

A global address may not be needed for intra-domain handover.  We can
revise the text to:

"
 When pre-authentication is used for inter-technology or inter-subnet
 handover, a candidate authenticator needs to have an IP address and a
 mechanism for discovering the candidate authenticators IP address is
 needed.  For inter-domain handover, the IP address of a candidate
 authenticator needs to be global unique.
"

>   SD> The above is a solution and does it require to have in the problem statement document? 

The above paragraph was added based on Ajay Rajkumar's review.  I
think this is a good to have, while I agree with you that it is not
mandatory to have in the problem statement document.

>    If so it may be appropriate to reflect that in the last sentence of the above paragraph. 

Context binding can happen before handover.

>  SD> Last part of the above sentence is not clear. 

The last part means that post-handover EAP terminates between MN and
CA, and does not require AAA signaling.

>   SD> The assumption here seems to me that mobile node has performed the network access authentication in the first place. Therefore, the earlier statement saying that serving network may or may no…

I don't think this contradicts with the earlier statement.  If there
is no authenticator in the serving network, then the mobile node will
be able to perform pre-authentication to the target network even if
the AAA server does not allow more than one logon session.  In other
words, there is no logon session before pre-authentication in this
case.

>       SD> The above sentence may need to be rephrased. 

OK.

>      SD> May be appropriate to add ?unless extended?

OK.

>     SD> The last part of the above paragraph seems to provide a solution rather than issue while all other bullet point describe the issue only. Needs to be uniform across the draft. 

OK.

>      SD> Is not correct that this information will be available to the home AAA when MN first attaches a foreign network in the first place? 

This is a good point.  I think you are right.  Perhaps we can remove
this bullet.

>   SD> Not clear how the above is related to AAA protocol extensions. This could be handover policy and may be obtained via different means. 

I agree that network controlled handover is more general than
pre-authentication.  We can remove this bullet.

>    SD> Again the last part provides a solution not an issue?

This part is describing a guidance (solution) to mitigate an attack.
As far as I understand, Security Considerations section can contain a
guidance.

>    SD> The statement ?when normal authentication uses link-layer EAP transport,? 

I agree, we can remove the statement.

>    authentication trigger to the peer.

Thanks,
Yoshihiro Ohba

---

From: Subir Das <[email-masked]>
Date: Thu, 10 Apr 2008 01:55:50 -0400

Yoshi,
Thanks for addressing the comments. Few answers inline

regards,
_Subir

> management signaling ..."
SD> Much better.
> would be still needed for seamless handover.
SD> Good.
> the sentence accordingly.
SD> Good.
> applicable to such scenarios.
SD> This scenario is possible and the target network may require EAP
authentication and can be done
via pre-authentication but I was thinking how much it is relevant in
terms of seamless handover.
For example, if the two networks does not have roaming agreement, can a
seamless handover
possible in real case? Also if it is a managed network, is it not fair
to assume that both serving and
target networks will have EAP authentication? Just a point to think.
> and CA.  We can add the assumption.
SD> Good.
> We can add the topology reason here.
SD> Good.
> architectural implications in terms of context binding. 
SD> I did not mean to say that transport has architectural relationship
with context binding. May be I
should have been a little bit clear. Three questions: i) If context
binding is a general issue, does it fit under
architectural issue section? ii) Does transport of pre-auth parameters
has any architectural impacts?, and
iii) Does location of target authenticator has any architectural impacts?

>  authenticator needs to be global unique.
SD> May we should say "For both intra-domain and inter-domain handover,
the IP address of a candidate
authenticator must be reachable by the mobile node that is performing
the pre-authntication " something
like that...
> mandatory to have in the problem statement document.
SD> Ok. May be we can say in preamble, if 802.21-based or similar
mechanism is used.....
> Context binding can happen before handover.
SD> Does this mean it can happen after handover too. If so, may be it
should clarify both options.
> CA, and does not require AAA signaling.

SD> Does this mean the target network does not have a AAA server? If
that is the case, it may be good
to clarify it.
> words, there is no logon session before pre-authentication in this

SD> Does that mean if the serving network does not have an authenticator
that interacts with AAA,
multiple logons is a non-issue? If that is the case and we allow such a
scenario (e..g, serving network
does not have an authenticator), this AAA issue is not a general issue.
> This is a good point.  I think you are right.  Perhaps we can remove
SD> Yes, that would be better.
> pre-authentication.  We can remove this bullet.
SD> Good.
> As far as I understand, Security Considerations section can contain a
SD> Ok.
> I agree, we can remove the statement.
SD> Good

---

From: Yoshihiro Ohba <[email-masked]>
Date: Sun, 20 Apr 2008 00:55:28 -0400

Subir,

Please see my resonse below.

On Thu, Apr 10, 2008 at 01:55:50AM -0400, Subir Das wrote:

(snip)

> target networks will have EAP authentication? Just a point to think.

This is a very good point.  I would say it depends on solutions.  For
example, a solution such as draft-irtf-mobopts-mpa-framework that does
not require roaming agreement.  On the other hand, other solutions
that use interworking gateways will require roaming agreement.  We can
add some text about this for fair analysis.

(snip)

> iii) Does location of target authenticator has any architectural impacts?

For i), it is specific to L3 pre-auth as I mentioned, so it fits under
this section.  For ii), there is no architectural impact.  Once
context binding issue is resolved at the architecture level, then
there can be several choices on transport.  Designing a new transport
can be one choice, reusing an existing transport can be another.  For
iii), as long as authenticator is defined as a logical functional
element as defined in RFC 3748, the location of target authenticator
does not have an architectural impact at logical level.  This problem
statement is dealing with architectural issues at that level.
However, when we start to talking about how authenticators are mapped
to physical elements such as BS/AP and access controllers, then there
can be an architectural impact at physical level, but I believe that
architectural issues at that level can be better addressed in SDO that
defines a solution for the L3 preauth problem.

OK.

> SD> Ok. May be we can say in preamble, if 802.21-based or similar

We will add such a preamble.

> should clarify both options.

OK, we will add clarification text on this.

> that is the case, it may be good

The target network has access to a AAA server, but the target
authenticator does not need to communicate with the AAA server for
authenticating the MN after handover.  That is the whole point of
pre-authentication.

> does not have an authenticator), this AAA issue is not a general issue.

Multiple logons is a non-issue if MN uses different subscriptons for
the serving and target networks.  If MN uses the same subscription for
the serving and target networks, multiple logons can be an issue
regardless of whether there is a serving authenticator or not.  
We can add clarification text about this.

Thanks,
Yoshihiro Ohba