idnits 2.17.1 draft-calhoun-diameter-authent-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 116 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 160 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 76: '... MUST This word, or the adject...' RFC 2119 keyword, line 80: '... MUST NOT This phrase means that t...' RFC 2119 keyword, line 83: '... SHOULD This word, or the adject...' RFC 2119 keyword, line 89: '... MAY This word, or the adject...' RFC 2119 keyword, line 91: '...hich does not include this option MUST...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... This docum...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '... groups may ...' == Line 20 has weird spacing: '...iate to use ...' == Line 21 has weird spacing: '... as referen...' == (111 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 1998) is 9539 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 541, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2058 (ref. '1') (Obsoleted by RFC 2138) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-00 -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-authent-01.txt 5 Date: March 1998 7 DIAMETER 8 User Authentication Extensions 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months. 19 Internet-Drafts may be updated, replaced, or obsoleted by other 20 documents at any time. It is not appropriate to use Internet-Drafts 21 as reference material or to cite them other than as a ``working 22 draft'' or ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 27 munnari.oz.au. 29 Abstract 31 DIAMETER is a management protocol used between Network Access Servers 32 and DIAMETER Servers for authentication, authorization, accounting of 33 dial-up users. A considerable amount of effort was put into the design 34 of this protocol to ensure that an implementation could support both 35 DIAMETER and RADIUS at the same time. 37 This document details the RADIUS authentication messages and how they 38 may be used with the DIAMETER protocol. 40 Table of Contents 42 1.0 Introduction 43 1.1 Specification of Requirements 44 2.0 Command Name and Command Code 45 3.0 Command Meanings 46 3.1 Domain-Discovery-Request 47 3.2 Domain-Discovery-Response 48 3.3 Authentication-Request 49 3.4 Authentication-Success 50 3.5 Authentication-Failure 51 4.0 Protocol Definition 52 4.1 RADIUS Proxies 53 4.2 DIAMETER Proxies 54 4.2 Domain Discovery 55 5.0 References 56 6.0 Authors' Addresses 58 1.0 Introduction 60 This document specifies extensions to the original RADIUS[1] 61 authentication messages. 63 There exists a scenario where services providers wish to proxy the 64 authentication of a user to a remote DIAMETER Server, yet wishes to 65 perform the authorization for the said user. 67 There are also many instances where a NAS may wish to simply 68 authenticate a user and not have any authorization assigned to the 69 request. 71 1.1 Specification of Requirements 73 In this document, several words are used to signify the requirements 74 of the specification. These words are often capitalized. 76 MUST This word, or the adjective "required", means that the 77 definition is an absolute requirement of the 78 specification. 80 MUST NOT This phrase means that the definition is an absolute 81 prohibition of the specification. 83 SHOULD This word, or the adjective "recommended", means that 84 there may exist valid reasons in particular circumstances 85 to ignore this item, but the full implications must be 86 understood and carefully weighed before choosing a 87 different course. 89 MAY This word, or the adjective "optional", means that this 90 item is one of an allowed set of alternatives. An 91 implementation which does not include this option MUST 92 be prepared to interoperate with another implementation 93 which does include the option. 95 2.0 Command Name and Command Code 97 Command Name: Domain-Discovery-Request 98 Command Code: 6 100 Command Name: Domain-Discovery-Response 101 Command Code: 7 103 Command Name: Authentication-Request 104 Command Code: 8 106 Command Name: Authentication-Success 107 Command Code: 9 109 Command Name: Authentication-Failure 110 Command Code: 10 112 3.0 Command Meanings 114 3.1 Domain-Discovery-Request 116 Description 118 The Domain-Discovery-Request message is used by a DIAMETER device 119 wishing to get contact information about a domain's home 120 authentication server as well as to receive password policy 121 information. This message MUST contain the User-Name attribute in 122 order to pass along the user's domain information. 124 A summary of the Domain-Discovery-Request packet format is shown 125 below. The fields are transmitted from left to right. 127 0 1 2 3 128 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Attribute Type | Length | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 | Flags | Command Type | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Code 137 256 DIAMETER Command 139 Length 141 The length of this attribute MUST be 7. 143 Flags 145 The flag field MUST have bit 1 (Mandatory Support) set. 147 Command Type 149 The Command Type field MUST be set to 6 (Domain-Discovery-Request). 151 3.2 Domain-Discovery-Response 153 Description 155 The Domain-Discovery-Response message is sent in response to the 156 Domain-Discovery-Request message by the domain's Home 157 authentication server. The message MUST contain either the X509- 158 Certificate or the X509-Certificate-URL attribute and MAY contain 159 the Password-Policy attribute. 161 A summary of the Domain-Discovery-Response packet format is shown 162 below. The fields are transmitted from left to right. 164 0 1 2 3 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Attribute Type | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Flags | Command Type | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Code 174 256 DIAMETER Command 176 Length 178 The length of this attribute MUST be 7. 180 Flags 182 The flag field MUST have bit 1 (Mandatory Support) set. 184 Command Type 186 The Command Type field MUST be set to 7 (Domain-Discovery- 187 Response). 189 3.3 Authentication-Request 191 Description 193 The Authentication-Request message is used in order to request 194 authentication and authorization for a given user. Note that this 195 command does not require the presence of a user name as the 196 credentials used MAY be a telephone number (i.e. DNIS, ANI) 197 instead. 199 Note that the flag field MAY be used in this command in order to 200 indicate that either Authentication-Only or Authorization-Only is 201 required for the request. If the Authentication-Only bit is set the 202 response MUST NOT include any authorization information. At least 203 one of the Authenticate/Authorize flag bits MUST be set. 205 A summary of the Authentication-Request packet format is shown 206 below. The fields are transmitted from left to right. 208 0 1 2 3 209 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Attribute Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Flags | Command Type | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 Code 218 256 DIAMETER Command 220 Length 222 The length of this attribute MUST be 7. 224 Flags 226 The flag field MUST have bit 1 (Mandatory Support) set. In 227 addition, the following bits may be used (note these bits are 228 mutually exclusive): 230 bit 3 - Authenticate-Only 231 bit 4 - Authorize-Only 233 Command Type 235 The Command Type field MUST be set to 8 (Authentication-Request). 237 3.4 Authentication-Success 239 Description 241 The Authentication-Success message is used in order to indicate 242 that Authentication (or authorization) was successful. If 243 authorization was requested a list of AVPs with the authorization 244 information MUST be attached to the message (see [1]). 246 Note that the flag field MUST be set to the same value that was 247 found in the Authentication-Request message. 249 A summary of the Access-Request packet format is shown below. The 250 fields are transmitted from left to right. 252 0 1 2 3 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Attribute Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Flags | Command Type | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Code 262 256 DIAMETER Command 264 Length 266 The length of this attribute MUST be 7. 268 Flags 270 following bits may be used (note these bits are mutually 271 exclusive): 273 bit 3 - Authenticate-Only 274 bit 4 - Authorize-Only 276 Command Type 278 The Command Type field MUST be set to 9 (Authentication-Success). 280 3.5 Authentication-Failure 282 Description 283 The Authentication-Failure message is used in order to indicate 284 that Authentication (or authorization) was unsuccessful. The list 285 of AVPs that may be attached to this message can be found in [1]. 287 Note that the flag field MUST be set to the same value that was 288 found in the Authentication-Request message. 290 A summary of the Access-Request packet format is shown below. The 291 fields are transmitted from left to right. 293 0 1 2 3 294 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Attribute Type | Length | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Flags | Command Type | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Code 303 256 DIAMETER Command 305 Length 307 The length of this attribute MUST be 7. 309 Flags 311 following bits may be used (note these bits are mutually 312 exclusive): 314 bit 3 - Authenticate-Only 315 bit 4 - Authorize-Only 317 Command Type 319 The Command Type field MUST be set to 10 (Authentication-Failure). 321 4.0 Protocol Definition 323 This section will outline how the DIAMETER Authentication Extension 324 can be used. 326 4.1 RADIUS Proxies 328 In today's dial up networks the RADIUS protocol is used to 329 authentication, authorize and perform accounting for dial-up users. 330 However, it has become common practice to make use of RADIUS Servers 331 known as proxies. 333 The use of proxies has become widespread especially with the 334 popularity of Internet Roaming[4]. In this example a user has a 335 single user account with a local service provider. When this user 336 roams outside of his ISPs service area, it is possible for the user 337 to connect to another service provider (see [4] for more details). 339 In this scenario, the new service provider (ISPB) provides internet 340 access for the user through a NAS (NASB). ISPB owns an authentication 341 server (RADB), which proxies the authentication request to the user's 342 original provider's authentication server (RADA). 344 (Access-Request) (Access-Request) 345 +------+ -----> +------+ ------> +------+ 346 | | | | | | 347 | NASB +--------------------+ RADB +--------------------+ RADA + 348 | | | | | | 349 +------+ <----- +------+ <------ +------+ 350 (Access-Accept) (Access-Accept) 352 The example shown above NASB generates an authentication request on 353 behalf of the dial-in user to the RADB Authentication server. In this 354 case, the user's identity would include a domain identifier [3] that 355 would enable RADB to identify the authentication server (i.e. 356 user@ISPA.com). 358 The RADB server then forwards the request to RADA which authenticates 359 the user based on information found within the request. If 360 successfully authentication the RADA server returns a successful 361 response along with authorization information. If the user 362 authentication fails RADA replies with a failed response. 364 In the past this model has caused much concern over it's security 365 implication. The model is much worse in the model where there exists 366 an intermediate provider between ISPB and ISPA (say ISPC). The 367 following diagram depicts such an example where RADB must forward any 368 requests for RADA through RADC. 370 (Accounting-Request) (Accounting-Request) 371 +------+ -----> +------+ ------> +------+ 372 | | | | | | 373 | RADB +--------------------+ RADC +--------------------+ RADA + 374 | | | | | | 375 +------+ <----- +------+ <------ +------+ 376 (Accounting-Response) (Accounting-Response) 378 The problem with the above scenario is that complete trust is placed 379 in RADC (and hence ISPC) since it is very simple to modify any 380 attributes found within the request or the response. The example 381 shows an accounting request sent from RADB to RADA through RADC. The 382 following is a list of a few attacks which can be generated by a 383 malicious proxy: 385 - Generating Accounting Records by replaying old 386 authentication/accounting records. In this example it is very 387 simple for RADC to simple retain old packets and replay then at a 388 later date. This will cause RADA to "pay" for services which were 389 never rendered. 391 - Modify Attributes within the request or response. In this case 392 RADC can modify attributes, such as the length of the call, that 393 would fool RADA into believing the call was longer than in reality. 395 - Stealing PAP Passwords is another problem with today's proxies. 396 In the current model PAP passwords are encrypted using a shared 397 secret which is shared between each hop in the proxy chain. In this 398 case each hop has the opportunity to decrypt, and possibly save for 399 future use, the user's password. fool RADA into believing that 401 Given the problems identified above with the current proxy model it 402 is necessary to create a mechanism which allows for non-repudiation, 403 end-to-end data integrity as well as end-to-end encryption. Given the 404 current encryption technology this can only be achieved with the use 405 of asymetric encryption and digital signatures. 407 4.2 DIAMETER Proxies 409 The DIAMETER protocol also the use of proxies in order to keep the 410 existing arrangements while migrating from RADIUS to DIAMETER. 411 However since DIAMETER makes use of asymetric encryption and digital 412 signatures it solves many of the problems shown above. 414 (Access-Request) (Access-Request) 415 +------+ -----> +------+ ------> +------+ 416 | | | | | | 417 | NASB +--------------------+ DIA2 +--------------------+ DIA1 + 418 | | | | | | 419 +------+ <----- +------+ <------ +------+ 420 (Access-Accept) (Access-Accept) 422 In this example NASB generates an Authentication-Request that is 423 forwarded to DIA2. The Authentication-Request contains a digital 424 signature AVP which "protects" all mandatory (or non-editable) AVPs 425 within the request. All AVPs which may be modified, or removed appear 426 after the digital signature AVP. Once DIA2 receives the request, it 427 MAY authenticate the request to ensure that it was originated by NASB 428 (verifying the signature is not necessary if the link between NASB 429 and DIA2 is secured using IPSEC). 431 The DIA2 Server may then add new attributes to the request. All 432 mandatory AVPs MUST be present prior to the non mandatory AVPs and 433 MUST be preceeded by a Digital Signature AVP (using DIA2's private 434 key). Note that all non-mandatory AVPs added to the packet by NASB 435 must appear after DIA2's digital signature AVP. The message is then 436 forwarded towards the DIA1 server. 438 Since all packets between NASB and DIA1 must flow through DIA2, it is 439 not possible to use IPSEC between both hosts. Therefore DIA1 MUST 440 validate NASB's digital signature AVP. However it is not necessary to 441 validate DIA2's digital signature if the link between DIA2 and DIA1 442 is secured using IPSEC. 444 This mechanism now provides a method for DIA1 to prove that NASB was 445 the initiator of the request (note that DIAMETER also includes a 446 timestap to prevent replay attacks). It also provides a method of 447 ensuring that RADB cannot modify any "non-editable" attributes (such 448 as length of call, etc). 450 In addition, this same mechanism can be used for end to end 451 encryption of AVPs. In the case where NASB needs to encrypt an AVP it 452 is done using asymetric encryption using DIA1's public key. This 453 ensures that only RADA can decrypt the AVP. 455 An attack has been identified in this proposal which allows a 456 malicous man in the middle attack as shown in the following diagram. 458 (Access-Request) (Access-Request) (Access-Request) 459 +------+ -----> +------+ -----> +------+ -----> +------+ 460 | | | | | | | | 461 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 + 462 | | | | | | | | 463 +------+ <----- +------+ <----- +------+ <----- +------+ 464 (Access-Accept) (Access-Accept) (Access-Accept) 466 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 467 removes the AVPs added by DIA2 and inserts its own AVPs (posibly by 468 trying to convince DIA1 to pay DIA3 for the services). This attack 469 can be prevented by supporting a new Next-Hop AVP. In this case when 470 NASB prepares a request it inserts a non-editable Next-Hop AVP which 471 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 472 as the next hop. 474 This mechanism ensures that a man in the middle cannot alter the 475 packet by overriding the previous hop's additions and signature. DIA1 476 could easily validate the packet's path with the use of the Next-Hop 477 AVPs. 479 4.3 Domain Discovery 481 The Domain Discovery message set is very useful in determining the 482 Home authentication server, the password policies for the domain, as 483 a mechanism to retrieve a certificate (or a pointer to a 484 certificate). 486 The following example shows a case where DIA1 needs to communicate 487 with DIA3. In this example it is necessary to use DIA2 as a proxy in 488 order for both ISPs to communicate. Although this MAY be desireable 489 in some business models, there are cases where it is beneficial to 490 remove the proxy altogether and allow both DIA3 and DIA2 to 491 communicate in a secure fashion. 493 (DD-Request) (DD-Request) 494 +------+ -----> +------+ ------> +------+ 495 | | | | | | 496 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 + 497 | | | | | | 498 +------+ <----- +------+ <------ +------+ 499 (DD-Response) (DD-Response) 501 The way the Domain Discovery works is that prior to sending out an 502 authentication request DIA1 would issue a Domain Discovery message 503 towards DIA2. This message is protected with the digital signature as 504 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 505 including the Next-Hop and the digital signature AVP. 507 When DIA3 receives the request, it MUST save the certificate (or the 508 pointer to the certificate) and respond back including the local 509 password policy, DIA3's certificate, it's contact information (i.e. 510 IP address) and protect the response with the digital signature. 512 Note that in all cases the TimeStamp AVP is also present to ensure no 513 reply packets are accepted. 515 When DIA2 receives the packet, it must add the Next-Hop AVP as well 516 as the digital signature AVP. When DIA1 receives the packet is now 517 knows a direct route to communicate with DIA3 since the contact 518 information is present in the response. The fact that both DIA1 and 519 DIA3 can now communicate directly allows both peers to use IPSEC to 520 protect the message exchange (note that it MAY be desirable to also 521 use the digital signature in order to keep the information in the 522 DIAMETER logs). 524 (Authentication-Request) 525 +------+ -----> +------+ 526 | | | | 527 | DIA1 +--------------------+ DIA3 + 528 | | | | 529 +------+ <----- +------+ 530 (Authentication-Response) 532 In addition, the password policy is also present which can indicate 533 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 535 Note that the Domain-Request/Response MAY include the Features- 536 Supported AVPs. 538 5.0 References 540 [1] Rigney, et alia, "RADIUS", RFC-2058, Livingston, January 1997 541 [2] P. R. Calhoun, A. Rubens, "DIAMETER Base Protocol", 542 draft-calhoun-diameter-00.txt, February 1998. 543 [3] B. Aboba. "The Network Access Identifier." Internet-Draft, 544 August 1997. 545 [4] Aboba, Zorn, "Dialup Roaming Requirements", Internet-Draft, 546 July 1997. 548 6.0 Authors' Addresses 550 Questions about this memo can be directed to: 552 Pat R. Calhoun 553 Technology Development 554 Sun Microsystems, Inc. 555 15 Network Circle 556 Menlo Park, California, 94025 557 USA 559 Phone: 1-847-548-9587 560 Fax: 1-650-786-6445 561 E-mail: pcalhoun@toast.net