Internet DRAFT - draft-boursetty-eap-cst
draft-boursetty-eap-cst
Internet Draft Benoit de Boursetty
Document: Florent Bersani
draft-boursetty-eap-cst-00.txt France Telecom R&D
Expires: September 2003 March 2003
EAP client-side transport
<draft-boursetty-eap-cst-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
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 defines a new architecture on the client-side for
authentication by EAP. This architecture complements the usual setup
considered in EAP by making it become symmetric: the client-side is
divided in two parts, the Authentication Token and the client, which
are analogous respectively to the Authentication Server and the
Authenticator on the server-side. Moreover, this document describes a
framework for the use of Authentication Tokens with the EAP protocol.
Boursetty and Bersani Expires - September 2003 [Page 1]
EAP client-side transport March 2003
Table of Contents
1. Introduction...................................................2
1.1 Reminder of a Typical EAP Setup............................2
1.2 Purpose of this draft......................................3
1.3 Requirements language......................................4
1.4 Terminology................................................4
1.5 Related work...............................................5
2. Architecture...................................................6
2.1 Overall Architecture.......................................6
2.2 Protocol stack.............................................7
3. Rationale for our proposal.....................................8
3.1 Security on the client side................................8
3.2 Flexibility on the Client side.............................8
3.3 Ease of deployment of the authentication method............9
4. Protocol specifications.......................................10
4.1 EAP-CST (EAP Client-Side Transport).......................10
4.2 EAP-CST-LDA (EAP-CST Link-layer Dependent Adaptation).....11
5. Example.......................................................11
6. Provisions for the evolution of EAP-CST.......................13
6.1 MK and MSK transport between AuthToken and Client.........13
6.2 Initialization of the authentication......................13
7. Security Considerations.......................................13
Acknowledgements.................................................14
References.......................................................14
Authors' Addresses...............................................16
1. Introduction
1.1 Reminder of a Typical EAP Setup
Let us begin this draft with a reminder of a typical EAP Setup. For a
more detailed description, the reader is referred to [1].
+--------+ +--------+
| Client | | NAS |
| +--( Access Network )--+ +-----( Target Network )
+--------+ +----+---+
|
|
+----+----+
| AAA |
| Server |
+---------+
Fig. 1 û A typical EAP Setup
Boursetty and Bersani Expires - September 2003 [Page 2]
EAP client-side transport March 2003
As represented on Fig 1., a client wants to connect to a Target
Network through a Network Access Server (NAS), which is first reached
via an Access Network (e.g. 802.11 [6]). The NAS requires
authentication using EAP [2,3] from the client, but it does not
perform authentication itself. It instead relays EAP authentication
exchanges to an AAA server (e.g. using the RADIUS protocol [4]).
After a successful authentication, an EAP Master Key (MK) may be
shared between the AAA Server and the Client, depending on the EAP
Method used. An example of EAP Method providing MK establishment is
EAP-TLS [5].
The data encryption or integrity protocol between the client and the
NAS that is used after the authentication (e.g. WEP, TKIP or CCMP
[6,7]) will use keying material which is termed in [1] the Master
Session Key (MSK). This MSK may be provided by the AAA server or
derived from the MK.
Since the NAS does not know this keying material right after the
authentication procedure, it needs to be transmitted from the AAA.
This problem is explained for PPP [8] in section 6.2 of [4]. In [1],
the data containing keying material transferred from the AAA server
to the NAS is called the AN-Token. Transport from the AAA server to
the NAS is sometimes dealt with, when using RADIUS, by using MS-MPPE-
Send-Key and MS-MPPE-Recv-Key between the NAS and the RADIUS server
as described in [9]. RADIUS Support For Extensible Authentication
Protocol (EAP) is dealt with in [10].
We want to stress the separation on the server-side between
authentication and its later use. In this setup, authentication is
performed between the Client and the AAA Server, but it is used
between the Client and the NAS.
1.2 Purpose of this draft
We propose in this draft a client-side mechanism which also separates
authentication from its later use (for instance, session keys used to
encrypt the communications between the NAS and the client).
We would additionally like to provide the basis for an interoperable
framework for the use of Authentication Tokens with EAP.
We however do not intend to define a general transaction protocol on
the client side. A typical use case for such a transaction protocol
is the following: the user wants to digitally sign an e-mail that he
wrote on his laptop but his credentials are stored on his mobile
phone. The transaction protocol would handle the communication
between the laptop and the mobile phone so as to deliver the expected
Boursetty and Bersani Expires - September 2003 [Page 3]
EAP client-side transport March 2003
service. Such a protocol is outside of our scope: our sole purpose is
to enhance EAP's typical setup on the client-side.
1.3 Requirements language
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 RFC-2119 [11].
1.4 Terminology
AN-Token
This terminology is defined in [1] and has the same meaning in this
document.
Client and Server
Two main entities are considered in this draft: the Client and the
Server. These two entities communicate with one another. The Client
initiates the dialog to the Server. In this document, the Client and
the Server wish to authenticate to each other, mutually or not. The
Client and the Server may then wish to use cryptographic
confidentiality and integrity protection mechanisms to safeguard
their communications.
We adopt this terminology of "Client" and "Server", although in [1]
the corresponding notions would be called "Client" and "NAS". This is
to abstract our work from the network access control problem to
address other sorts of access control, between any client and server.
Authentication Server (AuthServer or AS)
An Authentication Server is an entity that provides an authentication
service to the Server. Most implementations would probably feature
Authorization and Accounting, making it an AAA server. But this is
not mandatory for the purpose of this draft.
Authentication Token (AuthToken or AT)
An Authentication Token is a device which a Client can use to prove
its identity and gain access to services suchas network services or
application services.
An Authentication Token not only stores the user's credentials but
also handles the authentication protocol and provides additional
management features like enabling multiple identities to be stored on
the same Token. In addition, Authentication Tokens have the ability
to communicate with other devices. A token card without a
communication port shall therefore not be considered an
Authentication Token in this draft.
Boursetty and Bersani Expires - September 2003 [Page 4]
EAP client-side transport March 2003
Authentication Tokens may be for instance: smart cards, token cards,
mobile phones or even laptops. An instance of Authentication Token is
the smart card performing EAP as presented in [12].
1.5 Related work
Our work is closely related to [12].
The approach of [12] is to perform end-to-end authentication between
a smart card and an AAA Server, then transmit session keys (fragments
of the MSK) from the smart card to the authenticating device which
will then be communicating with the NAS using these session keys for
security.
The main value of this approach is to lower the risk of fraud. When
secrets are stored on a device like a PC, historically known to be
prone to Trojan horses, they can easily be misused without the
legitimate user noticing it. Also, the memory of a "borrowed" PC
(e.g. hard drives) can be read with little time and investment. Thus,
by keeping the secrets on a secure authentication Token hardened
against Trojan horse and physical attacks, the overall fraud risk is
lowered.
Acknowledging the value of this approach, we propose an architecture
that generalizes it in several ways.
First, we would like to broaden the scope and not be restricted to
smart cards. An Authentication Token might well be, for instance, a
mobile phone regardless of whether a smart card (like the GSM SIM) is
present in the mobile phone. We would therefore like to specify a
more general protocol that would enable EAP exchanges to be relayed
from a Client to an Authentication Token.
Second, we wish to split this protocol in two sublayers: a logical
sublayer, independent of the networking technology used to link the
Authentication Token to the Client, and a physical sublayer taking
care of the adaptation to the particular technology used. To take
[12] as an example, this would imply separating the four abstract
primitives used (EAP-Packet, Get-Next-Identity, Set-Identity, Get-
PairwiseMasterKey) from the specific ISO 7816-4 case.
In our approach, we make a clear distinction between the link used by
the Authentication Token and the Client (in [12], ISO 7816-4) and the
Token itself (in [12], a smart card). Thanks to our approach, the
same Authentication Token (e.g. a mobile phone) can be used with
various links (e.g. Infra-red or Bluetooth). Similarly, the same link
(e.g. Bluetooth) can be used by different Authentication Tokens (e.g.
a Linux PDA or a Java phone).
Boursetty and Bersani Expires - September 2003 [Page 5]
EAP client-side transport March 2003
2. Architecture
2.1 Overall Architecture
The architecture that we define is represented on Fig. 2.
+---------+ +----------+
|AuthToken| <====== Authentication ======> |AuthServer|
+----+----+ +-----+----+
| Integrity & |
| +------------+ <= Encryption => +-----------+ |
'----+ Client |------------------+ Server +-'
+------------+ +-----------+
Fig. 2. A new EAP setup
A Client and a Server want to communicate with each other (e.g. a
client laptop and an 802.11 Access Point).
At some point, authentication needs to be performed between the
Client and the Server. This authentication is delegated on the
client-side to an Authentication Token (AuthToken), and on the
server-side to an Authentication Server (AuthServer).
Authentication then takes place using EAP between the Authentication
Token and the Authentication Server at the logical level, while the
Client and the Server simply relay exchanges between the two, such as
Challenges, Responses, etc.
Optionally, an EAP Master Key (MK) is derived during the
authentication phase. At the end of this phase, the MK is shared
between the Authentication Token and the Authentication Server.
If the Client and the Server then wish to establish a secure link,
they need to share some keying material. This keying material derives
from the MSK that is provided either by derivation from the MK or by
the Authentication Server (depending on the particular EAP method
used).
The Client and the Server then use the MSK (more precisely the TSK
derived from the MSK) to encrypt and integrity-protect their
communications in a service-specific way.
The setup that we propose in Fig. 2 makes the typical setup of Fig. 1
become symmetric. In Fig 2, the client of Fig 1. has been split up in
two parts (the Authentication Token and the Client), the NAS has
become the Server and the AAA Server, the Authentication Server.
Boursetty and Bersani Expires - September 2003 [Page 6]
EAP client-side transport March 2003
2.2 Protocol stack
The protocol stack defined for our architecture is represented on
Fig. 3.
+------------+
| EAP-X |<== Authentication to the AuthServer =>
+------------+ +------------++--------+ +--------++--------+
| EAP | | EAP || EAP | | EAP || EAP |
+------------+ +------------++--------+ +--------++--------+
| EAP-CST | | EAP-CST || | | || EAP |
+------------+ +------------+|Service | |Service || over |
|EAP-CST-LDA | |EAP-CST-LDA ||Protocol| |Protocol|| AAA |
+------------+ +------------+| | | |+--------+
| Local link |---| Local link || +-------+ || AAA |
+------------+ +------------++--------+ +--------++--------+
AuthToken Client Server
Fig. 3(a). Protocol stack on the client side
+---------+
<= Authentication from the AuthToken => | EAP-X |
+--------++--------+ +---------+
| EAP || EAP | | EAP |
+--------++--------+ +---------+
| || EAP | | EAP |
|Service || over | + over |
|Protocol|| AAA | | AAA |
| |+--------+ +---------+
| || AAA |----------------------------| AAA |
+--------++--------+ +---------+
Server AuthServer
Fig. 3(b). Protocol stack on the server side
It is assumed that the Server and the Client authenticate each other
using EAP.
EAP is used to encapsulate a given method represented on Fig. 3. as
EAP-X, for instance EAP-TLS. Any method can be used there (e.g. EAP-
SIM [13], EAP-TLS, ...).
The layer represented as "Service Protocol" is an abstract layer,
that is to say that its choice does not have any importance for the
definition of our architecture. It could be instantiated for example
by EAPoverLAN over 802.3 [14], or by PPP over a serial line.
Boursetty and Bersani Expires - September 2003 [Page 7]
EAP client-side transport March 2003
Similarly, it is not relevant to specify the AAA and EAP-over-AAA
protocols for the purpose of this Draft.
The two layers that we define in this document are EAP-CST (which
stands for EAP Client-Side Transport) and EAP-CST-LDA (which stands
for EAP-CST Link-layer Dependent Adaptation).
3. Rationale for our proposal
In our opinion, the benefits of our approach are:
a. Security on the client side.
b. Flexibility on the client side.
c. Ease of deployment of the authentication method.
Additionally, when compared to [12], our approach enhances the
security of the client's credentials. Although smart cards provide
good protection against physical attacks, they provide little
protection so far against Trojan horses on the host to which they are
connected. It is easier to provide security against these threats by
encapsulating the smart card in a component which can be hardened
against Trojan horses more efficiently than a PC, e.g. a mobile
phone.
3.1 Security on the client side
Thanks to an adequate Authentication Token, it will be harder for an
attacker to steal the client's credentials, to use them without his
consent, to destroy them or to make them unusable.
For instance, if a Trojan horse on the host to which a smartcard is
connected performs enough wrong PIN entries, it may block that
smartcard. Alternatively, if a Trojan horse knew the user's PIN code
(for example by keylogging previous PIN entries), it could relay the
smartcard's capabilities to an outside attacker.
By placing a smartcard inside an Authentication Token which has a
User Interface, and only performs authentication once the User
Interface has been properly activated, the risk can greatly be
reduced. For instance, an Authentication Token may be a closed OS
device featuring a keyboard for PIN entry and comprising a smart
card; PIN entry being performed locally to the Authentication Token,
a Trojan horse located on a different host would have no way of
keylogging the PIN or entering it secretly to the smartcard
unbeknownst to the user.
3.2 Flexibility on the Client side
Boursetty and Bersani Expires - September 2003 [Page 8]
EAP client-side transport March 2003
The same Client (e.g. a laptop) supports a wide range of
authentication Tokens (mobile phone, smart card, Token card...).
The client will be able to use at his/her convenience a wide range of
media for authentication transport (Bluetooth, Ir, etc.).
The client will be able to authenticate to multiple services
simultaneously (e.g. cellular and WLAN services).
The client won't have to do any cumbersome manipulation (e.g. taking
the SIM out of a GSM mobile phone to plug it into an appropriate
reader on his laptop, when the GSM mobile phone could instead act as
an Authentication Token for the laptop).
3.3 Ease of deployment of the authentication method
Only the Authentication Token needs to implement the EAP method, not
the Client. This may simplify the user configuration: for instance,
no specific adjustments would need to be made to a user's laptop when
an EAP method upgrade is performed.
Boursetty and Bersani Expires - September 2003 [Page 9]
EAP client-side transport March 2003
4. Protocol specifications
These sections should be completed in future versions of this draft.
4.1 EAP-CST (EAP Client-Side Transport)
The following specification of EAP-CST is currently only at the
functional level. In the future, the definition of the primitives
below shall be completed by parameter syntax and more precise
semantics.
EAP-CST includes the following primitives, exchanged between
AuthToken (AT) and the Client (C).
Primitive name Direction Description
====================================================================
EAP-Packet AT <-> C Relay an EAP packet
--------------------------------------------------------------------
Auth-Status AT --> C Indicate the success or failure of the
authentication. If successful, a
MasterSessionKey-Give message may
follow
--------------------------------------------------------------------
MasterSessionKey- AT --> C Transmit the Master Session Key
Give generated by the last authentication,
if successful
--------------------------------------------------------------------
IdentityList-Get AT <-- C Request a list of identities supported
by the Authentication Token
--------------------------------------------------------------------
IdentityList-Give AT --> C Give a list of supported identities
--------------------------------------------------------------------
Identity-Select AT <-> C Select an identity for use for the next
authentication
--------------------------------------------------------------------
Prompt-Request AT --> C Request an entry from the user (e.g.
"Please enter your PIN code")
--------------------------------------------------------------------
Prompt-Answer AT <-- C Give the user's response to a Prompt
request.
--------------------------------------------------------------------
Control-Start AT <-> C Require the start of a session
--------------------------------------------------------------------
Control-Stop AT <-> C Close the current session
--------------------------------------------------------------------
Boursetty and Bersani Expires - September 2003 [Page 10]
EAP client-side transport March 2003
4.2 EAP-CST-LDA (EAP-CST Link-layer Dependent Adaptation)
EAP-CST-LDA may be specified in future versions of this draft, or in
separate drafts. It will define a mapping of the abstract primitives
of EAP-CST to actual data exchanges on the local link layer.
EAP-CST-LDA will also be responsible for ensuring security; to take
an example where EAP-CST-LDA would be required to provide security,
the unprotected client-side transport of EAP over an IrCOMM link
would not be protected against eavesdropping; an attacker would be
able to learn the session key from listening to SessionKey-Response
messages. In this case, EAP-CST-LDA would be required to add a
security mechanism similar to the BlueTooth pairing mechanism.
5. Example
Let us illustrate our architecture with a use case: Alice ("A") wants
to connect to an 802.11 wireless LAN using her mobile phone as an
Authentication Token. A's Wireless Internet Service Provider
authenticates its users through a RADIUS server interrogated by
wireless Access Points.
This example is an instance of the above architecture, with the
following mapping:
* AuthToken = A's mobile phone
* Client = A's laptop
* Server = the wireless Access Point A wishes to use
* AuthServer = the wireless ISP's RADIUS server.
The local link layer is a BlueTooth pseudo-serial link [15]. The
"Service Protocol" abstract layer is 802.1x.
At first, the Access Point will require A to provide her identity and
start an authentication session with the RADIUS server.
Boursetty and Bersani Expires - September 2003 [Page 11]
EAP client-side transport March 2003
A's Mobile Phone A's Laptop Access Point RADIUS
AuthToken Client Server AuthServer
| | | |
| | EAP-Request/Identity | |
| |<---------------------| |
| EAP-Request/Identity| | |
|<--------------------| | |
| | | |
| EAP-Respon./Identity| | |
|-------------------->| | |
| | | |
| | EAP-Respon./Identity | |
| |--------------------->| EAP-Respon./Id. |
| | |----------------->|
The Wireless ISP's RADIUS server then starts an EAP method (EAP-SIM
for instance)
A's Mobile Phone A's Laptop Access Point RADIUS
AuthToken Client Server AuthServer
| | | |
| | |EAP-Req./SIM/Start|
| | |<-----------------|
| | EAP-Request/SIM/Start| |
| |<---------------------| |
| EAP-Req./SIM/Start | | |
|<--------------------| | |
The EAP-SIM dialog continues between the Wireless ISP's RADIUS and
A's mobile phone, relayed by the Access Point and A's laptop, until
the RADIUS issues an EAP-Success message. During this phase, A's
mobile phone may ask A to enter a PIN code. Upon success of
authentication, A's mobile phone delivers to A the session keys
derived from the successful EAP-SIM exchange.
A's Mobile Phone A's Laptop Access Point RADIUS
AuthToken Client Server AuthServer
| | | |
| | | EAP-Success |
| | |<-----------------|
| | EAP-Success | |
| |<---------------------| |
| EAP-Success | | |
|<--------------------| | |
| Auth-Success | | |
|-------------------->| | |
| SessionKey-Give | | |
|-------------------->| | |
Boursetty and Bersani Expires - September 2003 [Page 12]
EAP client-side transport March 2003
6. Provisions for the evolution of EAP-CST
6.1 MK and MSK transport between AuthToken and Client
At this point, the table of section 4.1 contains a primitive to
transport the Master Session Key. This scheme is satisfactory e.g. in
the case of EAP-TLS, where the MSK is derived using the sole
knowledge of the EAP Master Key. But considering for example that in
services allowing roaming, several MSKs may need to be created from
the EAP Master Key, and particularized for each Server to which they
relate (cf. the definition of Client-Server Token, page 4 of [1]), we
think that this scheme may need to be evolved to take into account
multiple Client-Server Tokens.
6.2 Initialization of the authentication
At this point, the table of section 4.1 contains two very simple
primitives to start and stop an authentication session. As of now,
more evolved scenarios (e.g Client scans for all available AuthTokens
and asks the user to choose which one to use) do not fall in the
scope of this document, since it is merely focused on EAP exchanges.
7. Security Considerations
As highlighted in [12] and in section 3.1, we feel that our
architecture enhances the overall security of the client-side by
preventing malicious use of critical credentials because of their
connection to a potentially insecure environment.
However, we must carefully examine various threats on our
architecture, because the EAP-CST interface exposes confidential
data. An initial assessment of threats follows. It is inspired from
section 14.3 of MeT Personal Transactions Protocol [16] (an
architecture which shares the same kind of vulnerabilities).
a. Impersonation of the Authentication Token to the Client
b. Impersonation of the Client to the Authentication Token
c. Eavesdropping on the link between the Authentication Token and
the Client
d. Modification or insertion of packets (including replay attacks)
on the link between the Authentication Token and the Client
e. Man in the Middle Attack between the Authentication Token and
the Client
f. Denial of Service on the link between the Authentication Token
and the Cilent
As mentioned in section 4.2, EAP-CST-LDA is responsible for providing
EAP-CST with a secure link that enforces confidentiality, data origin
authentication and replay protection and thus tackle all the threats
listed above.
Boursetty and Bersani Expires - September 2003 [Page 13]
EAP client-side transport March 2003
Of course, if the Authentication Token is compromised (e.g. infected
by a Trojan Horse), our security enhancements are voided: our central
assumption is that the Authentication Token is a much safer
application execution environment than the Client.
Acknowledgements
We would like to express our deep thanks to Julien Bournelle of INT
and Stefan Andersson of Ericsson for their very valuable feedback
on preliminary versions of this document.
Additionally, we thank Laurent Butti and Jean-Michel Combes of France
Telecom R&D for their support and input on the preparation of this
document.
References
1 Aboba, B., Simon, D., "EAP Keying Framework", Internet Draft
(work in progress) draft-aboba-pppext-key-problem-06.txt, March
2003
2 Blunk, L., Vollbrecht, J., "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998
3 Blunk, L., et al., "Extensible Authentication Protocol (EAP)",
Internet Draft (work in progress) draft-ietf-eap-rfc2284bis-
01.txt, January 2003
4 Rigney, C., et al., "Remote Authentication Dial-In User Service
(RADIUS)", RFC 2865, June 2000
5 Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol",
RFC 2716, October 1999
6 Institute of Electrical and Electronics Engineers, "Information
Technology - Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Network - Specific
Requirements - Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications", IEEE Standard 802.11,
1999.
7 Institute of Electrical and Electronics Engineers, "Information
Technology - Telecommunications and Information Exchange between
Systems - Local and Metropolitan Area Network - Specific
Boursetty and Bersani Expires - September 2003 [Page 14]
EAP client-side transport March 2003
Requirements - Part 11: Wireless LAN Medium Access Control (MAC)
and Physical Layer (PHY) Specifications: Specification for
Robust Security", IEEE Standard 802.11i, Drat 3.1 (work in
progress), February 2003
8 Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
9 Zorn, G., "Microsoft Vendor-specific RADIUS Attributes",
RFC 2458, March 1999
10 Aboba, B., Calhoun, P., "RADIUS Support For Extensible
Authentication Protocol (EAP)", draft-aboba-radius-rfc2869bis-
10.txt, March 2003
11 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
12 Urien, P., et al., "EAP support in smartcards", Internet Draft
(work in progress) draft-urien-eap-smartcard-01.txt, February
2003
13 Haverinen, H. Salowey, J., "EAP SIM Authentication", Internet
Draft (work in progress) draft-haverinen-pppext-eap-sim-09.txt,
January 2003
14 Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port-Based Network Access Control",
IEEE Standard 802.1X, September 2001.
15 Bluetooth SIG, "Bluetooth specifications v1.1", February 2001
16 Mobile electronic Transactions, "MeT Personal Transactions
Protocol v1.0", November 2002.
Boursetty and Bersani Expires - September 2003 [Page 15]
EAP client-side transport March 2003
Authors' Addresses
Benoit de Boursetty Phone: +33-1-4529-5926
France Telecom R&D Email: benoit.deboursetty
38, rue du General-Leclerc @francetelecom.com
92794 Issy-les-Moulineaux Cedex 9
France
Florent Bersani Phone: +33-1-4529-6220
France Telecom R&D Email: florent.bersani
38, rue du General-Leclerc @francetelecom.com
92794 Issy-les-Moulineaux Cedex 9
France
Boursetty and Bersani Expires - September 2003 [Page 16]
