idnits 2.17.1 draft-ietf-radext-dynamic-discovery-10.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3721 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-07 == Outdated reference: A later version (-15) exists of draft-ietf-radext-nai-05 Summary: 0 errors (**), 0 flaws (~~), 3 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 18, 2014 OSC 6 February 14, 2014 8 NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 9 draft-ietf-radext-dynamic-discovery-10 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 18, 2014. 34 Copyright Notice 36 Copyright (c) 2014 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. DNS RR definition . . . . . . . . . . . . . . . . . . . . 3 56 2.1.1. S-NAPTR . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1.2. SRV . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 2.1.3. Optional name mangling . . . . . . . . . . . . . . . 8 59 2.2. Definition of the X.509 certificate property 60 SubjectAltName:otherName:NAIRealm . . . . . . . . . . . . 10 61 3. DNS-based NAPTR/SRV Peer Discovery . . . . . . . . . . . . . 11 62 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 11 63 3.2. Configuration Variables . . . . . . . . . . . . . . . . . 12 64 3.3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 12 65 3.4. Realm to RADIUS server resolution algorithm . . . . . . . 13 66 3.4.1. Input . . . . . . . . . . . . . . . . . . . . . . . . 13 67 3.4.2. Output . . . . . . . . . . . . . . . . . . . . . . . 14 68 3.4.3. Algorithm . . . . . . . . . . . . . . . . . . . . . . 14 69 3.4.4. Validity of results . . . . . . . . . . . . . . . . . 16 70 3.4.5. Delay considerations . . . . . . . . . . . . . . . . 17 71 3.4.6. Example . . . . . . . . . . . . . . . . . . . . . . . 17 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 73 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 75 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 76 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 77 7.2. Informative References . . . . . . . . . . . . . . . . . 24 78 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm . . . . . . . . 25 80 1. Introduction 82 RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, 83 RADIUS/DTLS) requires manual configuration of all peers (clients, 84 servers). 86 Where RADIUS forwarding servers are in use, the number of realms to 87 be forwarded and the corresponding number of servers to configure may 88 be significant. Where new realms with new servers are added or 89 details of existing servers change on a regular basis, maintaining a 90 single monolithic configuration file for all these details may prove 91 too cumbersome to be useful. 93 Furthermore, in cases where a roaming consortium consists of 94 independently working branches, each with their own forwarding 95 servers, and who add or change their realm lists at their own 96 discretion, there is additional complexity in synchronising the 97 changed data across all branches. 99 These situations can benefit significantly from a distributed 100 mechanism for storing realm and server reachability information. 101 This document describes one such mechanism: storage of realm-to- 102 server mappings in DNS. 104 This document also specifies various approaches for verifying that 105 server information which was retrieved from DNS was from an 106 authorised party; e.g. an organisation which is not at all part of a 107 given roaming consortium may alter its own DNS records to yield a 108 result for its own realm. 110 1.1. Requirements Language 112 In this document, several words are used to signify the requirements 113 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 115 and "OPTIONAL" in this document are to be interpreted as described in 116 RFC 2119. [RFC2119] 118 1.2. Terminology 120 RADIUS/TLS Client: a RADIUS/TLS [RFC6614] instance which initiates a 121 new connection. 123 RADIUS/TLS Server: a RADIUS/TLS [RFC6614] instance which listens on a 124 RADIUS/TLS port and accepts new connections 126 RADIUS/TLS node: a RADIUS/TLS client or server 128 2. Definitions 130 2.1. DNS RR definition 132 DNS definitions of RADIUS/TLS servers can be either S-NAPTR records 133 (see [RFC3958]) or SRV records. When both are defined, the 134 resolution algorithm prefers S-NAPTR results (see Section 3.4 below). 136 2.1.1. S-NAPTR 138 2.1.1.1. Registration of Application Service and Protocol Tags 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 2.1.1.2. Definition of Conditions for Retry/Failure 187 RADIUS is a time-critical protocol; RADIUS clients which do not 188 receive an answer after a configurable, but short, amount of time, 189 will consider the request failed. Due to this, there is little 190 leeway for extensive retries. 192 As a general rule, only error conditions which generate an immediate 193 response from the other end are eligible for a retry of a discovered 194 target. Any error condition involving time-outs, or the absence of a 195 reply for more than one second during the connection setup phase is 196 to be considered a failure; the next target in the set of discovered 197 NAPTR targets is to be tried. 199 Note that [RFC3958] already defines that a failure to identify the 200 server as being authoritative for the realm is always considered a 201 failure; so even if a discovered target returns a wrong credential 202 instantly, it is not eligible for retry. 204 Furthermore, the contacted RADIUS/TLS server verifies during 205 connection setup whether or not it finds the connecting RADIUS/TLS 206 client authorized or not. If the connecting RADIUS/TLS client is not 207 found acceptable, the server will close the TLS connection 208 immediately with an appropriate alert. Such TLS handshake failures 209 are permanently fatal and not eligible for retry, unless the 210 connecting client has more X.509 certificates to try; in this case, a 211 retry with the remainder of its set of certificates SHOULD be 212 attempted. 214 If the TLS session setup to a discovered target does not succeed, 215 that target (as identified by IP address and port number) SHOULD be 216 ignored from the result set of any subsequent executions of the 217 discovery algorithm at least until the target's Effective TTL has 218 expired or until the entity which executes the algorithm changes its 219 TLS context to either send a new client certificate or expect a 220 different server certificate. 222 2.1.1.3. Server Identification and Handshake 224 After the algorithm in this document has been executed, a RADIUS/TLS 225 session as per [RFC6614] is established. Since the dynamic discover 226 algorithm does not have provisions to establish confidential keying 227 material between the RADIUS/TLS client (i.e. the server which 228 executes the discovery algorithm) and the RADIUS/TLS server which was 229 discovered, TLS-PKS ciphersuites cannot be used for in the subsequent 230 TLS handshake. Only TLS ciphersuites using X.509 certificates can be 231 used with this algorithm. 233 There are numerous ways to define which certificates are acceptable 234 for use in this context. This document defines one mandatory-to- 235 implement mechanism which allows to verify whether the contacted host 236 is authoritative for a NAI realm or not. It also gives one example 237 of another mechanism which is currently in wide-spread deployment, 238 and one possible approach based on DNSSEC which is yet unimplemented. 240 2.1.1.3.1. Mandatory-to-implement mechanism: Trust Roots + NAIRealm 242 Verification of authority to provide AAA services over RADIUS/TLS is 243 a two-step process. 245 Step 1 is the verification of certificate wellformedness and validity 246 as per [RFC5280] and whether it was issued from a root certificate 247 which is deemed trustworthy by the RADIUS/TLS client. 249 Step 2 is to compare the value of algorithm's variable "R" after the 250 execution of step 3 of the discovery algorithm in Section 3.4.3 below 251 (i.e. after a consortium name mangling, but before conversion to a 252 form usable by the name resolution library) to all values of the 253 contacted RADIUS/TLS server's X.509 certificate property 254 "subjectAlternativeName:otherName:NAIRealm" as defined in 255 Section 2.2. 257 2.1.1.3.2. Other mechanism: Trust Roots + policyOID 259 Verification of authority to provide AAA services over RADIUS/TLS is 260 a two-step process. 262 Step 1 is the verification of certificate wellformedness and validity 263 as per [RFC5280] and whether it was issued from a root certificate 264 which is deemed trustworthy by the RADIUS/TLS client. 266 Step 2 is to compare the values of the contacted RADIUS/TLS server's 267 X.509 certificate's extensions of type "Policy OID" to a list of 268 configured acceptable Policy OIDs for the roaming consortium. If one 269 of the configured OIDs is found in the certificate's Policy OID 270 extensions, then the server is considered authorized; if there is no 271 match, the server is considered unauthorized. 273 This mechanism is inferior to the mandatory-to-implement mechanism in 274 the previous section because all authorized servers are validated by 275 the same OID value; the mechanism is not fine-grained enough to 276 express authority for one specific realm inside the consortium. If 277 the consortium contains members which are hostile against other 278 members, this weakness can be exploited by one RADIUS/TLS server 279 impersonating another if DNS responses can be spoofed by the hostile 280 member. 282 The shortcomings in server identification can be partially mitigated 283 by using the RADIUS infrastructure only with authentication payloads 284 which provide mutual authentication and credential protection (i.e. 285 EAP types passing the criteria of [RFC4017]): using mutual 286 authentication prevents the hostile server from mimicking the real 287 EAP server (it can't terminate the EAP authentication unnoticed 288 because it does not have the server certificate from the real EAP 289 server); protection of credentials prevents the impersonating server 290 from learning usernames and passwords of the ongoing EAP conversation 291 (other RADIUS attributes pertaining to the authentication, such as 292 the EAP peer's Calling-Station-ID, can still be learned though). 294 2.1.1.3.3. Other mechanism: DNSSEC / DANE 296 Where DNSSEC is used, the results of the algorithm can be trusted; 297 i.e. the entity which executes the algorithm can be certain that the 298 realm that triggered the discovery is actually served by the server 299 that was discovered via DNS. However, this does not guarantee that 300 the server is also authorized (i.e. a recognised member of the 301 roaming consortium). 303 The authorization can be sketched using DNSSEC+DANE as follows: if 304 DANE/TLSA records of all authorized servers are put into a DNSSEC 305 zone with a common, consortium-specific branch of the DNS tree, then 306 the entity executing the algorithm can retrieve TLSA RRs for the 307 label "realm.commonroot" and verify that the presented server 308 certificate during the RADIUS/TLS handshake matches the information 309 in the TLSA record. 311 Example: 313 Realm = "example.com" 315 Common Branch = "idp.roaming-consortium.example. 317 label for TLSA query = "example.com.idp.roaming- 318 consortium.example. 320 result of discovery algorithm for realm "example.com" = 321 192.0.2.1:2083 323 ( TLS certificate of 192.0.2.1:2083 matches TLSA RR ? "PASS" : 324 "FAIL" ) 326 2.1.1.3.4. Client Authentication and Authorisation 328 Note that RADIUS/TLS connections always mutually authenticate the 329 RADIUS server and the RADIUS client. This specification provides an 330 algorithm for a RADIUS client to contact and verify authorization of 331 a RADIUS server only. During connection setup, the RADIUS server 332 also needs to verify whether it considers the connecting RADIUS 333 client authorized; this is outside the scope of this specification. 335 2.1.2. SRV 337 This specification defines two SRV prefixes (i.e. two values for the 338 "_service._proto" part of an SRV RR as per [RFC2782]): 340 +-----------------+-----------------------------------------+ 341 | SRV Label | Use | 342 +-----------------+-----------------------------------------+ 343 | _radiustls._tcp | RADIUS transported over TLS as defined | 344 | | in [RFC6614] | 345 | - - - - - - - - | - - - - - - - - - - - - - - - - - - - - | 346 | _radiustls._udp | RADIUS transported over DTLS as defined | 347 | | in [I-D.ietf-radext-dtls] | 348 +-----------------+-----------------------------------------+ 350 Figure 3: List of SRV Labels 352 Just like NAPTR records, the lookup and subsequent follow-up of SRV 353 records may yield more than one server to contact in a prioritised 354 list. [RFC2782] does not specify rules regarding "Definition of 355 Conditions for Retry/Failure", nor "Server Identification and 356 Handshake". This specification defines that the rules for these two 357 topics as defined in Section 2.1.1.2 and Section 2.1.1.3 SHALL be 358 used both for targets retrieved via an initial NAPTR RR as well as 359 for targets retrieved via an initial SRV RR (i.e. in the absence of 360 NAPTR RRs). 362 2.1.3. Optional name mangling 364 It is expected that in most cases, the SRV and/or NAPTR label used 365 for the records is the DNS A-label representation of the literal 366 realm name for which the server is the authoritative RADIUS server 367 (i.e. the realm name after conversion according to section 5 of 368 [RFC5891]). 370 However, arbitrary other labels or service tags may be used if, for 371 example, a roaming consortium uses realm names which are not 372 associated to DNS names or special-purpose consortia where a globally 373 valid discovery is not a use case. Such other labels require a 374 consortium-wide agreement about the transformation from realm name to 375 lookup label, and/or which service tag to use. 377 Examples: 379 a. A general-purpose RADIUS server for realm example.com might have 380 DNS entries as follows: 382 example.com. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 383 _radiustls._tcp.foobar.example.com. 385 _radiustls._tcp.foobar.example.com. IN SRV 0 10 2083 386 radsec.example.com. 388 b. The consortium "foo" provides roaming services for its members 389 only. The realms used are of the form enterprise-name.example. 390 The consortium operates a special purpose DNS server for the 391 (private) TLD "example" which all RADIUS servers use to resolve 392 realm names. "Bad, Inc." is part of the consortium. On the 393 consortium's DNS server, realm bad.example might have the 394 following DNS entries: 396 bad.example IN NAPTR 50 50 "a" "aaa+auth:radius.dtls" "" 397 very.bad.example 399 c. The eduroam consortium uses realms based on DNS, but provides its 400 services to a closed community only. However, a AAA domain 401 participating in eduroam may also want to expose AAA services to 402 other, general-purpose, applications (on the same or other RADIUS 403 servers). Due to that, the eduroam consortium uses the service 404 tag "x-eduroam" for authentication purposes and eduroam RADIUS 405 servers use this tag to look up other eduroam servers. An 406 eduroam participant example.org which also provides general- 407 purpose AAA on a different server uses the general "aaa+auth" 408 tag: 410 example.org. IN NAPTR 50 50 "s" "x-eduroam:radius.tls" "" 411 _radiustls._tcp.eduroam.example.org. 413 example.org. IN NAPTR 50 50 "s" "aaa+auth:radius.tls" "" 414 _radiustls._tcp.aaa.example.org 416 _radiustls._tcp.eduroam.example.org. IN SRV 0 10 2083 aaa- 417 eduroam.example.org. 419 _radiustls._tcp.aaa.example.org. IN SRV 0 10 2083 aaa- 420 default.example.org. 422 2.2. Definition of the X.509 certificate property 423 SubjectAltName:otherName:NAIRealm 425 This specification retrieves IP addresses and port numbers from the 426 Domain Name System which are subsequently used to authenticate users 427 via the RADIUS/TLS protocol. Since the Domain Name System is not 428 necessarily trustworthy (e.g. if DNSSEC is not deployed for the 429 queried domain name), it is important to verify that the server which 430 was contacted is authorized to service requests for the user which 431 triggered the discovery process. 433 The input to the algorithm is a NAI realm as specified in 434 Section 3.4.1. As a consequence, the X.509 certificate of the server 435 which is ultimately contacted for user authentication needs to be 436 able to express that it is authorized to handle requests for that 437 realm. 439 Current subjectAltName fields do not semantically allow to express an 440 NAI realm; the field subjectAltName:dNSName is syntactically a good 441 match but would inappropriately conflate DNS names and NAI realm 442 names. Thus, this specification defines a new subjectAltName field 443 to hold either a single NAI realm name or a wildcard name matching a 444 set of NAI realms. 446 The subjectAltName:otherName:sRVName field certifies that a 447 certificate holder is authorized to provide a service; this can be 448 compared to the target of DNS label's SRV resource record. If the 449 Domain Name System is insecure, it is required that the label of the 450 SRV record itself is known-correct. In this specification, that 451 label is not known-correct; it is potentially derived from a 452 (potentially untrusted) NAPTR resource record of another label. If 453 DNS is not secured with DNSSEC, the NAPTR resource record may have 454 been altered by an attacker with access to the Domain Name System 455 resolution, and thus the label to lookup the SRV record for may 456 already be tainted. This makes subjectAltName:otherName:sRVName not 457 a trusted comparison item. 459 Further to this, this specification's NAPTR entries may be of type 460 "A" which do not involve resolution of any SRV records, which again 461 makes subjectAltName:otherName:sRVName unsuited for this purpose. 463 This section defines the NAIRealm name as a form of otherName from 464 the GeneralName structure in SubjectAltName defined in [RFC5280]. 466 id-on-nai OBJECT IDENTIFIER ::= { id-on XXX } 468 NAIRealm ::= UTF8String (SIZE (1..MAX)) 470 The NAIRealm, if present, MUST contain an NAI realm as defined in 471 [I-D.ietf-radext-nai]. It MAY substitute labels on the leftmost dot- 472 separated part of the NAI with the single character "*" to indicate a 473 wildcard match for "all labels in this part". Further features of 474 regular expressions, such as a number of characters followed by a * 475 to indicate a common prefix inside the part, are not permitted. 477 The comparison of a NAIRealm to the NAI realm as derived from user 478 input with this algorithm is a byte-by-byte comparison, except for 479 the optional leftmost dot-separated part of the value whose content 480 is a single "*" character; such labels match all strings in the same 481 dot-separated part of the NAI realm. If at least one of the 482 sAN:otherName:NAIRealm values matches the NAI realm, the server is 483 considered authorized; if none matches, the server is considered 484 unauthorized. 486 Since multiple names and multiple name forms may occur in the 487 subjectAltName extension, an arbitrary number of NAIRealms can be 488 specified in a certificate. 490 Examples: 492 +---------------------+-------------------+-----------------------+ 493 | NAI realm (RADIUS) | NAIRealm (cert) | MATCH? | 494 +---------------------+-------------------+-----------------------+ 495 | foo.example | foo.example | YES | 496 | foo.example | *.example | YES | 497 | bar.foo.example | *.example | NO | 498 | bar.foo.example | *ar.foo.example | NO (NAIRealm invalid) | 499 | bar.foo.example | bar.*.example | NO (NAIRealm invalid) | 500 | bar.foo.example | *.*.example | NO (NAIRealm invalid) | 501 | sub.bar.foo.example | *.*.example | NO (NAIRealm invalid) | 502 | sub.bar.foo.example | *.bar.foo.example | YES | 503 +-----------------+-----------------------------------------------+ 505 Figure 4: Examples for NAI realm vs. certificate matching 507 Appendix A contains the ASN.1 definition of the above objects. 509 3. DNS-based NAPTR/SRV Peer Discovery 511 3.1. Applicability 513 Dynamic server discovery as defined in this document is only 514 applicable for new AAA transactions and per service (i.e. distinct 515 discovery is needed for Authentication, Accounting, and Dynamic 516 Authorization) where a RADIUS entity which acts as a forwarding 517 server for one or more realms receives a request with a realm for 518 which it is not authoritative, and which no explicit next hop is 519 configured. It is only applicable for 521 a. new user sessions, i.e. for the initial Access-Request. 522 Subsequent messages concerning this session, for example Access- 523 Challenges and Access-Accepts use the previously-established 524 communication channel between client and server. 526 b. the first accounting ticket for a user session 528 c. the first RADIUS DynAuth packet for a user session 530 3.2. Configuration Variables 532 The algorithm contains various variables for timeouts. These 533 variables are named here and reasonable default values are provided. 534 Implementations wishing to deviate from these defaults should make 535 they understand the implications of changes. 537 DNS_TIMEOUT: maximum amount of time to wait for the complete set 538 of all DNS queries to complete: Default = 3 seconds 540 MIN_EFF_TTL: minimum DNS TTL of discovered targets: Default = 60 541 seconds 543 BACKOFF_TIME: if no conclusive DNS response was retrieved after 544 DNS_TIMEOUT, do not attempt dynamic discovery before BACKOFF_TIME 545 has elapsed. Default = 600 seconds 547 3.3. Terms 549 Positive DNS response: a response which contains the RR that was 550 queried for. 552 Negative DNS response: a response which does not contain the RR that 553 was queried for, but contains an SOA record along with a TTL 554 indicating cache duration for this negative result. 556 DNS Error: Where the algorithm states "name resolution returns with 557 an error", this shall mean that either the DNS request timed out, or 558 a DNS response which is neither a positive nor a negative response 559 (e.g. SERVFAIL). 561 Effective TTL: The validity period for discovered RADIUS/TLS target 562 hosts. Calculated as: Effective TTL (set of DNS TTL values) = max { 563 MIN_EFF_TTL, min { DNS TTL values } } 564 SRV lookup: for the purpose of this specification, SRV lookup 565 procedures are defined as per [RFC2782], but excluding that RFCs "A" 566 fallback as defined in its section "Usage Rules", final "else" 567 clause. 569 Greedy result evaluation: The NAPTR to SRV/A/AAAA resolution may lead 570 to a tree of results, whose leafs are the IP addresses to contact. 571 The branches of the tree are ordered according to their order/ 572 preference DNS properties. An implementation is executing greedy 573 result evaluation if it uses a depth-first search in the tree along 574 the highest order results, attempts to connect to the corresponding 575 resulting IP addresses, and only backtracks to other branches if the 576 higher ordered results did not end in successful connection attempts. 578 3.4. Realm to RADIUS server resolution algorithm 580 3.4.1. Input 582 For RADIUS Authentication and RADIUS Accounting server discovery, 583 input I to the algorithm is the RADIUS User-Name attribute with 584 content of the form "user@realm"; the literal @ sign being the 585 separator between a local user identifier within a realm and its 586 realm. The use of multiple literal @ signs in a User-Name is 587 strongly discouraged; but if present, the last @ sign is to be 588 considered the separator. All previous instances of the @ sign are 589 to be considered part of the local user identifier. 591 For RADIUS DynAuth Server discovery, input I to the algorithm is the 592 domain name of the operator of a RADIUS realm as was communicated 593 during user authentication using the Operator-Name attribute 594 ([RFC5580], section 4.1). Only Operator-Name values with the 595 namespace "1" are supported by this algorithm - the input to the 596 algorithm is the actual domain name, preceeded with an "@" (but 597 without the "1" namespace identifier byte of that attribute). 599 Note well: The attribute User-Name is defined to contain UTF-8 text. 600 In practice, the content may or may not be UTF-8. Even if UTF-8, it 601 may or may not map to a domain name in the realm part. Implementors 602 MUST take possible conversion error paths into consideration when 603 parsing incoming User-Name attributes. This document describes 604 server discovery only for well-formed realms mapping to DNS domain 605 names in UTF-8 encoding. The result of all other possible contents 606 of User-Name is unspecified; this includes, but is not limited to: 608 Usage of separators other than @ 610 Encoding of User-Name in local encodings 611 UTF-8 realms which fail the conversion rules as per [RFC5891] 613 UTF-8 realms which end with a . ("dot") character. 615 For the last bullet point, "trailing dot", special precautions should 616 be taken to avoid problems when resolving servers with the algorithm 617 below: they may resolve to a RADIUS server even if the peer RADIUS 618 server only is configured to handle the realm without the trailing 619 dot. If that RADIUS server again uses NAI discovery to determine the 620 authoritative server, the server will forward the request to 621 localhost, resulting in a tight endless loop. 623 3.4.2. Output 625 Output O of the algorithm is a two-tuple consisting of: O-1) a set of 626 tuples {hostname; port; protocol; order/preference; Effective TTL} - 627 the set can be empty; and O-2) an integer: if the set in the first 628 part of the tuple is empty, the integer contains the Effective TTL 629 for backoff timeout, if the set is not empty, the integer is set to 0 630 (and not used). 632 3.4.3. Algorithm 634 The algorithm to determine the RADIUS server to contact is as 635 follows: 637 1. Determine P = (position of last "@" character) in I. 639 2. generate R = (substring from P+1 to end of I) 641 3. modify R according to agreed consortium procedures if applicable 643 4. convert R to a representation usable by the name resolution 644 library if needed 646 5. Initialize TIMER = 0; start TIMER. If TIMER reaches 647 DNS_TIMEOUT, continue at step 20. 649 6. Using the host's name resolution library, perform a NAPTR query 650 for R (see "Delay considerations" below). If the result is a 651 negative DNS response, O-2 = Effective TTL ( TTL value of the 652 SOA record ) and continue at step 13. If name resolution 653 returns with error, O-1 = { empty set }, O-2 = BACKOFF_TIME and 654 terminate. 656 7. Extract NAPTR records with service tag "aaa+auth", "aaa+acct", 657 "aaa+dynauth" as appropriate. Keep note of the protocol tag and 658 remaining TTL of each of the discovered NAPTR records. 660 8. If no records found, continue at step 13. 662 9. For the extracted NAPTRs, perform successive resolution as 663 defined in [RFC3958], section 2.2. An implementation MAY use 664 greedy result evaluation according to the NAPTR order/preference 665 fields (i.e. can execute the subsequent steps of this algorithm 666 for the highest-order entry in the set of results, and only 667 lookup the remainder of the set if necessary). 669 10. If the set of hostnames is empty, O-1 = { empty set }, O-2 = 670 BACKOFF_TIME and terminate. 672 11. O' = (set of {hostname; port; protocol; order/preference; 673 Effective TTL ( all DNS TTLs that led to this hostname ) } for 674 all terminal lookup results). 676 12. Proceed with step 18. 678 13. Generate R' = (prefix R with "_radiustls._tcp." and/or 679 "_radiustls._udp.") 681 14. Using the host's name resolution library, perform SRV lookup 682 with R' as label (see "Delay considerations" below). 684 15. If name resolution returns with error, O-1 = { empty set }, O-2 685 = BACKOFF_TIME and terminate. 687 16. If the result is a negative DNS response, O-1 = { empty set }, 688 O-2 = min { O-2, Effective TTL ( TTL value of the SOA record ) } 689 and terminate. 691 17. O' = (set of {hostname; port; protocol; order/preference; 692 Effective TTL ( all DNS TTLs that led to this result ) } for all 693 hostnames). 695 18. Generate O-1 by resolving hostnames in O' into corresponding A 696 and/or AAAA addresses: O-1 = (set of {IP address; port; 697 protocol; order/preference; Effective TTL ( all DNS TTLs that 698 led to this result ) } for all hostnames ), O-2 = 0. 700 19. For each element in O-1, test if the original request which 701 triggered dynamic discovery was received on {IP address; port}. 702 If yes, O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, 703 Terminate (see next section for a rationale). If no, O is the 704 result of dynamic discovery. Terminate. 706 20. O-1 = { empty set }, O-2 = BACKOFF_TIME, log error, Terminate. 708 3.4.4. Validity of results 710 The dynamic discovery algorithm is used by servers which do not have 711 sufficient configuration information to process an incoming request 712 on their own. If the discovery algorithm result contains the 713 server's own listening address (IP address and port), then this will 714 either lead to a tight loop (if that DNS entry has topmost priority, 715 the server would forward the request to itself, triggering dynamic 716 discovery again in a perpetual loop), or lead to a potential loop 717 with intermediate hops in between (the server could forward to 718 another host with a higher priority, which might use DNS itself and 719 forward the packet back to the first server). The underlying reason 720 that enables these loops is that the server executing the discovery 721 algorithm is seriously misconfigured in that it does not recognise 722 the request as one that is to be processed by itself. RADIUS has no 723 built-in loop detection, so any such loops would remain undetected. 724 So, if step 18 of the algorithm discovers such a possible-loop 725 situation, the algorithm should be aborted and an error logged. Note 726 that this safeguard does not provide perfect protection against 727 routing loops: other reasons include the possiblity that a subsequent 728 hop has a statically configured next-hop which leads to an earlier 729 host in the loop; or the algorithm execution was executed with greedy 730 result evaluation, and the own address was in a lower-priority branch 731 of the result set which was not retrieved from DNS at all. 733 After executing the above algorithm, the RADIUS server establishes a 734 connection to a home server from the result set. This connection can 735 potentially remain open for an indefinite amount of time. This 736 conflicts with the possibility of changing device and network 737 configurations on the receiving end. Typically, TTL values for 738 records in the name resolution system are used to indicate how long 739 it is safe to rely on the results of the name resolution. If these 740 TTLs are very low, thrashing of connections becomes possible; the 741 Effective TTL mitigates that risk. When a connection is open and the 742 smallest of the Effective TTL value which was learned during 743 discovering the server has not expired, subsequent new user sessions 744 for the realm which corresponds to that open connection SHOULD re-use 745 the existing connection and SHOULD NOT re-execute the dynamic 746 discovery algorithm nor open a new connection. To allow for a change 747 of configuration, a RADIUS server SHOULD re-execute the dynamic 748 discovery algorithm after the Effective TTL that is associated with 749 this connection has expired. The server MAY keep the session open 750 during this re-assessment to avoid closure and immediate re-opening 751 of the connection should the result not have changed. 753 Should the algorithm above terminate with O-1 = empty set, the RADIUS 754 server SHOULD NOT attempt another execution of this algorithm for the 755 same target realm before the timeout O-2 has passed. 757 3.4.5. Delay considerations 759 The host's name resolution library may need to contact outside 760 entities to perform the name resolution (e.g. authoritative name 761 servers for a domain), and since the NAI discovery algorithm is based 762 on uncontrollable user input, the destination of the lookups is out 763 of control of the server that performs NAI discovery. If such 764 outside entities are misconfigured or unreachable, the algorithm 765 above may need an unacceptably long time to terminate. Many RADIUS 766 implementations time out after five seconds of delay between Request 767 and Response. It is not useful to wait until the host name 768 resolution library signals a time-out of its name resolution 769 algorithms. The algorithm therefore control execution time with 770 TIMER. Execution of the NAI discovery algorithm SHOULD be non- 771 blocking (i.e. allow other requests to be processed in parallel to 772 the execution of the algorithm). 774 3.4.6. Example 776 Assume 778 a user from the Technical University of Munich, Germany, has a 779 RADIUS User-Name of "foobar@tu-m[U+00FC]nchen.example". 781 The name resolution library on the RADIUS forwarding server does 782 not have the realm tu-m[U+00FC]nchen.example in its forwarding 783 configuration, but uses DNS for name resolution and has configured 784 the use of Dynamic Discovery to discover RADIUS servers. 786 It is IPv6-enabled and prefers AAAA records over A records. 788 It is listening for incoming RADIUS/TLS requests on 192.0.2.1, TCP 789 /2083. 791 May the configuration variables be 793 DNS_TIMEOUT = 3 seconds 795 MIN_EFF_TTL = 60 seconds 797 BACKOFF_TIME = 3600 seconds 799 If DNS contains the following records: 801 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 802 "aaa+auth:radius.tls" "" _myradius._tcp.xn--tu-mnchen-t9a.example. 804 xn--tu-mnchen-t9a.example. IN NAPTR 50 50 "s" 805 "fooservice:bar.dccp" "" _abc123._def.xn--tu-mnchen-t9a.example. 807 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 10 2083 808 radsecserver.xn--tu-mnchen-t9a.example. 810 _myradius._tcp.xn--tu-mnchen-t9a.example. IN SRV 0 20 2083 811 backupserver.xn--tu-mnchen-t9a.example. 813 radsecserver.xn--tu-mnchen-t9a.example. IN AAAA 814 2001:0DB8::202:44ff:fe0a:f704 816 radsecserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.3 818 backupserver.xn--tu-mnchen-t9a.example. IN A 192.0.2.7 820 Then the algorithm executes as follows, with I = 821 "foobar@tu-m[U+00FC]nchen.example", and no consortium name mangling 822 in use: 824 1. P = 7 826 2. R = "tu-m[U+00FC]nchen.example" 828 3. NOOP 830 4. name resolution library converts R to xn--tu-mnchen-t9a.example 832 5. TIMER starts. 834 6. Result: 836 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" 837 _myradius._tcp.xn--tu-mnchen-t9a.example. 839 (TTL = 522) 50 50 "s" "fooservice:bar.dccp" "" 840 _abc123._def.xn--tu-mnchen-t9a.example. 842 7. Result: 844 (TTL = 47) 50 50 "s" "aaa+auth:radius.tls" "" 845 _myradius._tcp.xn--tu-mnchen-t9a.example. 847 8. NOOP 849 9. Successive resolution performs SRV query for label 850 _myradius._tcp.xn--tu-mnchen-t9a.example, which results in 851 (TTL 499) 0 10 2083 radsec.xn--tu-mnchen-t9a.example. 853 (TTL 2200) 0 20 2083 backup.xn--tu-mnchen-t9a.example. 855 10. NOOP 857 11. O' = { 859 (radsec.xn--tu-mnchen-t9a.example.; 2083; RADIUS/TLS; 10; 860 60), 862 (backup.xn--tu-mnchen-t9a.example.; 2083; 20; 60) 864 } // minimum TTL is 47, up'ed to MIN_EFF_TTL 866 12. Continuing at 18. 868 13. (not executed) 870 14. (not executed) 872 15. (not executed) 874 16. (not executed) 876 17. (not executed) 878 18. O-1 = { 880 (2001:0DB8::202:44ff:fe0a:f704; 2083; RADIUS/TLS; 10; 60), 882 (192.0.2.7; 2083; RADIUS/TLS; 20; 60) 884 }; O-2 = 0 886 19. No match with own listening address; terminate with tuple (O-1, 887 O-2) from previous step. 889 The implementation will then attempt to connect to two servers, with 890 preference to [2001:0DB8::202:44ff:fe0a:f704]:2083 using the RADIUS/ 891 TLS protocol. 893 4. Security Considerations 895 When using DNS without DNSSEC security extensions and validation for 896 all of the replies to NAPTR, SRV and A/AAAA requests as described in 897 section Section 3, the result O can not be trusted. Even if it can 898 be trusted (i.e. DNSSEC is in use), actual authorization of the 899 discovered server to provide service for the given realm needs to be 900 verified. A mechanism from section Section 2.1.1.3 or equivalent 901 MUST be used to verify authorization. 903 The algorithm has a configurable completion time-out DNS_TIMEOUT 904 defaulting to three seconds for RADIUS' operational reasons. The 905 lookup of DNS resource records based on unverified user input is an 906 attack vector for DoS attacks: an attacker might intentionally craft 907 bogus DNS zones which take a very long time to reply (e.g. due to a 908 particularly byzantine tree structure, or artificial delays in 909 responses). 911 To mitigate this DoS vector, implementations SHOULD consider rate- 912 limiting either their amount of new executions of the dynamic 913 discovery algorithm as a whole, or the amount of intermediate 914 responses to track, or at least the number of pending DNS queries. 915 Implementations MAY choose lower values than the default for 916 DNS_TIMEOUT to limit the impact of DoS attacks via that vector. They 917 MAY also continue their attempt to resolve DNS records even after 918 DNS_TIMEOUT has passed; a subsequent request for the same realm might 919 benefit from retrieving the results anyway. The amount of time to 920 spent waiting for a result will influence the impact of a possible 921 DoS attack; the waiting time value is implementation dependent and 922 outside the scope of this specification. 924 With Dynamic Discovery being enabled for a RADIUS Server, and 925 depending on the deployment scenario, the server may need to open up 926 its target IP address and port for the entire internet, because 927 arbitrary clients may discover it as a target for their 928 authentication requests. If such clients are not part of the roaming 929 consortium, the RADIUS/TLS connection setup phase will fail (which is 930 intended) but the computational cost for the connection attempt is 931 significant. With the port for a TLS-based service open, the RADIUS 932 server shares all the typical attack vectors for services based on 933 TLS (such as HTTPS, SMTPS, ...). Deployments of RADIUS/TLS with 934 Dynamic Discovery should consider these attack vectors and take 935 appropriate counter-measures (e.g. blacklisting known-bad IPs on a 936 firewall, rate-limiting new connection attempts, etc.). 938 5. Privacy Considerations 940 The classic RADIUS operational model (known, pre-configured peers, 941 shared secret security, mostly plaintext communication) and this new 942 RADIUS dynamic discovery model (peer discovery with DNS, PKI security 943 and packet confidentiality) differ significantly in their impact on 944 the privacy of end users trying to authenticate to a RADIUS server. 946 With classic RADIUS, traffic in large environments gets aggregated by 947 statically configured clearinghouses. The packets sent to those 948 clearinghouses and their responses are mostly unprotected. As a 949 consequence, 951 o All intermediate IP hops can inspect most of the packet payload in 952 clear text, including the User-Name and Calling-Station-Id 953 attributes, and can observe which client sent the packet to which 954 clearinghouse. This allows the creation of mobility profiles for 955 any passive observer on the IP path. 957 o The existence of a central clearinghouse creates an opportunity 958 for the clearinghouse to trivially create the same mobility 959 profiles. The clearinghouse may or may not be trusted not to do 960 this, e.g. by sufficiently threatening contractual obligations. 962 o In addition to that, with the clearinghouse being a RADIUS 963 intermediate in possession of a valid shared secret, the 964 clearinghouse can observe and record even the security-critical 965 RADIUS attributes such as User-Password. This risk may be 966 mitigated by choosing authentication payloads which are 967 cryptographically secured and do not use the attribute User- 968 Password - such as certain EAP types. 970 o There is no additional information disclosure to parties outside 971 the IP path between the RADIUS client and server (in particular, 972 no DNS servers learn about realms of current ongoing 973 authentications). 975 With RADIUS and dynamic discovery, 977 o This protocol allows for RADIUS clients to identify and directly 978 connect to the RADIUS home server. This can eliminate the use of 979 clearinghouses to do forwarding of requests, and it also 980 eliminates the ability of the clearinghouse to then aggregate the 981 user information that flows through it. However, there exist 982 reasons why clearinghouses might still be used. One reason to 983 keep a clearinghouse is to act as a gateway for multiple backends 984 in a company; another reason may be a requirement to sanitise 985 RADIUS datagrams (filter attributes, tag requests with new 986 attributes, ... ). 988 o Even where intermediate proxies continue to be used for reasons 989 unrelated to dynamic discovery, the number of such intermediates 990 may be reduced by removing those proxies which are only deployed 991 for pure request routing reasons. This reduces the number of 992 entities which can inspect the RADIUS traffic. 994 o RADIUS clients which make use of dynamic discovery will need to 995 query the Domain Name System, and use a user's realm name as the 996 query label. A passive observer on the IP path between the RADIUS 997 client and the DNS server(s) being queried can learn that a user 998 of that specific realm was trying to authenticate at that RADIUS 999 client at a certain point in time. This may or may not be 1000 sufficient for the passive observer to create a mobility profile. 1001 During the recursive DNS resolution, a fair number of DNS servers 1002 and the IP hops in between those get to learn that information. 1003 Not every single authentication triggers DNS lookups, so there is 1004 no one-to-one relation of leaked realm information and the number 1005 of authentications for that realm. 1007 o Since dynamic discovery operates on a RADIUS hop-by-hop basis, 1008 there is no guarantee that the RADIUS payload is not transmitted 1009 between RADIUS systems which do not make use of this algorithm, 1010 and possibly using other transports such as RADIUS/UDP. On such 1011 hops, the enhanced privacy is jeopardized. 1013 In summary, with classic RADIUS, few intermediate entities learn very 1014 detailed data about every ongoing authentications, while with dynamic 1015 discovery, many entities learn only very little about recently 1016 authenticated realms. 1018 6. IANA Considerations 1020 This document requests IANA registration of the following entries in 1021 existing registries: 1023 o S-NAPTR Application Service Tags registry 1025 * aaa+auth 1027 * aaa+acct 1029 * aaa+dynauth 1031 o S-NAPTR Application Protocol Tags registry 1033 * radius.tls 1035 * radius.dtls 1037 This document reserves the use of the "_radiustls" and "_radiusdtls" 1038 Service labels. 1040 This document requests the creation of a new IANA registry named 1041 "RADIUS/TLS SRV Protocol Registry" with the following initial 1042 entries: 1044 o _tcp 1046 o _udp 1048 This specification allocates a X.509 certificate property "NAIRealm" 1049 as per section Section 2.2 above, see placeholders "XXX". There is 1050 currently no IANA registry for the subjectAltName:otherName 1051 namespace. The authority for this namespace appears to be the PKIX 1052 working group. Before issuing the RFC, IANA should liaise with PKIX 1053 to ensure that a value for NAIRealm is issued; IANA should 1054 subsequently, prior to issuing the RFC, update the placeholders in 1055 said section. 1057 7. References 1059 7.1. Normative References 1061 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1062 Requirement Levels", BCP 14, RFC 2119, March 1997. 1064 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1065 specifying the location of services (DNS SRV)", RFC 2782, 1066 February 2000. 1068 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 1069 "Remote Authentication Dial In User Service (RADIUS)", RFC 1070 2865, June 2000. 1072 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1074 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 1075 Service Location Using SRV RRs and the Dynamic Delegation 1076 Discovery Service (DDDS)", RFC 3958, January 2005. 1078 [RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. 1079 Aboba, "Dynamic Authorization Extensions to Remote 1080 Authentication Dial In User Service (RADIUS)", RFC 5176, 1081 January 2008. 1083 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1084 Housley, R., and W. Polk, "Internet X.509 Public Key 1085 Infrastructure Certificate and Certificate Revocation List 1086 (CRL) Profile", RFC 5280, May 2008. 1088 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 1089 Aboba, "Carrying Location Objects in RADIUS and Diameter", 1090 RFC 5580, August 2009. 1092 [RFC5891] Klensin, J., "Internationalized Domain Names in 1093 Applications (IDNA): Protocol", RFC 5891, August 2010. 1095 [I-D.ietf-radext-dtls] 1096 DeKok, A., "DTLS as a Transport Layer for RADIUS", draft- 1097 ietf-radext-dtls-07 (work in progress), October 2013. 1099 [RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, 1100 "Transport Layer Security (TLS) Encryption for RADIUS", 1101 RFC 6614, May 2012. 1103 [I-D.ietf-radext-nai] 1104 DeKok, A., "The Network Access Identifier", draft-ietf- 1105 radext-nai-05 (work in progress), November 2013. 1107 7.2. Informative References 1109 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 1110 Authentication Protocol (EAP) Method Requirements for 1111 Wireless LANs", RFC 4017, March 2005. 1113 Appendix A. Appendix A: ASN.1 Syntax of NAIRealm 1115 PKIXServiceNameSAN93 {iso(1) identified-organization(3) dod(6) 1116 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 1117 id-mod-dns-srv-name-93(40) } 1119 DEFINITIONS EXPLICIT TAGS ::= 1121 BEGIN 1123 -- EXPORTS ALL -- 1125 IMPORTS 1127 id-pkix 1128 FROM PKIX1Explicit-2009 1129 {iso(1) identified-organization(3) dod(6) internet(1) 1130 security(5) mechanisms(5) pkix(7) id-mod(0) 1131 id-mod-pkix1-explicit-02(51)} 1132 -- from RFC 5280 1134 OTHER-NAME 1135 FROM PKIX1Implicit-2009 1136 {iso(1) identified-organization(3) dod(6) internet(1) security(5) 1137 mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59)} 1138 ; 1140 -- Service Name Object Identifier 1142 id-on OBJECT IDENTIFIER ::= { id-pkix 8 } 1144 id-on-nai OBJECT IDENTIFIER ::= { id-on 99999 } 1146 -- Service Name 1148 naiRealm OTHER-NAME ::= { NAIRealm IDENTIFIED BY { id-on-nai }} 1150 NAIRealm ::= UTF8String (SIZE (1..MAX)) 1152 END 1154 Authors' Addresses 1156 Stefan Winter 1157 Fondation RESTENA 1158 6, rue Richard Coudenhove-Kalergi 1159 Luxembourg 1359 1160 LUXEMBOURG 1162 Phone: +352 424409 1 1163 Fax: +352 422473 1164 EMail: stefan.winter@restena.lu 1165 URI: http://www.restena.lu. 1167 Mike McCauley 1168 Open Systems Consultants 1169 9 Bulbul Place 1170 Currumbin Waters QLD 4223 1171 AUSTRALIA 1173 Phone: +61 7 5598 7474 1174 Fax: +61 7 5598 7070 1175 EMail: mikem@open.com.au 1176 URI: http://www.open.com.au.