Internet Info 1997 December

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_q_t / draft-ietf-roamops-auth-02.txt < prev next >

Wrap

Text File | 1997-07-23 | 40KB | 988 lines

ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Corporation Category: Standards Track John R. Vollbrecht <draft-ietf-roamops-auth-02.txt > Merit Networks, Inc. 21 July 1997 Glen Zorn Microsoft Guidelines for the Secure Operation of RADIUS Proxies in Roaming 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute work- ing documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference mate- rial or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as <draft- ietf-roamops-auth-02.txt>, and expires February 1, 1998. Please send comments to the authors. 2. Abstract Today, RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. This document provides guidelines for the secure operation of RADIUS proxies within roaming systems. 2.1. Terminology This document frequently uses the following terms: Network Access Server The Network Access Server (NAS) is the device that clients contact in order to get access to the network. RADIUS server This is a server which provides for authentication/autho- rization via the protocol described in [3], and for account- ing as described in [4]. Aboba, Vollbrecht & Zorn [Page 1] INTERNET-DRAFT 21 July 1997 RADIUS proxy In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client. Network Access Identifier In order to provide for the routing of RADIUS authentication and accounting requests, the userID field used in PPP (known as the Network Access Identifier or NAI) and in the subse- quent RADIUS authentication and accounting requests, can contain structure. This structure provides a means by which the RADIUS proxy will locate the RADIUS server that is to receive the request. Roaming relationships Roaming relationships include relationships between compa- nies and ISPs, relationships among peer ISPs within a roam- ing association, and relationships between an ISP and a roaming consortia. Together, the set of relationships form- ing a path between a local ISP's authentication proxy and the home authentication server is known as the roaming rela- tionship path. 3. Introduction Today, as described in [1], RADIUS proxy chaining is widely deployed for the purposes of providing roaming services. In such systems, RADIUS authentication and accounting packets are routed between a NAS device and a home RADIUS server through a series of RADIUS proxies. The purpose of this document is to provide guidelines for the secure operation of such systems. An example of such a proxy chaining system is shown below. (request) (request) (request) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS (reply) (reply) (reply) Server <--------- <--------- <--------- In the above diagram, the NAS generates a RADIUS request and sends it to Proxy1. Proxy1 forwards the request to Proxy2 and Proxy2 forwards the request to the Home Server. The Home Server generates a reply and returns it to Proxy2. Proxy2 receives the reply, matches it with the request it had sent, and forwards a reply to Proxy1. Proxy1 matches the reply with the request it sent earlier and forwards a reply to the NAS. This model applies to all RADIUS requests, including Access Requests and Accounting Requests. RADIUS proxies implementing policy MAY send a reply without forwarding the request. An example of this would be when the proxy refuses all connections from a particular realm during prime time. In this case Aboba, Vollbrecht & Zorn [Page 2] INTERNET-DRAFT 21 July 1997 the home server will never receive the Access-Request. This situation is shown below: (request) (request) NAS ----------> Proxy1 ----------> Proxy2 Home RADIUS (reply) (reply) Server <--------- <--------- The proxy SHOULD reply directly only to Access-Requests and SHOULD NOT reply directly to Accounting-Requests. When replying directly to an Access-Request, the proxy MUST reply either with an Access-Reject or an Access-Challenge packet. A RADIUS proxy MUST NOT reply directly with an Access-Accept. A proxy forwarding a request SHOULD NOT send a reply to a request until it has received a reply from the server or proxy to which it sent the corresponding request. The effect of this is that the NAS will never see a reply which was not initiated by the home server. A less pleasant consequence is that the delay between request and reply at the NAS will be longer than if the reply were "faked" by a proxy. A proxy MAY decide to Reject a Request that has been accepted by the home server. This could be based on the set of attributes returned by the home server. In this case the Proxy SHOULD send an Access-Reject to the NAS and an Accounting message with Acct-Status-Type=Proxy-Stop to the home server. This lets the Home Server know that the Session it approved has been denied downstream by the Proxy. However, a proxy MUST NOT send an Access-Accept after receiving an Access-Reject from the home server. (AccReq) (AccReq) (AccReq) NAS ----------> Proxy1 ----------> Proxy2 ----------> Home RADIUS (AccRejct) (AccAccpt) (AccAccpt) Server <--------- <--------- <--------- (AcctPxStop) (AcctPxStop) ----------> ----------> Home servers SHOULD insert a unique session identifier in the Class attribute in an Access-Accept and Access-Challenge. Proxies and NASes MUST forward the Class attribute. The NAS MUST include the Class attribute in subsequent requests, in particular for Accounting- Requests. The Class attribute can be used to match accounting requests with prior access requests. It can also be used to match session log records between the home Server, proxies, and NAS. The sequence of events is shown below: --------> --------> ---------> Aboba, Vollbrecht & Zorn [Page 3] INTERNET-DRAFT 21 July 1997 NAS Proxy1 Proxy2 Home (add class) <-class-- <-class- <-class-- In RADIUS proxy chaining, the forwarding function is carried out based on the realm portion of the Network Access Identifier (NAI), defined in [9]. While the mechanism by which the path is selected is implemen- tation dependent, existing implementations typically use static for- warding tables set in their configuration files. While the RADIUS protocol described in [3] does not provide for authentication of Access-Requests, such authentication is possible using the Signature attribute described in [5]. Proxies MUST include the Signature attribute in all Access-Requests. Since the RADIUS pro- tocol, described in [3], does support authentication of Access-Reply packets, the Signature attribute is not required in an Access-Reply. 4. Trust models In conventional ISP application, the NAS, RADIUS proxy, and RADIUS server typically exist within a single administrative entity. As a result, the RADUS proxy and RADIUS server may be considered to be trusted components. However, in a roaming system implemented with proxy chaining, the NAS, RADIUS proxies, and RADIUS server may be managed by different adminis- trative entities. Through the use of shared secrets it is possible for RADIUS proxies operating in different domains to establish a trust relationship. However, since RADIUS packets are only authenticated on a hop-by-hop basis, proxy chaining systems deployed in roaming operate without end-to-end authentication. This means that in such systems security is only as strong as the weakest link in the proxy chain. Among other things, this implies that it is advisable to keep the chain as short as possible. To date, as described in [1], existing roaming implementations have been limited in scale, forwarding RADIUS packets over a maximum of two hops, or implementing star configura- tions with all systems connecting to a single trusted entity. Such configurations minimize trust issues. 5. Security issues Since current roaming implementations operate in more than 150 coun- tries and service millions of users, it is critical that RADIUS proxy chaining implementations be secure. In particular, protection must be provided against the following attacks: Theft of passwords Replay attacks Attribute editing Connection hijacking Authentication routing attacks Aboba, Vollbrecht & Zorn [Page 4] INTERNET-DRAFT 21 July 1997 Fraudulent accounting records 5.1. Theft of passwords In the case where clients authenticate using PAP, each RADIUS proxy along the path between the local NAS and the home RADIUS server will have access to the cleartext password. In many circumstances, this represents an unacceptable security risk, and as a result, it is rec- ommended that PAP SHOULD NOT be used in roaming. A possible exception to this recommendation occurs in situations where PAP is used in order to pass a one time password or token. 5.2. Replay attacks In this attack, a man in the middle or rogue RADIUS proxy collects CHAP-Challenge and CHAP-Response attributes, and later replays them. If this attack is performed in collaboration with an unscrupulous ISP, it can be used to subsequently submit fraudulent accounting records to the accounting agent for payment. The system performing the replay need not necessarily be the one that initially captured the CHAP Chal- lenge/Response pair. While such an attack has always been possible, without roaming the threat is restricted to RADIUS proxies operating in the home server's domain. With roaming, such an attack can be mounted by any RADIUS proxy capable of reaching the home RADIUS server. In order to detect replay attacks, RADIUS servers used in roaming SHOULD keep a log of CHAP challenges, so as to allow the log to be checked for replays. CHAP replay attacks can be defeated by means of an end-to-end chal- lenge-response exchange. For example, if the home RADIUS server returns an Access-Challenge packet containing a CHAP-Challenge attribute and maintains state with respect to outstanding challenges, replay attacks will not work. However, it should also be noted that end-to-end challenges (as prac- ticed within the EAP MD5 authentication method, or in the CHAP-Chal- lenge method described above) are subject to attacks by rogue RADIUS proxies. In such an attack a RADIUS proxy substitutes a static chal- lenge for the challenge sent by the home RADIUS server, and on receiv- ing the response, checks it against a databases of hashes applied against a dictionary. Use of the CHAP and PAP authentication methods may be avoided entirely by instructing the PPP authenticating peer to refuse these authentica- tion methods if offered. Aboba, Vollbrecht & Zorn [Page 5] INTERNET-DRAFT 21 July 1997 5.3. Attribute editing In this attack, a RADIUS proxy modifies an Access-Accept sent by the RADIUS server so as to lessen the security obtained by the client. For example, EAP attributes might be removed or modified so as to cause a client to authenticate with EAP MD5 or PAP, instead of a stronger authentication method. Alternatively, tunnel attributes might be removed or modified so as to remove encryption, redirect the tunnel to a rogue tunnel server, or otherwise lessen the security provided to the client. In order to prevent inappropriate modification of RADIUS attributes the table in Appendix A describe what attributes may be added, edited, deleted, or processed by authentication and accounting proxies. Inappropriate attribute editing need not occur du to acts of malice. The vast majority of such problems are likely to result from miscon- figuration of RADIUS proxies. In fact, it is expected that as roaming grows in popularity, attribute editing problems will become widespread. This is likely since several proxy implementations remove attributes that they do not understand, or can be set up to replace attribute sets sent in the Access-Accept with sets of attributes appropriate for a particular network. Since RADIUS only provides for hop-by-hop authentication, it is not possible to provide end-to-end integrity checks within proxy chaining systems. However, in order to provide for detection of inappropriate attribute editing, local RADIUS proxies and home RADIUS servers SHOULD implement auditing functionality. For example, the local RADIUS proxy SHOULD include RADIUS attributes received in the Access-Accept within the session record or Accounting- Start message for the session. Similarly, home RADIUS servers SHOULD log the contents of RADIUS Access-Replies sent, and SHOULD periodi- cally check for discrepancies between attributes sent in RADIUS Access-Replies, and attributes received by local proxies. In order to prevent intermediate proxies from modifying accounting records, accounting records SHOULD NOT travel the same path taken by RADIUS authentication. Instead, accounting records SHOULD be sent directly between the local proxy and the systems requiring copies of the accounting records. 5.4. Connection hijacking In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the home RADIUS server. RADIUS as described in [3] is vulnerable to such attacks since only Access-Reply and Access-Challenge packets are authenticated. In order to provide for authentication of Access-Request packets, RADIUS proxies operating in roaming systems MUST support the Signature attribute, as decribed in [9]. RADIUS proxies used in roaming imple- mentations MUST check for the presence of the Signature attribute in Aboba, Vollbrecht & Zorn [Page 6] INTERNET-DRAFT 21 July 1997 Access-Requests forwarded to them from other proxies, and MUST silently discard Access-Request packets missing the Signature attribute or failing authentication. RADIUS proxies operating in roam- ing systems also MUST include a Signature attribute in all forwarded Access-Request packets. 5.5. Authentication routing attacks In roaming, one of the functions of the RADIUS proxy is to route authentications between domains. Authentication routing attacks affect the core of a roaming system by modifying authentication rout- ing information, thus disabling the system or causing RADIUS packets to be routed inappropriately. Since to date roaming has been implemented on a relatively small scale, existing implementations perform authentication routing based on local knowledge expressed in proxy configuration files. To date implementations have not found a need for dynamic routing protocols, or propagation of global routing information. Since authentication routing information is fundamental to the opera- tional of a roaming system, routing information SHOULD be propagated using an transfer method supporting mutual authentication, such as Kerberized rcp, SSH or TLS. Since all RADIUS packets used in roaming are secured by a shared secret, such attacks will not rsult in more than a denial of service, as long as the attacker did not also obtain the shared secrets. As with attribute editing, it is expected that most problems of this type will result from misconfiguration of RADIUS proxies. In order to detect such misconfigurations, RADIUS proxies participating in roaming MUST implement the Route attribute described below. The Route attribute provides trace route and/or source route capabilities. This allows a local RADIUS proxy to specify a route through which an Access-Request must travel, or for a home RADIUS server to determine whether to authorize Access-Requests routed on a given roaming rela- tionship path. A RADIUS proxy receiving a Route attribute with the Trace option set MUST append the domain of the system from which it received the packet to the end of the Route attribute prior to forwarding it. 5.6. Fraudulent accounting records In this form of attack, a local RADIUS proxy transmits fraudulent accounting packets or session records to the accounting agent in an effort to collect fees to which they are not entitled. In order to detect submission of fraudulent accounting records by an unscrupulous ISP, the the accounting gateway SHOULD send copies of session records to all parties with a financial interest in the Aboba, Vollbrecht & Zorn [Page 7] INTERNET-DRAFT 21 July 1997 session. Parties receiving copies of these session records SHOULD reconcile them with logs of proxied authentications. In order to make it easier to match RADIUS authentication logs with accounting records, RADIUS servers involved in roaming SHOULD include a Class attribute in the Access-Accept. The Class attribute should uniquely identify a session, so as to allow an authentication log entry to be matched with a corresponding accounting record. In order to be able to match accounting records with logs of proxied RADIUS authentications, accounting agents SHOULD require that they act as an authentication proxy for all sessions for which an accounting record will subsequently be submitted. 6. Proposed RADIUS attributes for use in roaming 6.1. Route Description In a roaming implementation based on proxy chaining, RADIUS packets are routed between the NAS and RADIUS server through a series of RADIUS proxies. This attribute allows for the authentication route taken by a RADIUS Access-Request, Access-Challenge, or Access-Reply packet to be recorded within the packet, or alternatively, for a source-route to be specified. RADIUS proxies receiving an Access- Request message with a Source-Route attribute MUST either honor the attribute or return an Access-Reject. A summary of the Route attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | String +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | String... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Route Length >=3 Flags The Flags field indicates the intended purpose of the Route Aboba, Vollbrecht & Zorn [Page 8] INTERNET-DRAFT 21 July 1997 attribute: 0 0 1 2 3 4 5 6 7 8 +-+-+-+-+-+-+-+-+ |T S L D R R R R| +-+-+-+-+-+-+-+-+ T = Trace. If T=1, then the string represents a trace route request, and a RADIUS proxy receiving a Route option set MUST append the domain of system from which it received the packet to the end of the Route prior to forwarding it. S = Source route. If S=1 then the string field represents a source route. L = Loose. If L=1 and S=1, then the string field represents a loose source route. If L=0 and S=1, then the route represents a strict source route. The combinations S=0, L=1 and T=1, S=1 are not permitted. R = Reserved. D = Direction. If D=1, the Route attribute is relevant to an Access-Request or Accounting-Request packet; if D=0, the Route attribute is relevant to an Access-Reply, Access-Challenge or Accounting-Reply packet. String The String field includes the route, which is represented as a series of domains separated by the "/" character. For example, a valid source route is ispb.com/ispgroup.com/ispa.com/bigco.com/. If trace routing is used, then a RADIUS proxy receiving a packet from another proxy MUST append the domain of the sender onto the end of the Route attribute, prior to forwarding it. Note that the Route attribute is represented as a domain path, NOT a path comprised of the IP addresses or fully qualified domain names of the RADIUS proxies themselves. Thus, it is expected that RADIUS proxies implementing the Route attribute will be able to trans- late the IP address of the sending proxy into the appropriate domain for use in the Route attribute. This is typically accom- plished through proxy configuration files. Since a single RADIUS attribute may only be 253 octets in length, if the Route attribute is larger than this, it may be necessary to split the contents across multiple Route attributes. In order to permit Route attributes to exceed 253 octets, Route attributes with identical values of the Flags field are to be concatenated prior to interpretation. However, Route attributes with different values of the Flags field MUST NOT be concatenated, since it is possible for multi- ple Route attributes to be required within a packet. For exam- ple, it is possible for a packet to contain one Route attribute with T=1,S=0 indicating a trace request, and another Route attribute with T=0, S=1, L=1, indicating the presence of a Loose Source route. In this case, a Loose Source Route is presented at the same time that it is requested that the actual route be recorded and returned. Aboba, Vollbrecht & Zorn [Page 9] INTERNET-DRAFT 21 July 1997 7. Appendix A: Allowable Proxy Behavior Proxies MAY interpret attributes they receive and MAY add attributes to Access-Request, Access-Reply, Access-Challenge, and Accounting- Request messages, as described below. Proxies MUST maintain attribute order when forwarding. A Proxy that adds attributes MUST precede the additional attributes with a "Proxy-State" attribute containing as its leading string the IP-Address of the Proxy. A Proxy may need to translate some attributes to support a particular service. Translation should be done only to support a common service, and only at the Proxy closest to the NAS. Translation could be done to support a common set of IP filters on NASs from different vendors. A local proxy (a proxy downstream from a NAS) MAY edit or delete attributes within Access-Requests, as provided below. An intermediate proxy (a proxy downstream from another proxy) SHOULD NOT edit or delete attributes when forwarding Access-Requests. Local proxies MAY edit or delete attributes in an Access-Reply, as provided below, if the downstream server is a NAS which is not able to interpret some attributes. Intermediate proxies SHOULD NOT edit or delete attributes in an Access-Reply. AUTHENTICATION Request Accept Reject Challenge # Attribute E A 1 User-Name [note 1] PD 2 User-Password [note 2] A 3 CHAP-Password [note 2] AED 4 NAS-IP-Address AED 5 NAS-Port AE AE 6 Service-Type AE AE 7 Framed-Protocol AED AED 8 Framed-IP-Address AED AED 9 Framed-IP-Netmask AED 10 Framed-Routing AE 11 Filter-Id AED 12 Framed-MTU AED AED 13 Framed-Compression AE AE 14 Login-IP-Host AE 15 Login-Service AE 16 Login-TCP-Port AE AE AE 18 Reply-Message AE AE 19 Callback-Number [note 3] A 20 Callback-Id AED 22 Framed-Route AED 23 Framed-IPX-Network AE AE AE 24 State AE 25 Class AED AED AED 26 Vendor-Specific AE AE 27 Session-Timeout AE AE 28 Idle-Timeout AE 29 Termination-Action AE 30 Called-Station-Id [note 3] Aboba, Vollbrecht & Zorn [Page 10] INTERNET-DRAFT 21 July 1997 AED 31 Calling-Station-Id [note 4] AED 32 NAS-Identifier AP AP AP AP 33 Proxy-State AE AE 34 Login-LAT-Service AE AE 35 Login-LAT-Node AE AE 36 Login-LAT-Group AE 37 Framed-AppleTalk-Link AED 38 Framed-AppleTalk-Network AED 39 Framed-AppleTalk-Zone 60 CHAP-Challenge AE 61 NAS-Port-Type AE AE 62 Port-Limit AE AE 63 Login-LAT-Port 64 Tunnel-Type 65 Tunnel-Medium-Type 67 Tunnel-Server-Endpoint P 69 Tunnel-Password AP 70 ARAP-Password AE AE 71 ARAP-Features AE 72 ARAP-Zone-Access A A 73 ARAP-Security A A 74 ARAP-Security-Data ED 75 Password-Retry AE 76 Prompt 77 Connect-Info AED 78 Configuration-Token 79 EAP-Message AP 80 Signature Request Accept Reject Challenge # Attribute 1. A proxy may strip the realm from the User-Name, so as to provide compatibiltiy with proxies that cannot handle this. 2. Use of PAP is considered undesirable in roaming, since each RADIUS proxy handling the Access-Request will have access to the cleartext password. As a result, if the user uses PAP to authenticate with the NAS, and the NAS sends the User-Password to the proxy (secure network) the proxy may convert it to CHAP before sending it to the home server (insecure network). In some situations this would be desirable (fewer proxies would have access to the password), and in others it would be undesirable (the home NAS has no way to know that it was only PAP that was done). 3. A proxy may edit these attributes in order to make them more spe- cific. For example, the proxy might need to change Callback-Number = "7771111" to Callback-Number = "5107771111". 4. A proxy may wish to delete the Calling-Station-ID so as to protect the privacy of the caller. As with note 2 above, this attribute may be edited to make it more specific. ACCOUNTING Aboba, Vollbrecht & Zorn [Page 11] INTERNET-DRAFT 21 July 1997 Request Reply # Attribute 1 User-Name 2 User-Password 3 CHAP-Password AE 4 NAS-IP-Address AE 5 NAS-Port AE 6 Service-Type AE 7 Framed-Protocol AED 8 Framed-IP-Address AED 9 Framed-IP-Netmask AED 10 Framed-Routing AE 11 Filter-Id AED 12 Framed-MTU AED 13 Framed-Compression AE 14 Login-IP-Host AE 15 Login-Service AE 16 Login-TCP-Port 18 Reply-Message A 19 Callback-Number A 20 Callback-Id AED 22 Framed-Route AED 23 Framed-IPX-Network 24 State AE 25 Class AED 26 Vendor-Specific AE 27 Session-Timeout AE 28 Idle-Timeout AE 29 Termination-Action AED 30 Called-Station-Id AED 31 Calling-Station-Id AED 32 NAS-Identifier AP 33 Proxy-State AE 34 Login-LAT-Service AE 35 Login-LAT-Node AE 36 Login-LAT-Group AE 37 Framed-AppleTalk-Link AED 38 Framed-AppleTalk-Network AED 39 Framed-AppleTalk-Zone 40 Acct-Status-Type 41 Acct-Delay-Time [note 1] 42 Acct-Input-Octets 43 Acct-Output-Octets E 44 Acct-Session-Id [note 2] 45 Acct-Authentic 46 Acct-Session-Time 47 Acct-Input-Packets 48 Acct-Output-Packets 49 Acct-Terminate-Cause E 50 Acct-Multi-Session-Id [note 2] 51 Acct-Link-Count 60 CHAP-Challenge AE 61 NAS-Port-Type AE 62 Port-Limit AE 63 Login-LAT-Port Aboba, Vollbrecht & Zorn [Page 12] INTERNET-DRAFT 21 July 1997 64 Tunnel-Type 65 Tunnel-Medium-Type 66 Acct-Tunnel-Client-Endpoint 67 Tunnel-Server-Endpoint 68 Acct-Tunnel-Connection-ID 69 Tunnel-Password 70 ARAP-Password AE 71 ARAP-Features AE 72 ARAP-Zone-Access A 73 ARAP-Security A 74 ARAP-Security-Data ED 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Signature Accounting Accounting Request Reply # Attribute 1. If the proxy can calculate the additional delay it is introducing, it should increment this. 2. The proxy may need to modify the NAS identification to hide private network information. In that case, it may forward packets with itself as the NAS, and will need to construct an Acct-Session-Id that is guaranteed to be unique. For example, if the proxy gets packets from 16 NASs, session '3478617' on the 11th NAS might be given the new ses- sion ID 'A3478617'. The following table defines the meaning of the above table entries. A This attribute MAY be added E This attribute MAY be edited. Editing is defined as a change beyond that required in hop-by-hop processing as described in [3]-[5]. D This attribute MAY be deleted. P This attribute MUST be processed as described in [3]-[5]. 8. Acknowledgments Thanks to Pat Calhoun of 3COM, Mark Beadles of CompuServe, Aydin Edguer of Morningstar, and Steven P. Crain of Shore.Net for useful discussions of this problem space. 9. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." Internet draft (work in progress), draft-ietf- roamops-imprev-04.txt, Microsoft, Aimnet, i-Pass Alliance, Asiainfo, Aboba, Vollbrecht & Zorn [Page 13] INTERNET-DRAFT 21 July 1997 Merit, June, 1997. [2] B. Aboba, G. Zorn. "Dialing Roaming Requirements." Internet draft (work in progress), draft-ietf-roamops-roamreq-04.txt, Microsoft, June, 1997. [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, 1997. [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, 1997. [5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-00.txt, Livingston, January, 1997. [6] R. Fielding, et al. "Hypertext Transfer Protocol - HTTP/1.1." RFC 2068, UC Irvine, January, 1997. [7] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., April 1992. [8] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [9] B. Aboba. "The Network Access Identifier." Internet draft (work in progress), draft-ietf-roamops-nai-06.txt, Microsoft, July 1997. 10. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com John R. Vollbrecht Merit Network, Inc. 4251 Plymouth Rd. Ann Arbor, MI 48105-2785 Phone: 313-763-1206 EMail: jrv@merit.edu Glen Zorn Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-703-1559 Aboba, Vollbrecht & Zorn [Page 14] INTERNET-DRAFT 21 July 1997 EMail: glennz@microsoft.com Aboba, Vollbrecht & Zorn [Page 15]