idnits 2.17.1 draft-ietf-radext-dynamic-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-13) exists of draft-ietf-radext-dtls-02 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RADIUS Extensions Working Group S. Winter 3 Internet-Draft RESTENA 4 Intended status: Experimental M. McCauley 5 Expires: August 29, 2013 OSC 6 February 25, 2013 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-06 11 Abstract 13 This document specifies a means to find authoritative RADIUS servers 14 for a given realm. It is used in conjunction with either RADIUS/TLS 15 and RADIUS/DTLS. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on August 29, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 3 55 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 57 2.3. Realm to RADIUS server resolution algorithm . . . . . . . 6 58 2.3.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.3.2. Output . . . . . . . . . . . . . . . . . . . . . . . 7 60 2.3.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 7 61 2.3.4. Validity of results . . . . . . . . . . . . . . . . . 8 62 2.3.5. Delay considerations . . . . . . . . . . . . . . . . 9 63 2.3.6. Example . . . . . . . . . . . . . . . . . . . . . . . 9 64 3. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 5. Normative References . . . . . . . . . . . . . . . . . . . . 12 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 69 1. Introduction 71 RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, 72 RADIUS/DTLS) requires manual configuration of all peers (clients, 73 servers). 75 Where RADIUS forwarding servers are in use, the number of realms to 76 be forwarded and the corresponding number of servers to configure may 77 be significant. Where new realms with new servers are added or 78 details of existing servers change on a regular basis, maintaining a 79 single monolithic configuration file for all these details may prove 80 too cumbersome to be useful. 82 Furthermore, in cases where a roaming consortium consists of 83 independently working branches, each with their own forwarding 84 servers, and who add or change their realm lists at their own 85 discretion, there is additional complexity in synchronising the 86 changed data across all branches. 88 These situations can benefit significantly from a distributed 89 mechanism for storing realm and server reachability information. 90 This document describes one such mechanism: storage of realm-to- 91 server mappings in DNS. 93 This document does not specify how to verify that server information 94 which was retrieved from DNS was from an authorised party; e.g. an 95 organisation which is not at all part of a given roaming consortium 96 may alter its own DNS records to yield a result for its own realm. 98 RADIUS/TLS and RADIUS/DTLS have their own ways how to verify that a 99 contacted peer is authorised (e.g. by presenting PKIX certificates 100 from a agreed-upon CA). 102 1.1. Requirements Language 104 In this document, several words are used to signify the requirements 105 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 106 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 107 and "OPTIONAL" in this document are to be interpreted as described in 108 RFC 2119. [RFC2119] 110 1.2. Terminology 112 RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a 113 new connection. 115 RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a 116 RADIUS/TLS port and accepts new connections 118 RADIUS/TLS node: a RADIUS/TLS client or server 120 2. DNS-based NAPTR/SRV Peer Discovery 122 2.1. Applicability 124 Dynamic server discovery as defined in this document is only 125 applicable for AAA transactions where a RADIUS entity which acts as a 126 forwarding server for one or more realms receives a request with a 127 realm for which it is not authoritative, and which no explicit next 128 hop is configured. Furthermore, it is only applicable for new user 129 sessions, i.e. for the initial Access-Request. Subsequent messages 130 concerning this session, for example Access-Challenges and Access- 131 Accepts use the previously-established communication channel between 132 client and server. 134 2.2. DNS RR definition 136 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 137 (see [RFC3958]) or SRV records. When both are defined, the 138 resolution algorithm prefers S-NAPTR results (see Section 2.3 below). 140 This specification defines three S-NAPTR service tags: 142 +-----------------+-----------------------------------------+ 143 | Service Tag | Use | 144 +-----------------+-----------------------------------------+ 145 | aaa+auth | RADIUS Authentication, i.e. traffic as | 146 | | defined in [RFC2865] | 147 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 148 | aaa+acct | RADIUS Accounting, i.e. traffic as | 149 | | defined in [RFC2866] | 150 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 151 | aaa+dynauth | RADIUS Dynamic Authorisation, i.e. | 152 | | traffic as defined in [RFC5176] | 153 +--------------- --+-----------------------------------------+ 155 Figure 1: List of Service Tags 157 This specification defines two S-NAPTR protocol tags: 159 +-----------------+-----------------------------------------+ 160 | Protocol Tag | Use | 161 +-----------------+-----------------------------------------+ 162 | radius.tls | RADIUS transported over TLS as defined | 163 | | in [RFC6614] | 164 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 165 | radius.dtls | RADIUS transported over DTLS as defined | 166 | | in [I-D.ietf-radext-dtls] | 167 +-----------------+-----------------------------------------+ 169 Figure 2: List of Protocol Tags 171 Note well: 173 The S-NAPTR service and protocols are unrelated to the IANA 174 Service Name and Transport Protocol Number registry 176 The delimiter '.' in the protocol tags is only a separator for 177 human reading convenience - not for structure or namespacing; it 178 MUST NOT be parsed in any way by the querying application or 179 resolver. 181 The use of the separator '.' is common also in other protocols' 182 protocol tags. This is coincidence and does not imply a shared 183 semantics with such protocols. 185 This specification defines two SRV prefixes (i.e. two values for the 186 "_service._proto" part of an SRV RR): 188 +-----------------+-----------------------------------------+ 189 | SRV Label | Use | 190 +-----------------+-----------------------------------------+ 191 | _radiustls._tcp | RADIUS transported over TLS as defined | 192 | | in [RFC6614] | 193 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 194 | _radiustls._udp | RADIUS transported over DTLS as defined | 195 | | in [I-D.ietf-radext-dtls] | 196 +-----------------+-----------------------------------------+ 198 Figure 3: List of SRV Labels 200 It is expected that in most cases, the SRV and/or NAPTR label used 201 for the records is the DNS A-label representation of the literal 202 realm name for which the server is the authoritative RADIUS server 203 (i.e. the realm name after conversion according to section 5 of 204 [RFC5891]). 206 However, arbitrary other SRV and/or NAPTR labels may be used if, for 207 example, a roaming consortium uses realm names which are not 208 associated to DNS names or special-purpose consortia where a globally 209 valid discovery is not a use case. Such other labels require a 210 consortium-wide agreement about the transformation from realm name to 211 lookup label. 213 Examples: 215 a. A general-purpose RADIUS server for realm example.com might have 216 DNS entries as follows: 218 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 219 _radiustls._tcp.foobar.example.com. 221 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 222 radsec.example.com. 224 b. The consortium "foo" provides roaming services for its members 225 only. The realms used are of the form enterprise-name.example. 226 The consortium operates a special purpose DNS server for the 227 (private) TLD "example" which all RADIUS servers use to resolve 228 realm names. "Bad, Inc." is part of the consortium. On the 229 consortium's DNS server, realm bad.example might have the 230 following DNS entries: 232 bad.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" 233 very.bad.example 235 c. The eduroam consortium uses realms based on DNS, but provides its 236 services to a closed community only. However, a AAA domain 237 participating in eduroam may also want to expose AAA services to 238 other, general-purpose, applications (on the same or other RADIUS 239 servers). Due to that, the eduroam consortium uses the service 240 tag "x-eduroam" for authentication purposes and eduroam RADIUS 241 servers use this tag to look up other eduroam servers. An 242 eduroam participant example.org which also provides general- 243 purpose AAA on a different server uses the general "aaa+auth" 244 tag: 246 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" 247 _radiustls._tcp.eduroam.example.org. 249 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 250 _radiustls._tcp.aaa.example.org 252 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 253 eduroam.example.org. 255 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 256 default.example.org. 258 2.3. Realm to RADIUS server resolution algorithm 260 This algorithm can be used to discover RADIUS servers (for RADIUS 261 Authentication and RADIUS Accounting) or to discover RADIUS DynAuth 262 servers. 264 2.3.1. Input 266 For RADIUS Authentication and RADIUS Accounting server discovery, 267 input I to the algorithm is the RADIUS User-Name attribute with 268 content of the form "user@realm"; the literal @ sign being the 269 separator between a local user identifier within a realm and its 270 realm. The use of multiple literal @ signs in a User-Name is 271 strongly discouraged; but if present, the last @ sign is to be 272 considered the separator. All previous instances of the @ sign are 273 to be considered part of the local user identifier. 275 For RADIUS DynAuth Server discovery, input I to the algorithm is the 276 domain name of the operator of a RADIUS realm as was communicated 277 during user authentication using the Operator-Name attribute 278 ([RFC5580], section 4.1). Only Operator-Name values with the 279 namespace "1" are supported by this algorithm - the input to the 280 algorithm is the actual domain name, preceeded with an "@" (but 281 without the "1" namespace identifier byte of that attribute). 283 Note well: The attribute User-Name is defined to contain UTF-8 text. 284 In practice, the content may or may not be UTF-8. Even if UTF-8, it 285 may or may not map to a domain name in the realm part. Implementors 286 MUST take possible conversion error paths into consideration when 287 parsing incoming User-Name attributes. This document describes 288 server discovery only for well-formed realms mapping to DNS domain 289 names in UTF-8 encoding. The result of all other possible contents 290 of User-Name is unspecified; this includes, but is not limited to: 292 Usage of separators other than @ 294 Encoding of User-Name in local encodings 296 UTF-8 realms which fail the conversion rules as per [RFC5891] 298 UTF-8 realms which end with a . ("dot") character. 300 For the last bullet point, "trailing dot", special precautions should 301 be taken to avoid problems when resolving servers with the algorithm 302 below: they may resolve to a RADIUS server even if the peer RADIUS 303 server only is configured to handle the realm without the trailing 304 dot. If that RADIUS server again uses NAI discovery to determine the 305 authoritative server, the server will forward the request to 306 localhost, resulting in a tight endless loop. 308 2.3.2. Output 310 Output O of the algorithm is a set of tuples {hostname; port; order/ 311 preference; TTL} - the set can be empty. 313 2.3.3. Algorithm 315 The algorithm to determine the RADIUS server to contact is as 316 follows: 318 1. Determine P = (position of last "@" character) in I. 320 2. generate R = (substring from P+1 to end of I) 322 3. Optional: modify R according to agreed consortium procedures 324 4. Using the host's name resolution library, perform a NAPTR query 325 for R (see "Delay considerations" below). The name resolution 326 library may need to convert R to a different respresentation, 327 depending on the resolution backend used. If no result, 328 continue at step 9. If name resolution returns with error, O = 329 { empty set } and terminate. 331 5. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 332 "aaa+dynauth" as appropriate. Keep note of the remaining TTL of 333 each of the discovered NAPTR records. 335 6. If no records found, continue at step 9. 337 7. Evaluate NAPTR result(s) for desired protocol tag, perform 338 subsequent lookup steps until lookup yields one or more 339 hostnames. O' = (set of {hostname; port; order/preference; 340 min{all TTLs that led to this result} } for all lookup results). 341 Keep note of the remaining TTL of each of the discovered records 342 (e.g. SRV and AAAA). 344 8. Proceed with step 15. 346 9. Generate R' = (prefix R with "_radiustls._tcp." or 347 "_radiustls._udp") 349 10. Using the host's name resolution library, perform SRV lookup 350 with R' as label (see "Delay considerations" below). Keep note 351 of the TTL of each of the discovered SRV records. 353 11. If name resolution returns with error, O = { empty set } and 354 terminate. 356 12. If no result, O = { empty set } and terminate. 358 13. O' = (set of {hostname; port; order/preference; min{all TTLs 359 that led to this result} } for all hostnames). 361 14. Generate O by resoving hostnames to corresponding A and/or AAAA 362 addresses: O = (set of {IP address; port; order/preference; 363 min{all TTLs that led to this result}} for all hostnames ). 365 15. For each element in O, test if the original request which 366 triggered dynamic discovery was received on {IP address; port}. 367 If yes, O = { empty set }, log error, Terminate. If no, O is 368 the result of dynamic discovery. Terminate. 370 2.3.4. Validity of results 372 After executing the above algorithm, the RADIUS server establishes a 373 connection to a home server from the result set. This connection can 374 potentially remain open for an indefinite amount of time. This 375 conflicts with the possibility of changing device and network 376 configurations on the receiving end. Typically, TTL values for 377 records in the name resolution system are used to indicate how long 378 it is safe to rely on the results of the name resolution. When a 379 connection is open and the smallest of the TTL values which were used 380 for discovering the server has not expired, subsequent new user 381 sessions for the realm which corresponds to that open connection 382 SHOULD re-use the existing connection and SHOULD NOT re-execute the 383 dynamic discovery algorithm nor open a new connection. To allow for 384 a change of configuration, a RADIUS server SHOULD re-execute the 385 dynamic discovery algorithm after the lowest of the TTL values that 386 are associated with this connection have expired. The server MAY 387 keep the session open during this re-assessment to avoid closure and 388 immediate re-opening of the connection should the result not have 389 changed. 391 Should the algorithm above terminate with an empty set (but no 392 error), the RADIUS server SHOULD NOT attempt another execution of 393 this algorithm for the same target realm before the negative TTL has 394 expired. 396 Should the algorithm above terminate due to an error with no TTL 397 value known (e.g. DNS SERVFAIL), the RADIUS server SHOULD NOT 398 attempt another execution of this algorithm for the same target realm 399 before a configurable timeout interval has passed. 401 2.3.5. Delay considerations 403 The host's name resolution library may need to contact outside 404 entities to perform the name resolution (e.g. authoritative name 405 servers for a domain), and since the NAI discovery algorithm is based 406 on uncontrollable user input, the destination of the lookups is out 407 of control of the server that performs NAI discovery. If such 408 outside entities are misconfigured or unreachable, the algorithm 409 above may need an unacceptably long time to terminate. Many RADIUS 410 implementations time out after five seconds of delay between Request 411 and Response. It is not useful to wait until the host name 412 resolution library signals a time-out of its name resolution 413 algorithms; instead, implementations of NAI discovery SHOULD 414 terminate the algorithm after the fixed upper bound of time of three 415 seconds. If no final output of the algorithm is available after this 416 timeout, the RADIUS server MUST assume the empty set as a result and 417 treat the pending request according to its static configuration 418 (e.g., fallback to a default route to a home server). Execution of 419 the NAI discovery algorithm SHOULD be non-blocking (i.e. allow other 420 requests to be processed in parallel to the execution of the 421 algorithm). 423 2.3.6. Example 425 Example: Assume 427 a user from the Technical University of Munich, Germany, has a 428 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 430 The name resolution library on the RADIUS forwarding server does 431 not have the realm tu-m[U+00FC]nchen.example in its forwarding 432 configuration, but uses DNS for name resolution and has configured 433 the use of Dynamic Discovery to discover RADIUS servers. 435 It is IPv6-enabled and prefers AAAA records over A records. 437 It is listening for incoming RADIUS/TLS requests on 192.37.5.1, 438 TCP/2083. 440 If DNS contains the following records: 442 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 443 "aaa+auth:radius.tls" "" _radiustls._tcp.xn--tu-mnchen- 444 t9a.example. 446 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 447 "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. 449 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 450 radsec.xn--tu-mnchen-t9a.example. 452 _radiustls._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 453 backup.xn--tu-mnchen-t9a.example. 455 radsec.xn--tu-mnchen-t9a.example. IN AAAA 456 2001:0DB8::202:44ff:fe0a:f704 458 radsec.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 460 backup.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 462 Then the algorithm executes as follows, with I = 463 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 464 in use: 466 1. P = 7 468 2. R = "tu-m[U+00FC]nchen.example" 470 3. NOOP 472 4. [name resolution library converts R to xn--tu-mnchen- 473 t9a.example] Query result: ( 50 50 "s" "aaa+auth:radius.tls" "" 474 _radiustls._tcp.xn--tu-mnchen-t9a.example. ; 50 50 "s" 475 "fooservice:bar.dccp" "" _abc._def.xn--tu-mnchen-t9a.example. ) 477 5. Result: 50 50 "s" "aaa+auth:radius.tls" "" _radiustls._tcp.xn 478 --tu-mnchen-t9a.example. 480 6. NOOP 482 7. O' = {(radsec.xn--tu-mnchen-t9a.example.; 2083; 10; TTL 483 A),(backup.xn--tu-mnchen-t9a. example.;2083; 20; TTL B)} 485 8. Go to step 15. 487 9. (not executed) 489 10. (not executed) 491 11. (not executed) 493 12. (not executed) 495 13. (not executed) 497 14. O = {(2001:0DB8::202:44ff:fe0a:f704; 2083; 10; TTL 498 A),(192.0.2.7; 2083; 20; TTL B)} 500 15. O = {(2001:0DB8::202:44ff:fe0a:f704; 2083; 10; TTL 501 A),(192.0.2.7; 2083; 20; TTL B)}. Terminate. 503 The implementation will then attempt to connect to two servers, with 504 preference to radsec.xn--tu-mnchen-t9a.example.:2083, using either 505 the AAAA or A addresses depending on the host configuration and its 506 IP stack's capabilities. 508 3. Security Considerations 510 When using DNS without DNSSEC security extensions, the replies to 511 NAPTR, SRV and A/AAAA requests as described in section Section 2 can 512 not be trusted. RADIUS transports have an out-of-DNS-band means to 513 verify that the discovery attempt led to the intended target: 514 certificate verification or TLS-PSK keys. 516 4. IANA Considerations 518 This document requests IANA registration of the following entries in 519 existing registries: 521 o S-NAPTR Application Service Tags registry 523 * aaa+auth 524 * aaa+acct 526 * aaa+dynauth 528 o S-NAPTR Application Protocol Tags registry 530 * radius.tls 532 * radius.dtls 534 This document reserves the use of the "_radiustls" and "_radiusdtls" 535 Service labels. 537 This document requests the creation of a new IANA registry named 538 "RADIUS/TLS SRV Protocol Registry" with the following initial 539 entries: 541 o _tcp 543 o _udp 545 5. Normative References 547 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 548 Requirement Levels", BCP 14, RFC 2119, March 1997. 550 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 551 "Remote Authentication Dial In User Service (RADIUS)", RFC 552 2865, June 2000. 554 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 556 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 557 Service Location Using SRV RRs and the Dynamic Delegation 558 Discovery Service (DDDS)", RFC 3958, January 2005. 560 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 561 Aboba, "Dynamic Authorization Extensions to Remote 562 Authentication Dial In User Service (RADIUS)", RFC 5176, 563 January 2008. 565 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 566 Aboba, "Carrying Location Objects in RADIUS and Diameter", 567 RFC 5580, August 2009. 569 [RFC5891] Klensin, J., "Internationalized Domain Names in 570 Applications (IDNA): Protocol", RFC 5891, August 2010. 572 [I-D.ietf-radext-dtls] 573 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- 574 ietf-radext-dtls-02 (work in progress), July 2012. 576 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 577 "Transport Layer Security (TLS) Encryption for RADIUS", 578 RFC 6614, May 2012. 580 Authors' Addresses 582 Stefan Winter 583 Fondation RESTENA 584 6, rue Richard Coudenhove-Kalergi 585 Luxembourg 1359 586 LUXEMBOURG 588 Phone: +352 424409 1 589 Fax: +352 422473 590 EMail: stefan.winter@restena.lu 591 URI: http://www.restena.lu. 593 Mike McCauley 594 Open Systems Consultants 595 9 Bulbul Place 596 Currumbin Waters QLD 4223 597 AUSTRALIA 599 Phone: +61 7 5598 7474 600 Fax: +61 7 5598 7070 601 EMail: mikem@open.com.au 602 URI: http://www.open.com.au.