Internet Draft J. Vollbrecht
Document: <draft-irtf-aaaarch-session-id-00.txt> Interlink Networks,Inc.
Category: Informational G. Carle
S. Zander
T. Zseby
GMD FOKUS
February 2001
Session ID
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.
The authors would like to note that although this draft is in a very
early stage of development it has been submitted to motivate
discussion about the topic.
Abstract
This draft describes bindings that are needed for auditing and
accounting in an interdomain generic AAA environment. It introduces
the concept of a session ID that is used to bind together a set of
related activities. These activities can be single messages,
transactions or sessions. For accounting different accounting
records must be tied together and linked to a user ID in order to
produce a bill. Auditing requires a binding of authentication,
authorization and accounting and the actual service delivered in
order to trace back all occurred actions. For both there must be a
link between the different sub-sessions a service is composed of.
This draft presents different approaches on how this binding can be
achieved. Furthermore requirements for the session ID which is used
for the binding are given and it is shown how the session ID can be
created with regard to the generic AAA architecture [1]. Finally
some examples are given.
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 1]
Internet Draft Session ID February 2001
Table of Contents
1. Introduction..................................................2
2. Terminology...................................................3
3. Binding Objectives............................................5
4. Binding Concepts..............................................6
5. Related Work..................................................6
5.1 RADIUS......................................................7
5.2 DIAMETER....................................................7
5.3 WWW based services..........................................8
6. Session ID Requirements.......................................9
7. Generation of Session IDs....................................10
8. Auditing.....................................................10
9. Accounting...................................................11
10. Anonymous Service Usage......................................11
11. Examples.....................................................11
12. Security Considerations......................................11
13. References...................................................12
14. Acknowledgments..............................................12
15. Author's Addresses...........................................12
16. Full Copyright Statement.....................................13
1. Introduction
The Generic AAA Architecture described in [1] is an infrastructure
that supports authentication, authorization and accounting for
generic services. A session is linked to one or more "users" which
might be an individual, a hardware device or a piece of software. A
"user" may act as a "customer" or with the permission of the
customer. The user might be identified with a public key, a user-ID,
an IP address, a phone number etc. A session also relates to one or
more service "providers" which support the session with resources of
some sort. Furthermore a session may incorporate one or more
"broker" which supports information on existing providers.
This draft describes the concept of a session ID which is needed in
[1] for the binding of:
- Authentication, Authorization and Accounting with the Service
provisioning process (Service Session)
- Accounting records (maybe generated by different hosts) which
provide the accounting data for the services a user has used
- Different service sessions that logically belong together
Authentication, authorization and service usage needs to be linked
to make a later auditing and accounting possible. This is even more
important if these functions are performed by different entities (in
different domains). In the case of fraud it must be checked whether
the authentication authenticated a wrong person or the rights
granted by the authorization process were wrong. The service usage
must be linked to authentication and authorization to associate the
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 2]
Internet Draft Session ID February 2001
accounted data in the service session to the person which requested
the service and has been identified during the authentication.
Furthermore in the case of misuse it must be possible to backtrack
the malicious service user which hopefully could be done having a
link to the authentication and authorization.
A session should have a session ID which allows each provider and
user in the session to audit session activity and compare it with
what other providers and users believe happened in the session. The
session ID should allow a provider to merge accounting data for the
different activities and generate a bill. Each user and provider may
have a different view on the overall session. In particular a user
or provider may only know a part of the session that took place.
In case we have more than one accounting record generated per
session (service) the session ID is used to link the different
records together. In [3] it is shown that even in the simple dialup
service we haven at least two accounting records (start and stop)
which must be tied together to provide useful information for later
billing. Other services may well produce more than two records for
example if interim reports are used or we have different service
equipment involved (e.g. print service).
A service which is provided with the architecture described in [1]
may be composed of different services from different providers. For
the user this may still look like a single service. To correlate
accounting and auditing information the different sessions which are
part of a service need to be linked together. This can be achieved
via session IDs. Several alternatives for linking are possible. One
alternative would be the use of a common session ID. Another
alternative would be to use individual session IDs for each
subsession, in combination with a binding function (or a binding
service) that would allow to obtain information about the related
services. In the accounting case it might not be necessary to link
to the session ID if there is a separate billing for each accounted
process.
A session ID must be unique for each provider-user combination. This
means that each provider and user may have to create a piece of the
session ID to guarantee that it is unique to it. It is also possible
that the provider creates the whole session ID by using user and
provider information.
2. Terminology
Service:
A service is a performance offered by a provider. In contrast to
goods, services are usually intangible and production and consuming
happens simultaneously. Services can be very different. A service
can be for instance a 2 hour videoconference including audio, video
and whiteboard, the guaranteed transmission of 100000 packets with a
high priority, the provisioning of accounting records, etc.
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 3]
Internet Draft Session ID February 2001
Session:
A session is a service provisioning over time. Start and stop of the
session is determined by the service definition. Examples for
sessions are audio/video flows, downloading data, collecting
continuous (interim) accounting data, etc. Also the concatenation of
transactions can be called a session. A session may have subsessions
and transactions. A session has three different phases: session
establishment, service session, session teardown.
Super- and Subsession:
A session can be a super- or subsession. A session is called a
supersession if it has one or more subsessions which are a part of
the supersession. A subsession is a session which is part of a
supersession. All sessions together form the session graph. In case
of a hierarchical relationship we have a session tree with a root
session which is the supersession for all other sessions. Whether a
particular session is a super- or subsession depends on the
viewpoint (e.g. a supersession of a subsession can be a subsession
of another supersession). The supersession should have knowledge of
all subsessions.
In certain cases it also might be desirable to be able to determine
the supersession ID from the subsession ID. Nevertheless, for
privacy reasons knowledge about the subsession should not
automatically imply knowledge about the supersession. Privacy may be
compromised if the ID of the supersession contains some cleartext
information which might for instance reveal participants. Even if
the supersession encrypts these information the knowledge that there
exists a supersession may be problematic. Even if the communication
between two parties is encrypted the fact that someone knows that
there is a communication between them might be already compromising.
Peer Session:
A peer-session is a session which is on the same level with another
session (this means it is neither a super- nor a sub-session). Peer-
sessions may interact which each other.
Transaction:
A transaction consists of request and response messages that are
exchanged. Transactions differ from sessions because they do not
require a "continuous" flow of data. Examples for transactions are
the authorization of a service, buying a book, etc. Transactions can
be part of a session. Simple transactions consist of a single
request-response message pair. An authentication and/or
authorization transaction is often used to determine if a session is
allowed prior to actual session establishment.
Authentication Transaction:
An authentication transaction is the exchange of request/response
messages to perform authentication.
Authorization Transaction:
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 4]
Internet Draft Session ID February 2001
An authorization transaction is the exchange of request/response
messages to perform authorization. During a session reauthorization
transactions might be necessary.
Accounting Transaction:
An accounting transaction is the exchange of request/response
messages to perform accounting. Accounting can be performed in the
form of accounting transactions that report on resource usage by a
session. Accounting transaction can occur during a session if
accounting or charging indications are needed [pol based acct] or
only at the start and the end of the session.
Accounting Session:
An accounting session consists of subsequent accounting records. It
can be seen as the concatenation of single messages or as
concatenation of multiple accounting transactions.
Auditing:
Auditing is the process of examining information on a provided
services to check whether the service has been provided correctly
and the contractual negotiated parameters have been met. // Auditing
should be performed by an independent third party in order to
prevent fraud.
Auditing Transactions:
Auditing transactions are message exchanges used in the process of
auditing a session. This could be requests to store or to query
auditing information.
AAA Transactions:
AAA messages and transactions may be considered a form of signaling
used to control a session. AAA transactions should have unique
transaction IDs, different from the session ID, which can be used to
associate the transactions with the session.
Binding:
Binding is the process of building associations between different
messages, transactions and sessions which logically belong together
for accounting and auditing purposes.
3. Binding Objectives
There are different objectives to bind messages, sessions and
transactions together.
A) Binding authentication, authorization transactions to the main
service session and accounting: This is required in order to
concatenate information about the user (user ID) to the session
and the involved transactions. For accounting it is important to
map the user ID to the corresponding accounting records. For
auditing it is also of interest how the user has been
authenticated (e.g. strong or weak mechanism) and authorized.
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 5]
Internet Draft Session ID February 2001
B) Binding together accounting records for one service session: This
is needed to recognize which accounting records belong to the
same service session. The bound accounting records form the
accounting session.
C) Binding together sub-sessions which belong to a service-package
or super-session: This would be for example the binding of audio-
and video session for a videoconference (super-session). Binding
of sub-sessions to a super-session is useful to concatenate the
services used by one user simultaneously and the accounting data
for this session.
A) and B) would be the "traditional" (see section 5) session ID. The
purpose of A) is auditing and to also link user authorization to
accounting while B) is needed for accounting and auditing. C) would
link different services (even from different domains) together.
The IDs could be named differently according to the bindings they
provide.
4. Binding Concepts
In the following we first describe two different concepts for
binding messages, sessions and transactions together:
- Hierarchical binding: With an hierarchical binding sub-session ID
are derived from the super-session (or parent-session) ID. Here we
have to distinguish whether one should be able to determine the
supersession ID from subsession IDs. For instance whether the ID
of a videoconference session could be derived from the audio-
session ID. This might violate privacy requirements.
- Peer-to-peer binding: With a peer-to-peer binding two sessions at
an equal level are concatenated (e.g. an audio-session that
consists of two audio-sessions in different provider networks).
Information on the binding between two sessions can be stored at
the concatenation points where both sessions are known (e.g. AAA
server or the border routers between two providers).
Second the binding could also distinguished according to the
following:
- Implicit (late) binding: No explicit binding is created during
session lifetime. Binding is created if needed (e.g. for auditing)
based on service relevant information like user name, IP address,
etc.
- Explicit binding: The binding is created during the session
lifetime and/or shortly after.
5. Related Work
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 6]
Internet Draft Session ID February 2001
This chapter gives an overview of existing services which already
use the concept of a session ID.
5.1 RADIUS
[2] defines the RADIUS protocol which is used for authorization and
accounting a dial-in service. A RADIUS session is defined as
follows: Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session defined as
the point where service is first provided and the end of the session
defined as the point where service is ended. A user may have
multiple sessions in parallel or series if the NAS supports that.
For accounting purposes a session ID is generated [3]. RADIUS
generates on accounting records at the start and the stop of a
session. The RADIUS Acct-Session-ID attribute is used to match the
two reports of a session and is defined as follows: This attribute
is a unique Accounting ID to make it easy to match start and stop
records in a log file. The start and stop records for a given
session MUST have the same Acct-Session-ID. It is strongly
recommended that the Acct-Session-ID be a printable ASCII string.
For example, one implementation uses a string with an 8-digit upper
case hexadecimal number, the first two digits increment on each
reboot (wrapping every 256 reboots) and the next 6 digits counting
from 0 for the first person logging in after a reboot up to 2^24-1,
about 16 million. Other encodings are possible. Another attribute
which is defined in [3] is the Acct-Multi-Session-ID. This attribute
links together multiple related sessions and thus can be seen as
kind of supersession ID with regard to the session ID of one
session. The attribute is defined as follows: This attribute is a
unique Accounting ID to make it easy to link together multiple
related sessions in a log file. Each session linked together would
have a unique Acct-Session-ID but the same Acct-Multi-Session-ID.
It is strongly recommended that the Acct-Multi-Session-ID be a
printable ASCII string.
5.2 DIAMETER
The successor of RADIUS is the basis for the forthcoming AAA
protocol DIAMETER [4]. DIAMETER has a session ID for binding the
different AAA transaction together. Therefore a Session-ID AVP has
been defined. The initial request for authentication and/or
authorization of a user would include the Session-ID. The Session-ID
is then used in all subsequent messages to identify the user's
session. The session state (associated with a Session-ID) is freed
upon receipt of the Session-Termination-Request, Session-
Termination-Answer and according to rules established in a
particular extension/application of DIAMETER.
The Session-ID AVP is defined as follows: The Session-ID AVP (AVP
Code 263) is of type Data and is used to identify a specific session
(see section 3.0). All messages pertaining to a specific session
MUST include only one Session-ID AVP and the same value MUST be used
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 7]
Internet Draft Session ID February 2001
throughout the life of a session. When present, the Session-ID
SHOULD appear immediately following the DIAMETER Header. For
messages that do not pertain to a specific session, multiple
Session-ID AVPs MAY be present as long as they are encapsulated
within different Grouped-AVP AVPs [messages which do not belong to
any session!]. The Session-ID MUST be globally unique at any given
time since it is used by the server to identify the session (or
flow). The format of the session identifier SHOULD be as follows:
<Sender's Host-Name><sender's port number> <monotonically increasing
32 bit value><optional value>
The monotonically increasing 32 bit value SHOULD NOT start at zero
upon reboot, but rather start at a random value. This will minimize
the possibility of overlapping Session-IDs after a reboot.
Alternatively, an implementation MAY keep track of the increasing
value in non-volatile memory. The optional value is implementation
specific but may include a modem's device ID, a layer 2 address,
timestamp, etc. The session ID is created by the DIAMETER device
initiating the session, which in most cases is done by the client.
Note that a Session-ID MAY be used by more than one extension (e.g.
authentication for a specific service and accounting, both of which
have separate extensions).
The Session-Timeout AVP can be used by a server to tell the client
the maximum session duration. The client may use this attribute to
indicate the maximum length that it is willing to accept.
5.3 WWW based services
WWW based services are content services, electronic shops and web
based messaging services etc. Since HTTP is a stateless protocol for
the provision of certain services there is need to keep state over a
number of different HTTP requests. A session ID is used in web based
services to allow the following: tracking of user, keep state for a
user over different pages/http requests, limited form of
authentication (prevent replay attacks). There are two traditional
methods of propagating a session ID which have been used before HTTP
state management was invented [6]: URL parameter or cookies. Cookies
are optimal but not reliable since the client can disable the use of
them. A session ID used for authentication is normally a short-lived
cookie which is only kept in browser memory and is not written to
disk. However if used for keeping state the session ID may be stored
on disk, so that the state can be resumed even after shutoff and
restart of the computer.
[6] describes a way to create stateful sessions with HTTP requests
and responses. The state management mechanism allows clients and
servers that wish to exchange state information to place HTTP
requests and responses within a larger context, which is called a
"session". This context might be used to create, for example, a
"shopping cart", in which user selections can be aggregated before
purchase, or a magazine browsing system, in which a user's previous
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 8]
Internet Draft Session ID February 2001
reading affects which offerings are presented. Neither clients nor
servers are required to support cookies. A server MAY refuse to
provide content to a client that does not return the cookies it
sends.
In [5] it is shown that the HTTP State Management mechanism is both
useful and controversial compared to the traditional methods. It is
useful because numerous applications of HTTP benefit from the
ability to save state between HTTP transactions, without encoding
such state in URLs. It is controversial because the mechanism has
been used to accomplish things for which it was not designed and is
not well-suited. Some of these uses have attracted a great deal of
public criticism because they threaten to violate the privacy of web
users, specifically by leaking potentially sensitive information to
third parties such as the Web sites a user has visited. There are
also other uses of HTTP State Management which are inappropriate
even though they do not threaten user privacy.
[other protocols to look at: SIP, SDP, RTSP]
6. Session ID Requirements
Global uniqueness:
To uniquely identify a session a session ID must be globally unique
which means unique in time and location. The might be relaxed to
unique within a given time period or within a certain spatial scope.
For instance if we have to audit session data for 10 years the
session ID must be unique within this period. If it is assured that
a session does not cross certain boundaries the uniqueness
requirement may be relaxed to "unique within this boundaries".
Privacy:
A session ID must not enable a third party to be able to derive the
"real" ID of the user from the session ID. The session ID should
only be resolvable to the entity which generated it. For the
provisioning of anonymous services it might be required that the
session ID is nor resolvable at all. In case of a fully anonymous
session the session ID has to be build without even knowing user
specific parameter. Therefore no relation to the user is given.
Furthermore no information should be logged which would give a hint
on the real ID.
Efficiency:
The generation and linkage of session IDs must be sufficiently fast
compared to the overall process of service authentication and
authorization to avoid unnecessary latency. Especially it must be
avoided to increase latency in service provision due to the
transport of session IDs between providers.
Security:
A session ID must be non predictable. Otherwise it may be possible
to take over another persons session. It must not be possible to
derive user data from the session ID. This can be avoided by using a
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 9]
Internet Draft Session ID February 2001
one way hash over the data (e.g. [8]). There may be situations where
it is allowed to directly use user data in the session ID. For
security reasons session IDs could be transmitted via encrypted
channels (e.g. IPSEC).
Flexibility:
There may be different solutions of generating/assigning session ID
and binding session IDs together which can be used in different
situations. One method can be tailored to a specific service
(usage). However all methods must be compatible in a way such that
accounting and auditing is not limited to an unacceptable degree.
Granularity:
The solution must allow for the finest grained auditing possible of
a provided service. However cases in which there is only lax
auditing required should also be supported efficiently.
7. Generation of Session IDs
When and where should the session ID be generated?
To tie the three As together the session ID must be generated as
part of the authentication process. The session ID may be build
using parameter from the authentication request as well as IP
address or DNS name of the requester. The authentication may be
performed by the service equipment (e.g. dialup the NAS) or by
another entity. In case of a free service there may be no
authentication and authorization. In this case the session ID is
generated by the service equipment at the start of the service
usage.
How is the Session ID generated?
A global unique session ID can created in the generic AAA
architecture as follows. The ID is composed of three different
parts: ID = user_ID + service_ID + AAA_ID
The user_ID is an ID which is created by the service. This ID may be
based on user specific information. The ID may contain user specific
information in cleartext or it may be a cryptographic hash over some
user information. The service_ID is the ID which is used to identify
the service at the AAA server. The AAA server needs some kind of ID
to map a certain request to a certain service i.e. pass the request
to the ASM. The AAA_ID is a global unique ID of the AAA server
providing the requested service. The ID of the AAA needs to be
globally unique anyway.
8. Auditing
Auditing is used to examine the correct provisioning of the service.
The auditing process should be defined in a way that it is accepted
by both sides (provider and user) as a valid process to proof that
the provider has fulfilled the provisioning task correctly even in a
legal action.
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 10]
Internet Draft Session ID February 2001
A session ID is required here to map all actions, messages,
transactions and sub-sessions to the specific user. Since Auditing
requires traceability of all performed actions, the auditability of
a service is usually in direct contrast to anonymity. For privacy
reasons it is possible to restrict access to the data used for
auditing to a few trusted instances and/or to distribute the
knowledge of the concatenated actions in a way that only the
concatenation of information from different instances gives a the
whole view.
A session ID is always needed except we provide no auditing function
at all. This may be the case for a cheap service. Auditing
capability may be an added value for the customer. On the other hand
the government may force providers to audit specific activities
and/or data.
9. Accounting
The binding of accounting records to a specific user is required to
generate a bill. Furthermore a session ID is used to tie together
accounting messages and transactions. This can be subsequent records
for one session, records form different sources or providers.
10. Anonymous Service Usage
The ability to provide an anonymous services is very important. The
anonymity of the service user can prevent proper auditing and
therefore is in direct contrast to the requirement for auditability
of the service. We distinguish between a full anonymous services
where it is not possible at all to obtain the user-session mapping
and a partial anonymous services where certain instances are able to
resolve the user-session mapping.
11. Examples
In this section there should be several examples on how the session
ID could be used for accounting and auditing with the generic AAA
architecture [1]. The same examples as in [7] could be used.
Video on Demand (with QoS)
VPN (with QoS)
Content service (with QoS)
Dialup (with Mobility/Roaming)
Bandwidth request
Network printing
E-commerce
Anonymous service
12. Security Considerations
Privacy
Forging/Spoofing Session IDs
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 11]
Internet Draft Session ID February 2001
Encryption
13. References
[1] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence,
"Generic AAA Architecture", IETF RFC2903, August 2000
[2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997.
[4] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base
Protocol", draft-calhoun-diameter-17.txt, IETF work in Progress,
September 2000.
[5] K. Moore, N. Freed: " Use of HTTP State Management", IETF
RFC2964, October 2000
[6] D. Kristol, L. Montulli: "HTTP State Management Mechanism",
IETF RFC2965, October 2000
[7] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B.
de Bruijn, C. de Laat, M. Holdrege, D. Spence, et al, "AAA
Authorization Application Examples", Informational RFC 2905,
August 2000.
[8] R. Rivest: "The MD5 Message-Digest Algorithm" IETF RFC1321,
April 1992
14. Acknowledgments
15. Author's Addresses
John R. Vollbrecht
Interlink Networks, Inc.
775 Technology Drive, Suite 200
Ann Arbor, MI 48108
USA
Phone: +1 734 821 1205
Fax: +1 734 821 1235
EMail: jrv@interlinknetworks.com
Georg Carle
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7149
Email: carle@fokus.gmd.de
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 12]
Internet Draft Session ID February 2001
Sebastian Zander
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7287
Email: zander@fokus.gmd.de
Tanja Zseby
GMD FOKUS
Kaiserin-Augusta-Allee 31
10589 Berlin
Germany
Phone: +49-30-34 63 7153
Email: zseby@fokus.gmd.de
16. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved. This
document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 13]
--
_________________________________________________________________________
dr.ir. C.Th.A.M. de Laat, Faculty of Physics and Astronomy,
Utrecht University, Princetonplein 5, NL-3584CC Utrecht, The Netherlands.
Tel: (31)30-2534585 , mobile: 06-51566438 , Fax:(31)30-2537555
web: http://www.phys.uu.nl/~delaat , mail: c.t.a.m.delaat@phys.uu.nl