AAA                                                    Stefano M. Faccin
INTERNET-DRAFT                                                 Franck Le
Date: April 2003                                         Basavaraj Patil
Expires: October 2003                                 Charles E. Perkins
                                                   Nokia Research Center

                                                          Francis Dupont
                                                           ENST Bretagne

                                            Maryline Laurent-Maknavicius
                                                        Julien Bournelle
                                                                INT Evry




 Mobile IPv6 Authentication, Authorization, and Accounting Requirements
                <draft-le-aaa-mipv6-requirements-02.txt>



Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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.


Abstract

   This document describes the motivation why Diameter support for
   Mobile IPv6 is required and needs to be developped. It analyses the
   requirements expressed in RFC 2977 which was written both for MIPv4



Faccin et al.                                                   [Page i]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   and MIPv6; and it finally updates the IPv6 requirements for the AAA
   support for Mobile IPv6 to reflect the latest modifications and
   evolution of the Mobile IP, AAA and other relevant working groups.
















































Faccin et al.                                                  [Page ii]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


                           Table of Contents


Status of This Memo  . . . . . . . . . . . . . . . . . . . . . . . .   i

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   i

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   1

2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . .   3

3. Basic model . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.1. Modifications to basic model . . . . . . . . . . . . . . . .   5
   3.2. AAA Protocol Roaming Requirements  . . . . . . . . . . . . .   6

4. Requirements related to basic IP connectivity . . . . . . . . . .   6

5. AAA for Mobile IP . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.1. Attendant functionnality . . . . . . . . . . . . . . . . . .   7
   5.2. Security associations  . . . . . . . . . . . . . . . . . . .   8
   5.3. Authentication and key distribution mechanisms.  . . . . . .   8
   5.4. Integration of Mobile IP and AAA procedures  . . . . . . . .   9
   5.5. Home agent allocation  . . . . . . . . . . . . . . . . . . .  10

6. Security considerations . . . . . . . . . . . . . . . . . . . . .  10

7. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .  11

8. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12






















Faccin et al.                                                 [Page iii]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


1.  Introduction

   Mobile IP defines a method that allows a Mobile Node to change its
   point of attachment to the Internet with minimal service disruption.
   But Mobile IP in itself does not provide any specific support for
   mobility across different administrative domains, which limits the
   applicability of Mobile IP in a large-scale commercial deployment.

   AAA protocols such as Diameter precisely enable mobile users to roam
   and obtain service in networks that may not necessarily be owned by
   their home service provider. For Mobile IP to be deployed in
   commercial networks, there therefore has to be AAA support for the
   protocol.

   RFC 2977 [1] describes the requirements that have to be supported by
   a AAA service to aid in Mobile IP services; and Diameter extensions
   for Mobile IPv4 [2] have already been specified allowing a MIPv4 node
   to receive services from service providers (home and foreign) and
   allowing the Diameter servers to authenticate, authorize and collect
   accounting information for those MIPv4 nodes.

   Even though MIPv4 and MIPv6 are similar when observed at high level,
   the two protocols are actually quite different when considering the
   support for Inter Domain deployment. Mobile IPv6 e.g. does not have
   the equivalent of a Foreign Agent as defined in Mobile IPv4, and as a
   result does not offer any mechanism by which the visited network can
   authenticate and authorize access to the network. In addition,
   extending the Diameter Mobile IPv4 Application to support Mobile IPv6
   will reduce the flexibility and result in some AAA capability
   exchange issues: it will be difficult to differentiate which AAA
   nodes support only Mobile IPv4, which ones support only Mobile IPv6
   and which ones support both.

   Some Diameter Mobile IPv6 Application will have to be specified to
   allow Mobile IPv6 nodes to receive services from foreign domains.
   Such application will allow:

      *  local network access control: cf section 3

      *  remote network access control: cf section 3

      *  credentials/trusted third party: the AAA server act as trusted
         third party allowing user authentication and key distribution.

      *  MN-Attendant LSA establishment: cf section 3.1

      *  home address allocation




Faccin et al.                                                   [Page 1]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


      *  home agent allocation (cf. 4.5): eventhough Mobile IPv6
         specifies a dynamic home agent assignement procedure, the AAA
         servers allow a secure and efficient alternative method.

      *  transport of messages for MN-HA SA establishment by AAA

      *  key distribution for MN-HA SA establishment (need a higher
         level of trust than for the previous)

      *  transport of MN-HA mobility signaling messages (need the two
         previous items)

   But before designing the solution, this document describes the Mobile
   IPv6 AAA requirements: RFC 2977 [1] describes the requirements for
   both Mobile IPv4 and Mobile IPv6 and this document will therefore be
   taken as the base. But since that time, many changes have happened in
   the IETF, different mechanisms have been defined and many
   modifications have ocurred in the Mobile IP and AAA working Groups;
   this draft will thus update the requirements to reflect those latest
   modifications for the Mobile IPv6/AAA requirements.

   In RFC 2977 [1], after a description of the model, the requirements
   were presented in a progressive fashion:

   -  Requirements based on the general model

   -  Requirements based on providing IP service for mobile nodes

   -  Requirements derived from specific Mobile IP needs

   This document will take the same structure, updating the requirements
   for the IPv6 specific case, and taking into account the latest
   amendments of the working groups.

   Finally, it has to be noted that even though Mobile IPv6 is not an
   RFC yet and still has some open issues, such issues (Mobile node-
   Correspondent nodes security association establishment, use of home
   address option, etc.) do no affect the need for Mobile IPv6 support
   by AAA and do not impact the ability for AAA to support Mobile IPv6.
   The Mobile IPv6 security issues are related to the MN-CN security
   association whereas the AAA support for MIPv6 solves all the MN-HA
   security issues.  The AAA/Mobile IPv6 requirements and solution
   specification can therefore proceed in parallel, while the last
   Mobile IPv6 issues are being solved.







Faccin et al.                                                   [Page 2]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


2.  Terminology

   This document frequently uses the following terms in addition to
   those defined in RFC 2977:

      Home Domain
         A Home Domain is the administrative domain with whom the user
         maintains an account relationship.

      Foreign Domain
         An administrative domain, visited by a Mobile IP client, and
         containing the AAA infrastructure needed to carry out the
         necessary operations enabling network access and Mobile IP
         registrations.

      Attendant
         The attendant is the entity that extracts identification and
         authorization data sent by the client and forwards them to AAAL
         for verification.

      AAAL
         The AAA server in the foreign domain that mediates local access
         to the AAA infrastructure.

      AAAH
         The AAA server in the home domain which is able to authorize
         each of its clients.

      Credential
         Data provided by a client to the AAA server in a message
         authentication code constructed using a secret shared between
         the client and AAAH.

      Local Security Association
         Security association shared between the client and the foreign
         domain. The sharing of such SA gives the foreign domain
         significant local control over the authentication of a roaming
         client: Local Security Association e.g. allows the foreign
         domain to authenticate the user and perform key distribution
         without involvement of any external authority such as the
         client's home domain. LSA can thus allow optimizations in terms
         of signaling load towards the external authorities and delay
         involved in the security procedures.

      Key distribution
         Process or protocol whereby a shared secret becomes available
         to two or more parties for subsequent crytographic use.




Faccin et al.                                                   [Page 3]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
   recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
   described in RFC 2119 [11].





3.  Basic model

   The Basic Model described in RFC 2977 [1] still applies:

      When a client belonging to one administrative domain (called the
      home domain) roams to another administrative domain (called the
      foreign domain) and needs to use the local network resources, an
      attendant in the foreign domain is likely to require that the
      client provides some credentials that can be authenticated before
      access to the resources is permitted.  These credentials may be
      something the foreign domain understands, but in most cases they
      are assigned by, and understood only by the home domain, and may
      be used for setting up secure channels with the mobile node.

      The attendant which often does not have direct access to the data
      needed to complete the transaction will forward the request to the
      local AAA server.

      The local AAAL itself may not have enough information stored
      locally to carry out the verification for the credentials of the
      client. In such cases, the AAAL has to contact other external
      authorities such as the AAAH to verify the client's credentials.

      In many typical cases, the authorization depends only upon secure
      authentication of the client's credentials. And once the
      authorization has been obtained by the local authority, and the
      authority has notified the attendant about the successful
      negotiation, the attendant can provide the requested resources to
      the client.














Faccin et al.                                                   [Page 4]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


                      Local Domain                  Home Domain
                    +--------------+           +----------------------+
                    |   +------+   |           |   +------+           |
                    |   |      |   |           |   |      |           |
                    |   | AAAL |   |           |   | AAAH |           |
                    |   |      +-------------------+      |           |
                    |   +---+--+   |           |   +------+           |
                    |       |      |           |                      |
                    |       |      |           +----------------------+
         +------+   |   +---+--+   |
         |      |   |   |      |   |       C    =  client
         |   C  |- -|- -|   A  |   |       A    =  attendant
         |      |   |   |      |   |       AAAL =  local authority
         +------+   |   +------+   |       AAAH =  home authority
                    |              |
                    +--------------+

                Figure 1: AAA Servers in Home and Local Domains

   Therefore, the Security Association Model and the requirements
   deduced from this model (RFC 2977 [1] section 3) are still valid for
   IPv6.

                                  +------+              +------+
                                  |      |              |      |
                                  | AAAL +--------------+ AAAH |
                                  |      |              |      |
                                  +---+--+              +--+---+
                                      |                    |
                                      |                    |
                                  +---+--+              +--+---+
      C    =  client              |      |              |      |
      A    =  attendant           |   A  |              |  C   |
      AAAL =  local authority     |      |              |      |
      AAAH =  home authority      +------+              +------+

                       Figure 2: Security Associations



3.1.  Modifications to basic model

   A modification to the basic model that is required is the need to
   support and utilize Local Security Associations. LSAs have been
   recently introduced in IETF ([3], [5]). After an initial successful
   authentication of the user through the home domain, LSAs allow the
   local domain to authenticate the user and perform key distribution
   without involvement of any external authority such as the client's



Faccin et al.                                                   [Page 5]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   home domain. LSA can thus allow optimizations in terms of signaling
   load between network domains and delay caused by security procedures
   between network domains: the requests can be processed locally and
   the latency due to the time taken to traverse the wide-area Internet
   that is likely to separate the AAAL and the AAAH can thus be avoided.

   Thus, the following requirement is formulated:

   -  LSA ([3], [5]) SHOULD be supported and utilized by AAA in order to
      support, e.g., user re-registration, user re-authentication, key
      distribution/refreshment, etc.


3.2.  AAA Protocol Roaming Requirements

   The Diameter Mobile IPv6 Application is a new application extension
   to the Diameter Base Protocol [6]: the retransmission algorithms of
   the transport mechanism will therefore rely on the already defined
   ones.

   Except this remark, all the other requirements described in section
   3.1 of RFC 2977 [1] are still valid.


4.  Requirements related to basic IP connectivity

   Since the usages scenarios described in section 4 of RFC 2977 [1] are
   still valid, the two main requirements on AAA for IP connectivity are
   still applicable:

   -  Either AAA server MUST be able to obtain, or to coordinate the
      allocation of, a suitable IP address for the customer, upon
      request by the customer

   -  AAA servers MUST be able to identify the client by some means
      other than its IP address

   And so are the derived ones such as:

   -  Policy in the home domain may dictate that the home agent instead
      of the AAAH manages the allocation of the home IP address for the
      mobile node. AAA servers MUST be able to coordinate the allocation
      of an IP address for the mobile node at least in this way.

   In the Diameter Mobile IPv4 Application, clients use the Network
   Access Identifier (NAI) [7] to identify themselves. In the same way,
   in MIPv6, Mobiles nodes should use the NAI: AAA servers today
   identify clients using NAI, and in addition using NAI allows AAAL to



Faccin et al.                                                   [Page 6]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   easily determine the home domain ("realm") for the client.

   From these reasons, derives the following requirement:

   -  In the Diameter support for MIPv6, mobiles nodes SHOULD use the
      NAI


5.  AAA for Mobile IP

   Since RFC 2977 [1] was written for both MIPv4 and MIPv6 and the
   previous sections mainly describe the general, AAA and functional
   requirements, most of them are still valid for MIPv6.

   This section analyzes the Mobile IPv6 specific requirements and, as
   MIPv6 and MIPv4 are quite different when looking at the architectural
   model(MIPv6 does not e.g. have the equivalent of a Foreign Agent),
   the main differences are described in this section.


5.1.  Attendant functionnality

   As defined in the basic model (section 2), the attendant is
   responsible for authorization and authentication of the user before
   giving him access to the local resources. The attendant receives the
   user's credentials and is in charge of performing the necessary
   functions to verify it (e.g. translating to the appropriate
   protocols) but the attendant is not responsible for the address
   allocation.

   The attendant MAY interact with a DHCP Server, but instead of the
   attendant functionality being the address allocation entity as
   suggested in RFC 2977 [1], it is suggested that the attendant SHOULD
   be some other agent in the network.  Since RFC 2977  [1] was written,
   several new mechanisms have evolved and new ones have been introduced
   in IETF, e.g. new working Groups have been created such as PANA.

   This draft suggest the following requirement for support of Mobile
   IPv6 by AAA:

   -  AAA SHOULD support different network access protocols (e.g. PANA).
      The location of the attendant depends on the specific protocol.
      E.g. in the specific case of PANA, the attendant SHOULD be located
      in the PANA Agent defined in [3] if such agent is present in the
      network.






Faccin et al.                                                   [Page 7]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


5.2.  Security associations

   RFC 2977 [1] requires the AAA servers to be able to perform key
   distributions, and in particular requires supports for key
   distribution for the security associations between the Home Agent and
   the Foreign Agent, and the SA between the Mobile Node and the Foreign
   Agent.

   Since Mobile IPv6 does not have a Foreign Agent and mobility support
   in the protocol is different (i.e. MN directly sends Binding Updates
   directly to the home agent and correspondent nodes), these
   requirements do not apply for MIPv6 and SHOULD not be considered.

   The remaining requirements about key distribution are still valid
   (support of mobile node-home agent security association, certificate
   validation, SA distribution, etc.) and SHOULD be supported for Mobile
   IPv6.

   In the same way that in MIPv4, a security association is established
   between the mobile node and the attendant; for MIPv6, it is still
   relevant to set up a SA between the mobile node and the attendant,
   more particularly for Local Security Association.


5.3.  Authentication and key distribution mechanisms.

   When RFC 2977 [1] was written, the requirements did not specify any
   particular authentication and key distribution mechanisms.
   However,the Diameter Mobile IPv4 Application defines a very specific
   mechanism.

   In order to make Mobile IPv6 support in AAA flexible and future
   proof, the following requirement is considered:

   -  for authentication and key distribution, support for Mobile IPv6
      in AAA SHOULD allow different mechanisms to be supported.

   EAP provides a more generic mechanism for authentication and the
   advantages of EAP are explained in RFC2284. Each authentication
   method (such as CHAP [9], AKA [10], etc.) has its own properties, and
   different users belonging to different home domains may have
   different requirements. The adoption of EAP as one of the mechanisms
   supported by AAA for Mobile IPv6 would provide a wider choice for the
   AAAH and MN of which authentication method to adopt based on their
   policies and requirements.

   As for the key distribution, the Mobile IPv6 support in AAA should
   also allow different possible protocols and more flexible behavior.



Faccin et al.                                                   [Page 8]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   For this reason, the following requirement is expressed:

   -  for authentication and key distribution, support for Mobile IPv6
      in AAA SHOULD allow for AAA to act only as trusted third party.

   This would allow the MN and the home agent to authenticate each other
   and perform key distribution with other mechanisms (e.g. IKE) without
   directly involving AAA.

   If no SA is shared by MN and HA, an SA MAY be negotiated through AAA
   exchanges with AAA acting as trusted third party


5.4.  Integration of Mobile IP and AAA procedures

   The following requirement is already present in RFC 2977 [1] and
   still applies to Mobile IPv6:

   -  After the initial registration, the mobile node is authorized to
      continue using Mobile IP at the foreign domain without requiring
      further involvement by the AAA servers.

   This implies that at the initial registration the mobile node needs
   to be authenticated and authorized, and mobility procedures need to
   be performed (e.g. between the foreign agent and the home agent) to
   guarantee the mobile node can use Mobile IP.

   Initial registration may take a long time, e.g. if the foreign and
   the home domains are far away from each other. In order to reduce
   latency in the initial registration, it is important to reduce the
   time taken for communications between the AAA servers to traverse the
   wide-area Internet that is likely to separate the AAAL and the AAAH.

   In the AAA support for Mobile IPv4, in order to reduce the number of
   messages between domains that traverse the network for initial
   registration of a Mobile Node and the resulting latency, the initial
   registration message between the foreign agent and the home agent is
   carried by AAA through the AAA functions in the visited network
   (AAAL) and the home network (AAAH).  As a result, latency is reduced
   by handling the initial registration in conjunction with AAA and the
   mobile IP mobility agents.

   A similar solution should be adopted also for the support of Mobile
   IPv6, and the following requirement is formulated:

   -  it SHOULD be possible to combine authorization and authentication
      of a mobile node through AAA with Mobile IPv6 mobility procedures
      (e.g. Binding Update).



Faccin et al.                                                   [Page 9]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   Moreover, subsequent registrations, and authentication could be
   optimized thanks to LSA.

   Thanks to this requirement, unless the authentication mechanism
   adopted requires several round trips, all needed AAA and Mobile IP
   functions can be processed during a single exchange of messages
   between the foreign domain and the home domain.


5.5.  Home agent allocation

   Another important requirement that needs to receive special attention
   when defining the IPv6 solution is the Home agent allocation.
   Scenarios for home agent allocation have already been described in
   RFC 2977 [1] and still apply.

   The Diameter Mobile IPv4 Application defines the procedure to assign
   the Home agent in the visited domain. The ability to support this not
   only provides more flexibility, but also allows more business
   scenarios and reduces delays for the Mobile IP signaling procedures.
   Thanks to the application, the Home Agent allocated to the MN needs
   not be part of the MN home domain.  E.g. this situation can occur if
   the home address of the mobile node is provided by one domain (e.g.
   an ISP that the mobile user uses while at home), and the
   authorization and accounting by another (specialized) domain, e.g., a
   credit card company. Another example is that the MN may want to get
   connectivity and the ability to be mobile in a foreign domain and by
   using the subscription with a home ISP (home domain), but the MN does
   not desire to be reachable for packets destined to the MN home
   address given by the home ISP.

   Such functionality SHOULD also be considered when designing the AAA
   support for MIPv6 solution.


6.  Security considerations

   This document does not specify a solution but describes the
   requirements that need to be considered when developing a solution
   for Mobile IPv6 and AAA. The security requirements have been listed
   and explained in the previous sections.  Different solutions MAY
   fulfill the functional requirements expressed in this document. For
   each of these, the security implications need to be analyzed








Faccin et al.                                                  [Page 10]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


7.  References

   [1]       Glass, et al.; Mobile IP Authentication, Authorization and
             Accounting Requirements, RFC 2977, Internet Engineering
             Task Force, October 2000.

   [2]       Pat R. Calhoun, Charles E. Perkins; Diameter Mobile IPv4
             Application, Internet draft, Internet Engineering Task
             Force, November 2001.

   [3]       Protocol Carrying Authentication for Network Access WG
             (pana) http://www.ietf.org/html.charters/pana-charter.html.

   [4]       Yoshihiro Ohba, James Kempf, Phil Roberts, Barani Subbiah,
             Basavaraj Patil, Henry Haverinen, Hesham Soliman; Usage
             Scenarios of a User Registration Protocol (URP), Internet
             draft, Internet Engineering Task Force, November 2001.

   [5]       Stefano M. Faccin, Franck Le; AAA Local Security
             Association (LSA): The Temporary Shared Key (TSK), Internet
             draft, Internet Engineering Task Force, July 2001.

   [6]       Pat R. Calhoun, et al.; Diameter Base Protocol, Internet
             draft, Internet Engineering Task Force, November 2001.

   [7]       B. Aboba et M. Beadles, The Network Access Identifier, RFC
             2486, Internet Engineering Task Force, January 1999.

   [8]       Charles E. Perkins et al., AAA for IPv6 Network Access,
             Internet draft, Internet Engineering Task Force, July 2001

   [9]       W. Simpson, PPP Challenge Handshake Authentication Protocol
             (CHAP), RFC 1994, Internet Engineering Task Force, August
             1996

   [10]      J. Arkko et H. Haverinen, EAP AKA Authentication, Internet
             draft, Internet Engineering Task Force, November 2001

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

   [12]      Stefano M. Faccin, Franck Le; Diameter Mobile IPv6
             Application, Internet draft, Internet Engineering Task
             Force, November 2001.

   [13]      Francis Dupont, Maryline Laurent-Maknavicius et Julien
             Bournelle; AAA for mobile IPv6; Internet draft, Internet
             Engineering Task Force, November 2001.



Faccin et al.                                                  [Page 11]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


8.  Authors' Addresses


















































Faccin et al.                                                  [Page 12]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   Stefano M. Faccin
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972 894-4994
   E-mail: stefano.faccin@nokia.com


   Franck Le
   Nokia Research Center
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972 374-1256
   E-mail: franck.le@nokia.com


   Basavaraj Patil
   Nokia Corporation
   6000 Connection Drive
   Irving, TX 75039
   USA

   Phone:  +1 972-894-6709
   E-Mail:  Raj.Patil@nokia.com


   Charles E. Perkins
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, California 94043
   USA

   Phone:  +1 650-625-2986
   E-Mail: charliep@iprg.nokia.com


   Francis Dupont
   ENST Bretagne
   Campus de Rennes
   2, rue de la Chataigneraie
   BP 78
   35512 Cesson-Sevigne Cedex
   FRANCE
   Fax: +33 2 99 12 70 30



Faccin et al.                                                  [Page 13]


INTERNET-DRAFT        Mobile IPv6 AAA Requirements             April 2003


   EMail: Francis.Dupont@enst-bretagne.fr


   Maryline Laurent-Maknavicius
   INT Evry
   9, rue Charles Fourier
   91011 Evry Cedex
   FRANCE
   Fax: +33 1 60 76 47 11
   EMail: Maryline.Maknavicius@int-evry.fr


   Julien Bournelle
   INT Evry
   9, rue Charles Fourier
   91011 Evry Cedex
   FRANCE
   Fax: +33 1 60 76 47 11
   EMail: Julien.Bournelle@int-evry.fr
































Faccin et al.                                                  [Page 14]