Merit Network, Incorporated Bernard Aboba Microsoft March 1997

Transcription

1 Internet Draft Category: Experimental expires in six months Pat R. Calhoun US Robotics Access Corp. Allan Rubens Merit Network, Incorporated Bernard Aboba Microsoft March 1997 DIAMETER Extensible Authentication Protocol Support <draft-calhoun-diameter-eap-00.txt> Status of this Memo Distribution of this memo is unlimited. This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working 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 material 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). Abstract The Extensible Authentication Protocol (EAP) is a PPP extension that provides support for additional authentication methods within PPP. This document describes how the EAP Protocl may be used in conjunction with the DIAMETER protocol. Calhoun, Rubens & Aboba [Page 1]

2 1. Introduction The Extensible Authentication Protocol (EAP), described in [1], provides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including token cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within DIAMETER, new messages are being introduced in this document. The scheme described here is similar to that proposed in [2], in that the DIAMETER server is used to shuttle DIAMETER-encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the DIAMETER server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use DIAMETER-encapsulated EAP via the new commands defined in this document. This has the advantage of allowing the DIAMETER server to support EAP without the need for authentication-specific code, which can instead reside on a backend security server. 2. Requirements language This specification uses the same words as [6] for defining the significance of each particular requirement. These words are: MUST This word, or the adjectives "REQUIRED" or "SHALL", means that the definition is an absolute requirement of the specification. MUST NOT This phrase, or the phrase "SHALL NOT", means that the definition is an absolute prohibition of the specification. SHOULD This word, or the adjective "RECOMMENDED", means that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. SHOULD NOT This phrase means that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. Calhoun, Rubens & Aboba [Page 2]

3 MAY This word, or the adjective "OPTIONAL", means that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option. (except, of course, for the feature the option provides) An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant." 3. Protocol overview The EAP conversation between the authenticating peer and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS will typically send to the DIAMETER server a DIAMETER Access-Request packet containing the DIAMETER-EAP-Request Command signifying an EAP-Start. EAP-Start is indicated by sending an DIAMETER-EAP-Request Command with an EAP-Packet attribute with a length of 7 (no data). The Port number and NAS Identifier MUST be included in the attributes issued by the NAS in the DIAMETER-EAP-Request packet. If the DIAMETER server supports EAP, it MUST respond with an DIAMETER-EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. The DIAMETER-EAP-Response typically will contain an EAP-Packet attribute encapsulating an EAP-Request/Identity message, requesting the authenticating peer to identify itself. The NAS will then respond with a DIAMETER-EAP-Request packet containing an EAP-Packet attribute encapsulating an EAP-Response, etc. The conversation continues until either a DIAMETER-EAP-Reject packet is received (with an EAP-Packet attribute encapsulating EAP-Failure) which results in the NAS disconnecting the user, or a DIAMETER-EAP-Ack packet is received (with an EAP-Packet attribute encapsulating EAP-Success) successfully ending the authentication Calhoun, Rubens & Aboba [Page 3]

4 phase. Note that if a DIAMETER-EAP-Reject packet with an EAP-Packet attribute encapsulating EAP-Failure is received from the DIAMETER Server, the NAS SHOULD issue an LCP Terminate Request to the authenticating peer. The above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer. This involves having the NAS send an EAP- Request/Identity message to the authenticating peer, and forwarding the Identity packet to the DIAMETER server in the EAP-Packet attribute of a DIAMETER-EAP-Request packet. While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user s identity may not be needed (such as when authentication and accounting is handled based on the calling or called phone number), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. Unless the NAS interprets the Identity packet returned by the authenticating peer, it will not have access to the user s identity. Therefore, the DIAMETER Server SHOULD return the user s identity by inserting it in the User-Name attribute of subsequent DIAMETER-EAP-Response and DIAMETER-EAP-Ack packets. Without the user s identity, accounting and billing becomes very difficult to manage. In cases where a backup DIAMETER servers is available, were the primary server to fail at any time during the EAP conversation, it would be desirable for the NAS to be able to redirect the conversation to an alternate DIAMETER server. However, for the backup server to be able to pick up the conversation, it must be provided with the state of the EAP conversation prior to the interruption. This can be accomplished by having the DIAMETER-EAP-Request include the series of EAP-Packet attributes representing the previous history of the EAP conversation. Similarly, the DIAMETER-EAP-Response returned by the DIAMETER server must also include all previous EAP-Packet attributes. The sequence number field in the EAP-Packet attribute MUST be used in order to determine which attribute is to be processed. The attribute with the highest sequence number is the most recent attribute. The DIAMETER-EAP-Ack/EAP-Packet/EAP-Success packet MUST contain all of the expected attributes which are currently returned in an Access-Accept packet. Calhoun, Rubens & Aboba [Page 4]

5 For proxied DIAMETER requests there are two methods of processing. If the domain is determined based on the DNIS the DIAMETER Server may proxy the initial DIAMETER-EAP-Request/EAP-Start. If the domain is determined based on the user s identity, the local DIAMETER Server MUST respond with a DIAMETER-EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server. For proxied DIAMETER requests, the NAS may receive an Command Unrecongnized packet in response to its DIAMETER-EAP-Request/EAP-Identity packet. This would occur if the message was proxied to a DIAMETER Server which does not support the DIAMETER EAP extensions. At this point, the NAS MUST re-open LCP with the authenticating peer and request either CHAP or PAP as the authentication protocol. If the NAS is unable to negotiate EAP with the authenticating peer, what happens next is a matter of policy. In circumstances where EAP is required of all users accessing the NAS, the NAS MUST disconnect the user. However, in circumstances where EAP is mandatory for some users, and optional or not required for others, the decision cannot be made until the user s identity is ascertained. In this case, the NAS will negotiate another authentication method, such as CHAP, and will pass the User-Name and CHAP-Password attributes to the DIAMETER Server in an Access-Request packet. If the user is not required to use EAP, then the DIAMETER Server will respond with an Access-Accept or Access-Reject packet as appropriate. However, should the user require EAP, then the DIAMETER Server will respond with an DIAMETER-EAP-Response packet containing an EAP-Packet attribute. The EAP-Packet attribute will either encapsulate an EAP-Request/Identity packet, or if the DIAMETER Server makes use of the User-Name attribute in the Access-Request, it may encapsulate an EAP challenge. On receiving the EAP-Packet attribute, the NAS will either attempt to negotiate EAP if it had not done so previously, or if negotiation had previously been attempted and failed, it MUST disconnect the user. The NAS is not responsible for the retransmission of any EAP messages. The authenticating peer and the DIAMETER Server are responsible for any retransmissions. The example below shows the conversation between the authenticating peer, NAS, and server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they would show somewhat different behavior. For brevity, the history of previous EAP messages (which will be transmitted in each DIAMETER-EAP-Request and DIAMETER-EAP-Response packet) has been left out. Calhoun, Rubens & Aboba [Page 5]

6 Authenticating Peer NAS DIAMETER Server PPP LCP ACK-EAP auth -> PPP Identity (MyID) -> PPP OTP, OTPpw -> PPP Authentication Phase complete, NCP Phase starts <- PPP LCP Request-EAP auth DIAMETER- EAP-Request/ EAP-Packet/Start -> <- PPP EAP-Request/ Identity DIAMETER- EAP-Request/ EAP-Packet/ (MyID) -> <- PPP EAP-Request/ OTP/OTP Challenge DIAMETER- EAP-Request/ EAP-Packet/ OTP, OTPpw -> <- PPP EAP-Success <- DIAMETER- EAP-Packet/Identity <- DIAMETER- EAP-Packet/EAP-Request OTP/OTP Challenge <- DIAMETER-EAP-Ack/ EAP-Packet/EAP-Success (other attributes) Calhoun, Rubens & Aboba [Page 6]

7 In the case where the NAS sends the authenticating peer an EAP-Request/Identity packet without first sending an EAP-Start packet to the DIAMETER server, the conversation would appear as follows: Authenticating Peer NAS DIAMETER Server PPP LCP ACK-EAP auth -> PPP Identity (MyID) -> PPP OTP, OTPpw -> PPP Authentication Phase complete, NCP Phase starts <- PPP LCP Request-EAP auth <- PPP EAP-Request/ Identity DIAMETER- EAP-Request/ EAP-Packet/ (MyID) -> <- PPP EAP-Request/ OTP/OTP Challenge DIAMETER- EAP-Request/ EAP-Packet/ OTP, OTPpw -> <- PPP EAP-Success <- DIAMETER- EAP-Packet/EAP-Request OTP/OTP Challenge <- DIAMETER-EAP-Ack/ EAP-Packet/EAP-Success (other attributes) Calhoun, Rubens & Aboba [Page 7]

8 In the case where the client fails EAP authentication, the conversation would appear as follows: Authenticating Peer NAS DIAMETER Server PPP LCP ACK-EAP auth -> PPP Identity (MyID) -> PPP OTP, OTPpw -> <- PPP LCP Request-EAP auth Access-Request/ EAP-Packet/Start -> <- PPP EAP-Request/ Identity DIAMETER- EAP-Request/ EAP-Packet/ (MyID) -> <- PPP EAP-Request/ OTP/OTP Challenge DIAMETER- EAP-Request/ EAP-Packet/ OTP, OTPpw -> <- PPP EAP-Failure (client disconnected) <- DIAMETER- EAP-Packet/Identity <- DIAMETER- EAP-Packet/EAP-Request OTP/OTP Challenge <- DIAMETER- EAP-Reject/ EAP-Packet/EAP-Failure Calhoun, Rubens & Aboba [Page 8]

9 In the case that the DIAMETER server or proxy does not support EAP extensions the conversation would appear as follows: Authenticating Peer NAS DIAMETER Server PPP LCP ACK-EAP auth -> PPP LCP ACK-CHAP auth -> PPP CHAP Response -> PPP Authentication Phase complete, NCP Phase starts <- PPP LCP Request-EAP auth DIAMETER Access-Request/ EAP-Packet/Start -> <- PPP LCP Request-CHAP auth <- PPP CHAP Challenge DIAMETER Access-Request-> <- PPP LCP CHAP-Success <- DIAMETER Command-Unrecognized <- DIAMETER Access-Accept In the case where the local DIAMETER Server does support the EAP extensions but the remote DIAMETER Server does not, the conversation would appear as follows: Authenticating Peer NAS DIAMETER Server PPP LCP ACK-EAP auth -> <- PPP LCP Request-EAP auth DIAMETER- EAP-Request/ EAP-Packet/Start -> Calhoun, Rubens & Aboba [Page 9]

10 PPP Identity (MyID) -> PPP LCP ACK-CHAP auth -> PPP CHAP Response -> PPP Authentication Phase complete, NCP Phase starts <- PPP EAP-Request/ Identity DIAMETER- EAP-Request/ EAP-Packet/ (MyID) -> <- PPP LCP Request-CHAP auth <- PPP CHAP Challenge DIAMETER Access-Request-> <- PPP LCP CHAP-Success <- DIAMETER- EAP-Packet/Identity <- DIAMETER- EAP-Reject (proxied from remote DIAMETER Server) <- DIAMETER Access-Accept (proxied from remote DIAMETER Server) In the case where the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows: Authenticating Peer NAS DIAMETER Server PPP LCP NAK-EAP auth -> <- PPP LCP Request-EAP auth <- PPP LCP Request-CHAP auth Calhoun, Rubens & Aboba [Page 10]

11 PPP LCP ACK-CHAP auth -> PPP CHAP Response -> <- PPP CHAP Challenge DIAMETER- Access-Request/ User-Name, CHAP-Password -> (User Disconnected) <- DIAMETER- EAP-Packet 5. Alternative uses Currently the conversation between the backend security server and the DIAMETER server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between DIAMETER vendors and backend security vendors, it is recommended that DIAMETER-encapsulated EAP be used for this conversation. This has the advantage of allowing the DIAMETER server to support EAP without the need for authentication-specific code within the DIAMETER server. Authentication-specific code can then reside on a backend security server instead. In the case where DIAMETER-encapsulated EAP is used in a conversation between a DIAMETER server and a backend security server, the Security Server will typically return an DIAMETER-EAP-Ack/EAP-Packet/EAP-Success message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the DIAMETER server MUST add these attributes prior to sending an DIAMETER-EAP-Ack/EAP-Packet/EAP-Success message to the NAS. 2. Command Name and Command Code Command Name: DIAMETER-EAP-Request Command Code: 300 Command Name: DIAMETER-EAP-Response Command Code: 301 Command Name: DIAMETER-EAP-Ack Command Code: 302 Calhoun, Rubens & Aboba [Page 11]

12 Command Name: DIAMETER-EAP-Reject Command Code: Command Meanings 3.1 DIAMETER-EAP-Request Description DIAMETER-EAP-Request packets are sent by the DIAMETER Client to the DIAMETER Server, and convey EAP-Responses from the client through the NAS and on to the DIAMETER server. DIAMETER-EAP-Requests will normally include at least one EAP-Packet attribute which contains the EAP packets. A DIAMETER-EAP-Request sent from the NAS to the DIAMETER Server that does not contain an EAP-Packet attribute signals to the DIAMETER Server that it is to initiate EAP authentication with the client. Upon receipt of a DIAMETER-EAP-Request, A DIAMETER Server MUST issue a reply. The reply may be either: 1) a DIAMETER-EAP-Response containing an EAP-Request in at lease one EAP-Packet attribute, 2) a DIAMETER-EAP-Ack containing an EAP-Packet of type "success", or 3) a DIAMETER-EAP-Reject containing an EAP-Packet of type "failure". A Command-Unrecognized packet is returned if the server does not support the EAP extensions. A summary of the DIAMETER-EAP-Request packet format is shown below. The fields are transmitted from left to right Code Flags Ver Command Identifier Length Authenticator Message Integrity Code Attributes Calhoun, Rubens & Aboba [Page 12]

13 Code 254 for DIAMETER. Flags The Following bits MAY be used in the Access-Request: 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 0x2 - (Bit 11) All attributes in packets are encrypted. 0x4 - (Bit 10) Authenticate-Only 0x8 - (Bit 9) Authorize-Only See [7] for more information on the encryption algorithm used. Version MUST be set to 2 Command 300 for DIAMETER-EAP-Request Identifier The Identifier field MUST be changed whenever the content of the Attributes field changes, and whenever a valid reply has been received for a previous request. For retransmissions, the Identifier MAY remain unchanged. Length The total length of the message, including this header. Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet Shared Secret ) Calhoun, Rubens & Aboba [Page 13]

14 Attributes The Attribute field is variable in length, and contains a list of zero or more Attributes. It MAY contain one or more EAP-Packet attributes. If it does not contain an EAP-Packet attribute, it is an indication to the server that server that EAP should be initiated by the server. See the description on EAP-Packet attribute for more information on its use. DIAMETER attributes which are normally found in an Access-Request MAY be present in the request. 3.2 DIAMETER-EAP-Response Description DIAMETER-EAP-Response packets are sent by the DIAMETER Server to the NAS. They contain the next EAP-Request packet to be passed to the client. The DIAMETER-EAP-Response MUST contain at least one EAP-Packet attribute. After issuing the included EAP-Request to the client, the NAS remains in a state where it awaits further EAP-Responses from the client. A summary of the DIAMETER-EAP-Request packet format is shown below. The fields are transmitted from left to right Code Flags Ver Command Identifier Length Authenticator Message Integrity Code Attributes Calhoun, Rubens & Aboba [Page 14]

15 Code 254 for DIAMETER. Flags The Following bits MAY be used in the Access-Request: 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 0x2 - (Bit 11) All attributes in packets are encrypted. 0x4 - (Bit 10) User Authenticated Only 0x8 - (Bit 9) User Authorized Only See [7] for more information on the encryption algorithm used. Version MUST be set to 2 Command 301 for DIAMETER-EAP-Response Identifier The Identifier field is a copy of the Identifier field of the DIAMETER-EAP-Request which caused this DIAMETER-EAP-Ack to be sent. Length The total length of the message, including this header. Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet Shared Secret ) Calhoun, Rubens & Aboba [Page 15]

16 Attributes The Attribute field MUST contains at least one EAP-Packet attribute which contains an EAP-Request packet. 3.3 DIAMETER-EAP-Ack Description DIAMETER-EAP-Ack packets are sent by the DIAMETER Server to the NAS. They contain the next EAP-Request or EAP-Success packet to be passed to the client. The DIAMETER-EAP-Ack packet MUST contain at least one EAP-Packet attribute. After issuing the included EAP-Success packet to the client, the NAS should end the authentication phase with a positive response. A summary of the DIAMETER-EAP-Ack packet format is shown below. The fields are transmitted from left to right Code Flags Ver Command Identifier Length Authenticator Message Integrity Code Attributes Code 254 for DIAMETER. Calhoun, Rubens & Aboba [Page 16]

17 Flags The Following bits MAY be used in the Access-Request: 0x1 - (Bit 12) TimeStamp is included in the Authenticator Field. 0x2 - (Bit 11) All attributes in packets are encrypted. 0x4 - (Bit 10) User Authenticated Only 0x8 - (Bit 9) User Authorized Only See [7] for more information on the encryption algorithm used. Version MUST be set to 2 Command 302 for DIAMETER-EAP-Ack Identifier The Identifier field is a copy of the Identifier field of the DIAMETER-EAP-Request which caused this DIAMETER-EAP-Ack to be sent. Length The total length of the message, including this header. Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet Shared Secret ) Attributes The Attribute field contains only a single EAP-Packet attribute which contains an EAP-Request packet. Calhoun, Rubens & Aboba [Page 17]

18 3.4 DIAMETER-EAP-Reject Description DIAMETER-EAP-Reject packets are sent by the DIAMETER Server to the NAS. They are sent in response to a DIAMETER-EAP-Request that results in an authentication failure. DIAMETER-EAP-Reject packets contain at least one EAP-Packet attribute containing an EAP failure packet. After issuing the included EAP failure packet to the client, the NAS should end the authentication phase with a negative result. A summary of the DIAMETER-EAP-Reject packet format is shown below. The fields are transmitted from left to right Code Flags Ver Command Identifier Length Authenticator Message Integrity Code Attributes Code 254 for DIAMETER. Flags The Flag field is used as defined in [7]. Version MUST be set to 2 Calhoun, Rubens & Aboba [Page 18]

19 Command 303 for DIAMETER-EAP-Reject Identifier The Identifier field is a copy of the Identifier field of the DIAMETER-EAP-Request which caused this DIAMETER-EAP-Reject to be sent. Length The total length of the message, including this header. Authenticator The Authenticator field is a random 16 octet value. If the Timestamp option is supported, the first four octets contain a timestamp of when the packet was sent from the peer. Message Integrity Code This field contains an MD5 hash of the following: MD5( packet Shared Secret ) Attributes The Attribute field contains only a single EAP-Packet attribute which contains an EAP-Request packet. Other attributes valid on an Access-Reject message may also be present. 4. Attribute Name and Attribute Code Attribute Name: EAP-Packet Attribute Code: Attribute Meanings 5.1 EAP-Packet Description This attribute is used to contain the actual EAP-Requests to be sent from the DIAMETER server to the client (DIAMETER-EAP-Ack and DIAMETER-EAP-Reject) and the EAP-Responses to be sent from the client to the DIAMETER server (DIAMETER-EAP-Requests). These EAP-Requests and Responses are exactly as defined in [1]. Calhoun, Rubens & Aboba [Page 19]

20 Attribute Type Length Flags Sequence Number String... Type 300 for EAP-Packet Length >= 6 Flags The Flags field indicates how the NAS or DIAMETER Server MUST react to the attribute. The following values are currently supported: 1 - The Device MUST support this attribute. If the attribute is NOT supported, the device MUST reject the Command. If this flag is not set, then the device MAY accept the command regardless of whether or not the particular attribute is recognized. This bit MUST be set. 2 - If this bit is set, the contents of the attributes are encrypted. Note that the attribute header is NOT encrypted in this case. See [7] for more information on the encryption algorithm. Sequence Number The Sequence Number field is used in order to build a "history" of the transaction. The EAP-Packet attribute with the highest Sequence Number represents the current packet to process. The history is passed along in each request/responses in order in order to support the concept of DIAMETER backup servers, as described earlier. String The String field is the exact EAP packet data to be transported from client to server or server to client. It is not Null terminated and may contain arbitrary binary values. Calhoun, Rubens & Aboba [Page 20]

21 7. Acknowledgments Thanks to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space. 8. References [1] L. J. Blunk, J. R. Vollbrecht. "PPP Extensible Authentication Protocol (EAP)." draft-ietf-pppext-eap-auth-02.txt, Merit Network, Inc., June, [2] P.R. Calhoun, A. Rubens, B. Aboba. "Extensible Authentication Protocol Support in RADIUS" US Robotics Access Corp., Merit Network, Inc., Microsoft Corp, February, [3] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authentication Dial In User Service (RADIUS)." RFC 2058, Livingston, Merit, Daydreamer, January, [4] C. Rigney. "RADIUS Accounting." RFC 2059, Livingston, January, [5] R. Rivest, S. Dusse. "The MD5 Message-Digest Algorithm", RFC 1321, MIT Laboratory for Computer Science, RSA Data Security Inc., [6] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." draft-bradner-key-words-02.txt, Harvard University, August, [7] P.R. Calhoun, A. Rubens, "DIAMETER", Internet-Draft, March Calhoun, Rubens & Aboba [Page 21]

22 9. Authors Addresses Pat R. Calhoun US Robotics Access Corp N. McCormick Blvd. Skokie, IL Phone: Allan C. Rubens Merit Network, Inc Plymouth Rd. Ann Arbor, MI Phone: Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA Phone: Calhoun, Rubens & Aboba [Page 22]