idnits 2.17.1 draft-calhoun-diameter-proxy-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages 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 4 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 92: '... MUST This word, or the adjecti...' RFC 2119 keyword, line 96: '... MUST NOT This phrase means that th...' RFC 2119 keyword, line 99: '... SHOULD This word, or the adjecti...' RFC 2119 keyword, line 105: '... MAY This word, or the adjecti...' RFC 2119 keyword, line 107: '...hich does not include this option MUST...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 889, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 892, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 894, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 897, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 899, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 901, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 903, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 907, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2138 (ref. '1') (Obsoleted by RFC 2865) == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-05 -- Possible downref: Normative reference to a draft: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '3') -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '5') -- No information found for draft-calhoun-diameter-authen - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '8') -- Unexpected draft version: The latest known version of draft-hoffman-pkcs-rsa-encrypt is -02, but you're referring to -03. (However, the state information for draft-calhoun-diameter-authen is not up-to-date. The last update was unsuccessful) ** Downref: Normative reference to an Informational draft: draft-hoffman-pkcs-rsa-encrypt (ref. '9') == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-framework-02 -- Possible downref: Normative reference to a draft: ref. '10' ** Downref: Normative reference to an Informational draft: draft-ietf-roamops-auth (ref. '11') Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 8 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-proxy-01.txt William Bulley 5 Date: August 1998 Merit Network, Inc. 7 DIAMETER 8 Proxy Server Extensions 10 Status of this Memo 12 This document is an individual contribution for consideration by the 13 AAA Working Group of the Internet Engineering Task Force. Comments 14 should be submitted to the diameter@ipass.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This DIAMETER Extension defines commands and AVPs that are used when 40 DIAMETER messages must be proxied by DIAMETER Servers. This extension 41 is intended to clearly define how proxying can be done with DIAMETER. 43 Table of Contents 45 1.0 Introduction 46 1.1 Definitions 47 1.2 Terminology 48 2.0 Command Codes 49 2.1 Domain-Discovery-Request (DDR) 50 2.2 Domain-Discovery-Answer (DDA) 51 3.0 DIAMETER AVPs 52 3.1 Proxy-State 53 3.2 Digital-Signature 54 3.3 X509-Certificate 55 3.4 X509-Certificate-URL 56 3.5 Next-Hop 57 4.0 Protocol Definition 58 4.1 Data Integrity 59 4.1.1 Using Digital Signatures 60 4.1.1 Using Mixed Data Integrity AVPs 61 4.2 AVP Data Encryption 62 4.2.1 AVP Encryption with Public Keys 63 4.3 Public Key Cryptography Support 64 4.3.1 X509-Certificate 65 4.3.2 X509-Certificate-URL 66 4.3.3 Static Public Key Configuration 67 5.0 References 68 6.0 Acknowledgements 69 7.0 Author's Address 71 1.0 Introduction 73 Many services, including ROAMOPS and MobileIP, have a requirement for 74 DIAMETER Server to proxy a request to another DIAMETER Server. The 75 concept of proxying AAA requests was introduced by RADIUS and has 76 been in use for many years. 78 Unfortunately due to the fact that RADIUS only supports hop-by-hop 79 security, where each node has a security association with the next 80 hop, this does introduce some security flaws. Specifically a 81 fraudulent proxy server can modify some portions of an AAA request in 82 order to make the next hop improperly believe that some services were 83 rendered. For example, a DIAMETER Proxy Server could modify an 84 accounting request, such as the number of bytes that a user 85 transfered, and the end system would have no way of determining that 86 this change occured. 88 1.1 Definitions 89 In this document, several words are used to signify the requirements 90 of the specification. These words are often capitalized. 92 MUST This word, or the adjective "required", means that the 93 definition is an absolute requirement of the 94 specification. 96 MUST NOT This phrase means that the definition is an absolute 97 prohibition of the specification. 99 SHOULD This word, or the adjective "recommended", means that 100 there may exist valid reasons in particular circumstances 101 to ignore this item, but the full implications must be 102 understood and carefully weighed before choosing a 103 different course. 105 MAY This word, or the adjective "optional", means that this 106 item is one of an allowed set of alternatives. An 107 implementation which does not include this option MUST 108 be prepared to interoperate with another implementation 109 which does include the option. 111 2.0 Command Codes 113 This document defines the following DIAMETER Commands. All DIAMETER 114 implementations supporting this extension MUST support all of the 115 following commands: 117 Command Name Command Code 118 ----------------------------------- 119 Domain-Discovery-Request 261 120 Domain-Discovery-Answer 262 122 2.1 Domain-Discovery-Request (DDR) 124 Description 126 The Domain-Discovery-Request message is used by a DIAMETER device 127 wishing to get contact information about a domain's home 128 authentication server as well as to receive password policy 129 information. This message MUST contain the User-Name attribute in 130 order to pass along the user's domain information. 132 It is not necessary for an implementation to issue a DDR in order 133 to make use of a proxy server. 135 The X509-Certificate or the X509-Certificate-URL [2] MUST be 136 present in this message in order to inform the home authentication 137 server of the issuing host's certificate. 139 At least one Extension-Id AVP MUST be present in the DDR in order 140 to inform the peer about the locally supported extensions. 142 Message Format 144 ::= 145 146 147 [] 148 149 150 [] 151 [] 152 153 154 { || 155 ::= 230 231 232 [] 233 234 [] 235 236 237 [] 238 [] 239 240 241 { || 242 +------+ ------> +------+ 565 | | | | | | 566 | NASB +--------------------+ DIA2 +--------------------+ DIA1 | 567 | | | | | | 568 +------+ <----- +------+ <------ +------+ 569 (Answer) (Answer) 571 In this example NASB generates a Request that is forwarded to DIA2. 572 The Request contains a digital signature AVP which "protects" all 573 mandatory (or non-editable) AVPs within the request. All AVPs which 574 may be modified, or removed appear after the digital signature AVP. 575 Once DIA2 receives the request, it MAY authenticate the request to 576 ensure that it was originated by NASB (verifying the signature is not 577 necessary if the link between NASB and DIA2 is secured using IPSEC). 579 The DIA2 Server SHOULD add the Proxy-State AVP, which contains opaque 580 data that MUST be present in the response and is used to identify 581 state information related to the request or response. If the Proxy- 582 State AVP is already present in the request, it MUST be replaced with 583 DIA2's Proxy-State AVP. This means that the Proxy-State AVP cannot be 584 protected end-to-end. The Server MAY also add other new AVPs to the 585 request. All AVPs that are protected by the Digital-Signature MUST 586 have the 'P' bit set, and all AVPs MUST preceed the Digital-Signature 587 AVP. The message is then forwarded towards the DIA1 server. 589 Since all packets between NASB and DIA1 must flow through DIA2, it is 590 not possible to use IPSEC between them, therefore the digital 591 signature must be present within the DIAMETER protocol itself. NASB 592 and DIA1 do not need to validate the digital signature AVP if the 593 link between themselves and DIA2 is secured using IP Security. 595 This mechanism now provides a method for DIA1 to prove that NASB was 596 the initiator of the request (note that DIAMETER also includes a 597 timestap to prevent replay attacks). It also provides a method of 598 ensuring that DIA2 cannot modify any protected AVPs (such as length 599 of call, etc.). 601 In addition, this same mechanism can be used for end-to-end 602 encryption of AVPs. In the case where NASB needs to encrypt an AVP it 603 is done using asymetric encryption using DIA1's public key. This 604 ensures that only DIA1 can decrypt the AVP. 606 An attack has been identified in this proposal which allows a 607 malicous man in the middle attack as shown in the following diagram. 609 (Request) (Request) (Request) 610 +------+ -----> +------+ -----> +------+ -----> +------+ 611 | | | | | | | | 612 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 613 | | | | | | | | 614 +------+ <----- +------+ <----- +------+ <----- +------+ 615 (Answer) (Answer) (Answer) 617 In this example, DIA3 traps packets generated from DIA2 towards DIA1, 618 removes the AVPs added by DIA2 and inserts its own AVPs (possibly by 619 trying to convince DIA1 to pay DIA3 for the services). This attack 620 can be prevented by supporting a new Next-Hop AVP. In this case when 621 NASB prepares a request it inserts a non-editable Next-Hop AVP which 622 contains DIA2's identitity. DIA2 also adds a Next-Hop AVP with DIA1 623 as the next hop. 625 This mechanism ensures that a man in the middle cannot alter the 626 packet by overriding the previous hop's additions and signature. DIA1 627 could easily validate the packet's path with the use of the Next-Hop 628 AVPs. 630 4.2 Domain Discovery 632 The Domain Discovery message set is very useful in determining the 633 Home authentication server, the password policies for the domain, as 634 a mechanism to retrieve a certificate (or a pointer to a 635 certificate). 637 Note that it is not necessary for a host to issue a Domain Discovery 638 in order to make use of a proxy. A DIAMETER Request MAY be proxied by 639 an intermediate server without the knowledge of the client, however 640 the client will be unable to validate any Digital-Signatures if the 641 home authentication server's certificate or public key is not known. 643 The following example shows a case where DIA1 needs to communicate 644 with DIA3. In this example it is necessary to use DIA2 as a proxy in 645 order for both ISPs to communicate. Although this MAY be desireable 646 in some business models, there are cases where it is beneficial to 647 remove the proxy altogether and allow both DIA3 and DIA1 to 648 communicate in a secure fashion. 650 (DD-Request) (DD-Request) 651 +------+ -----> +------+ ------> +------+ 652 | | | | | | 653 | DIA1 +--------------------+ DIA2 +--------------------+ DIA3 | 654 | | | | | | 655 +------+ <----- +------+ <------ +------+ 656 (DD-Response) (DD-Response) 658 The way the Domain Discovery works is that prior to sending out an 659 authentication request DIA1 would issue a Domain Discovery message 660 towards DIA2. This message is protected with the digital signature as 661 well as the Next-Hop AVP. DIA2 would then forward the request to DIA3 662 including the Next-Hop and the digital signature AVP. 664 When DIA3 receives the request, it MUST save the certificate (or the 665 pointer to the certificate) and respond back including the local 666 password policy, DIA3's certificate, its contact information (i.e. IP 667 address) and protect the response with the digital signature. 669 Note that in all cases the TimeStamp AVP is also present to ensure no 670 replay packets are accepted. 672 When DIA2 receives the packet, it must add the Next-Hop AVP as well 673 as the digital signature AVP. When DIA1 receives the packet it then 674 knows a direct route to communicate with DIA3 since the contact 675 information is present in the response. The fact that both DIA1 and 676 DIA3 can now communicate directly allows both peers to use IPSEC to 677 protect the message exchange (it may be desirable to use the 678 Digital-Signature AVP in instances where records of digitally signed 679 packets must be kept). 681 (Request) 682 +------+ -----> +------+ 683 | | | | 684 | DIA1 +--------------------+ DIA3 | 685 | | | | 686 +------+ <----- +------+ 687 (Answer) 689 In addition, the password policy is also present which can indicate 690 whether DIA3 is willing to accept CHAP, PAP or EAP authentication. 692 Note that the Domain-Discovery-Request/Answer MUST include at least 693 one Extension-Id AVP [2]. 695 4.3 Data Integrity 696 This section will describe how data integrity and non-repudiation is 697 achieved using the Digital-Signature AVP. 699 Note that the Timestamp and Nonce AVPs MUST be present in the message 700 PRIOR to the Digital-Signature AVPs discussed in this section. The 701 Timestamp AVP provides replay protection and the Nonce AVP provides 702 randomness. 704 Any AVPs in a message that is not followed by either the ICV or the 705 Digital-Signature AVPs MUST be ignored. 707 4.3.1 Using Digital Signatures 709 In the case of a simple peer to peer relationship the use of IPSEC is 710 sufficient for data integrity and non-repudiation. However there are 711 instances where a peer must communicate with another peer through the 712 use of a proxy server. IPSEC does not provide a mechanism to protect 713 traffic when two peers must use an intermediary node to communicate 714 at the application layer therefore the Digital-Signature AVP MUST be 715 used. 717 The following diagram shows an example of a router initiating a 718 DIAMETER message to DIA1. Once DIA1 has finished processing the 719 message it adds its signature and forwards the message to the non- 720 trusted DIA2 proxy server. If DIA2 needs to add or change any 721 protected AVPs it SHOULD add its digital signature before forwarding 722 the message to DIA3. 724 +------+ -----> +------+ -----> +------+ -----> +------+ 725 | | | | | non- | | | 726 |router+----------+ DIA1 +----------+trustd+----------+ DIA3 | 727 | | | | | DIA2 | | | 728 +------+ <----- +------+ <----- +------+ <----- +------+ 730 Since some fields within the DIAMETER header will change "en route" 731 towards the final DIAMETER destination, it is necessary to set the 732 unprotected fields to zero (0) prior to calculating the signature. 733 The two unprotected fields are the identifier and the length in the 734 DIAMETER header. 736 The following is an example of a message that include end-to-end 737 security: 739 ::= 740 741 [] 742 743 744 745 747 The AVP Header's 'P' bit is used to identify which AVPs are 748 considered protected when applying a digital signature to a DIAMETER 749 message. Protected AVPs cannot be changed "en route" since they are 750 protected by the Digital Signature AVP. All AVPs added by a DIAMETER 751 entity MUST appear prior to the Digital Signature AVP that is added 752 (with the exception of the Integrity-Check-Vector AVP). However, only 753 AVPs with the 'P' bit set are used in the digital signature 754 calculation. 756 The Next-Hop AVP indicates the intended recipient of the DIAMETER 757 message. When a DIAMETER message is received with a Next-Hop AVP 758 that does not correspond with the Host-IP-Address that follows, the 759 message MUST be considered invalid and MUST be rejected. 761 The Data field of the Digital-Signature AVP contains the RSA/MD5 762 signature algorithm as defined in [9]. 764 4.3.2 Using Mixed Data Integrity AVPs 766 The previous sections described the Integrity-Check-Vector and the 767 Digital-Signature AVP. Since the ICV offers hop-by-hop integrity and 768 the digital signature offers end to end integrity, it is possible to 769 use both AVPs within a single DIAMETER message. 771 The following diagram provides an example where DIAMETER Server 1 772 (DIA1) communicates with DIA3 using Digital-Signatures through DIA2. 773 In this example ICVs are used between DIA1 and DIA2 as well as 774 between DIA2 and DIA3. 776 777 -----------------------------> 778 779 +------+ -----> +------+ -----> +------+ 780 | | | | | | 781 | DIA1 +----------+ DIA2 +----------+ DIA3 | 782 | | | | | | 783 +------+ +------+ +------+ 785 Using the previous diagram, the following message would be sent 786 between DIA1 and DIA2: 788 ::= 789 790 [] 791 792 793 794 DIA2)> 796 The following message would be sent between DIA2 and DIA3: 798 ::= 799 800 [] 801 802 803 804 805 806 DIA3)> 808 Note that in the above example messages the ICV AVP appear after the 809 Digital-Signature AVP. This is necessary since DIA2 above removes the 810 ICV AVP (DIA1->DIA2) and adds its own ICV AVP (DIA2->DIA3). The ICVs 811 provide hop-by-hop security while the Digital-Signature provides 812 integrity of the message between DIA1 and DIA3. 814 815 +------+ -----> +------+ -----> +------+ 816 | | | | | | 817 |router+----------+ DIA1 +----------+ DIA2 | 818 | | | | | | 819 +------+ <----- +------+ <----- +------+ 821 There are cases, such as in remote access, where the device 822 initiating the DIAMETER request does not have the processing power to 823 generate Digital-Signatures as required by the protocol. In such an 824 arrangement, there normally exists a first hop DIAMETER Server (DIA1) 825 which acts as a proxy to relay the request to the final 826 authenticating DIAMETER server (DIA2). It is valid for the first hop 827 server to remove the Integrity-Check-Vector AVP inserted by the 828 router and replace it with a Digital-Signature AVP. 830 4.4 AVP Encryption with Public Keys 832 AVP encryption using public keys is much more complex than the 833 previously decribed method, yet it is desirable to use it in cases 834 where the DIAMETER message will be processed by an untrusted 835 intermediate node (proxy). 837 Public Key encryption SHOULD be supported, however it is permissible 838 for a low powered device initiating the DIAMETER message to use 839 shared secret encryption with the first hop (proxy) DIAMETER server, 840 which would decrypt and encrypt using the Public Key method. 842 The PK-Encrypted-Data bit MUST only be set if the final DIAMETER host 843 is aware of the sender's public key. This information can be relayed 844 in three different methods as described in section 4.3. 846 The AVP is encrypted in the method described in [9]. 848 4.5 Public Key Cryptography Support 850 A DIAMETER peer's public key is required in order to validate a 851 message which includes the the Digital-Signature AVP. There are three 852 possibilities on retrieving public keys: 854 4.5.1 X509-Certificate 856 A message which includes a Digital-Signature MAY include the X509- 857 Certificate AVP. Given the size of a typical certificate, this is 858 very wasteful and in most cases DIAMETER peers would cache such 859 information in order to minimize per packet processing overhead. 861 It is however valid for a DIAMETER host to provide its X509- 862 Certificate in certain cases, such as when issuing the Device- 863 Reboot-Indication. It is envisioned that the peer would validate and 864 cache the certificate at that time. 866 4.5.2 X509-Certificate-URL 868 The X509-Certificate-URL is a method for a DIAMETER host sending a 869 message that includes the Digital-Signature to provide a pointer to 870 its certificate. 872 Upon receiving such a message a DIAMETER host MAY choose to retrieve 873 the certificate if it is not locally cached. Of course the process of 874 retrieving and validating a certificate is lengthy and will require 875 the initiator of the message to retransmit the request. However once 876 cached the certificate can be used until it expires. 878 4.5.3 Static Public Key Configuration 880 Given that using certificates requires a PKI infrastructure which is 881 very costly, it is also possible to use this technology by locally 882 configuring DIAMETER peers' public keys. 884 Note that in a network involving many DIAMETER proxies this may not 885 scale well. 887 5.0 References 889 [1] Rigney, et alia, "RADIUS", RFC-2138, April 1997 890 [2] Calhoun, Rubens, "DIAMETER Base Protocol", Internet-Draft, 891 draft-calhoun-diameter-05.txt, August 1998. 892 [3] Rivest, Dusse, "The MD5 Message-Digest Algorithm", 893 RFC 1321, April 1992. 894 [4] Kaufman, Perlman, Speciner, "Network Security: Private 895 Communications in a Public World", Prentice Hall, 896 March 1995, ISBN 0-13-061466-1. 897 [5] Krawczyk, Bellare, Canetti, "HMAC: Keyed-Hashing for Message 898 Authentication", RFC 2104, January 1997. 899 [6] Calhoun, Bulley, "DIAMETER User Authentication Extensions", 900 draft-calhoun-diameter-authen-03.txt, May 1998. 901 [7] Aboba, Beadles "The Network Access Identifier." RFC 2486. 902 January 1999. 903 [8] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", 904 RFC 2477, January 1999. 905 [9] Kaliski, "PKCS #1: RSA Encryption Version 1.5", Internet- 906 Draft, draft-hoffman-pkcs-rsa-encrypt-03.txt, October 1997. 907 [10] Calhoun, Zorn, Pan, "DIAMETER Framework", 908 draft-calhoun-diameter-framework-02.txt, Work in Progress, 909 December 1998 910 [11] Aboba, Vollbrecht, "Proxy Chaining and Policy Implementation in 911 Roaming", draft-ietf-roamops-auth-10.txt, Work in Progress, 912 February 1999. 914 6.0 Acknowledgements 916 The Authors would like to acknowledge the following people for their 917 contribution in the development of the DIAMETER protocol: 919 Bernard Aboba, Jari Arkko, , Daniel C. Fox, Lol Grant, Nancy Greene, 920 Peter Heitman, Ryan Moats, Victor Muslin, Kenneth Peirce, Allan 921 Rubens, Sumit Vakil, John R. Vollbrecht, Jeff Weisberg and Glen Zorn 923 7.0 Author's Address 924 Questions about this memo can be directed to: 926 Pat R. Calhoun 927 Technology Development 928 Sun Microsystems, Inc. 929 15 Network Circle 930 Menlo Park, California, 94025 931 USA 933 Phone: 1-650-786-7733 934 Fax: 1-650-786-6445 935 E-mail: pcalhoun@eng.sun.com 937 William Bulley 938 Merit Network, Inc. 939 4251 Plymouth Road, Suite C 940 Ann Arbor, Michigan, 48105-2785 941 USA 943 Phone: 1-734-764-9993 944 Fax: 1-734-647-3185 945 E-mail: web@merit.edu