Authentication, Authorization and Accounting Frank M. Alfano Internet Draft Peter J. McCann Document: draft-alfano-aaa-qosreq-01.txt Tom Towle Expires: April 2004 Richard Ejzak Lucent Technologies Hannes Tschofenig Siemens October 2003 Requirements for a QoS AAA Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes requirements for a protocol that would perform Authentication, Authorization, and Accounting for Quality-of- Service reservations. Such a protocol would be used by entities to authenticate a user's reservation request, to ensure that the reservation is authorized and to provide accounting functionality. The requirements covered in this document primarily address the communication of AAA protocols and not the QoS signaling protocols, although they have to provide some degree of interworking. Therefore, we list a minimal set of requirements on supported QoS signaling protocols. Alfano, et al. Expires - April 2004 [Page 1] Requirements for a QoS AAA Protocol October 2003 Table of Contents 1. Introduction...................................................2 1.1 QoS Signaling..............................................3 1.2 Architecture...............................................3 2. Keywords.......................................................5 3. Terminology....................................................5 4. Generic Requirements on a QoS Signaling Protocol...............7 4.1 User Authentication/Authorization..........................7 4.2 Support for different authorization scenarios..............7 4.3 Providing Authorization Information........................7 4.4 Reauthorization............................................8 4.5 Integrity and Replay Protection............................8 4.6 Confidentiality Protection.................................8 5. Generic Requirements on a QoS AAA Protocol.....................9 5.1 Inter-domain Support.......................................9 5.2 Identity-based Routing.....................................9 6. Requirements for QoS Authentication............................9 6.1 Flexible Authentication Support............................9 7. Requirements for QoS Authorization............................10 7.1 Making an Authorization Decision..........................10 7.2 Triggering an Authorization Process.......................10 7.3 Associating QoS Reservations and Application State........10 7.4 Dynamic Authorization.....................................11 7.5 Bearer Gating.............................................11 8. Requirements for QoS Accounting...............................11 8.1 Accounting Records........................................11 8.2 Accounting Rules..........................................11 8.3 Sending Accounting Records................................12 8.4 Failure Notification......................................12 8.5 Accounting Correlation....................................12 9. Interaction with other AAA Applications.......................12 10. Use Scenario.................................................13 10.1 Bearer Gating............................................14 10.2 Loss of Connectivity.....................................14 11. Security Considerations......................................14 12. References...................................................15 13. Author's Addresses...........................................16 1. Introduction To meet the quality-of-service needs of applications such as voice- over-IP, it will often be necessary to explicitly request resources from the network. This will allow the network to identify packets belonging to such application flows and ensure that bandwidth, delay, and error rate requirements are met. By performing admission control Alfano et al. Expires - April 2003 [Page 2] Requirements for a QoS AAA Protocol October 2003 on individual flows, the network can avoid congestion and the resulting high packet drop rates. 1.1 QoS Signaling A variety of protocols can be used to signal QoS information and to make a reservation, such as RSVP, NSIS, SIP/SDP or link-layer specific mechanisms. RSVP [2] is the existing IETF-defined QoS signaling protocol. The Next Steps in Signaling (NSIS) working group [3] is currently developing a general signaling model based on two-layer architecture. In the meantime, deployments such as 3rd generation cellular networks are defining their own reservation procedures: these include link- layer specific means, such as the PDP Context Activation procedures of 3GPP [4,5] or the service instance establishment procedures of 3GPP2 [6]. This list can easily be extended. In other areas QoS signaling mechanisms are often tightly coupled to the application signaling. In the 3GPP/3GPP2 IP Multimedia Core Network subsystems the Session Initiation Protocol (SIP) [7] and Session Description Protocol (SDP) [8] are essentially being used to request resource reservations from the network. Special purpose protocols are used for communication between the SIP servers and network elements. 1.2 Architecture This draft describes requirements on a AAA protocol for QoS reservations stemming from the new (primarily wireless) network deployments in light of recent efforts to revisit QoS signaling within the IETF. The goal is to meet these requirements of network operators while at the same time supporting a variety of QoS signaling protocols and avoiding the need for monolithic, vertically integrated applications (such as e.g., a SIP proxy server in every router). A high-level picture of the resulting architecture is shown in Figure 1. Alfano et al. Expires - April 2003 [Page 3] Requirements for a QoS AAA Protocol October 2003 +-------------+ | Resource | | Authorizing | | Entity | +-----+-------+ | | /-\----+-----/\ //// \\\\ || || | AAA Cloud | || || \\\\ //// \-------+-----/ | +-------------+ +---+--+ | Entity | Application | | | Requesting |<<=================+ NE +==========>> | Resource | Flow | | +-------------+ +------+ Figure 1: Architecture Figure 1 depicts an entity requesting a resource, a network element (NE) through which application flows need to pass (i.e., an entity which enforces the QoS reservation), a cloud of AAA servers and an entity authorizing the QoS request. In many cases, the authentication terminates at the user's home network where a database containing subscriber records is located. This is often the entity that executes the authorization decision. Finally, there might be an interaction with an application signaling protocol. Note that the entity authorizing the QoS reservation request might be a AAA server, an application server or another entity. These entities are collectively referred as the "Resource Authorizing Entity" in Figure 1. The term "AAA Cloud" is used to refer to the network of AAA proxies and brokers. Furthermore, there might be more than one network element that needs to interact with the AAA infrastructure although Figure 1 depicts only one for clarity. Similarly, a given user might support different authentication methods; he might have more than one home network; or, he might use different means of authorization. The remainder of this document is organized as follows: Section 3 defines some terms that are used in subsequent discussion. Alfano et al. Expires - April 2003 [Page 4] Requirements for a QoS AAA Protocol October 2003 Section 4 describes some generic requirements for a QoS signaling protocol. Section 5 gives generic requirements for a QoS AAA protocol. Section 6 gives requirements specific to Authentication. Section 7 gives requirements specific to Authorization. Section 8 gives requirements specific to Accounting. Section 9 discusses the relationship of a QoS AAA protocol to other AAA applications. Section 10 gives an example use scenario. Finally, Section 11 outlines some security considerations. 2. Keywords The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [9]. 3. Terminology Accounting Rules An accounting rule is a collection of data that identifies one or more IP flows and provides related information. An accounting rule defines the accounting treatment such as on-line (i.e., pre-paid) or off-line accounting. The data may also identify, for example, volume or time based accounting, rating information, termination actions for on-line accounting (e.g., drop or re-route packets), record correlation identifiers, etc. Application Server An application server is a network entity that exchanges signaling messages with an application endpoint. It may be a source of authorization for QoS-enhanced application flows. For example, a SIP server is one kind of application server. Application Endpoint An application endpoint is an entity in an end user device that exchanges signaling messages with application servers or directly with other application endpoints. Based on the result of this signaling, the endpoint will make a request for QoS from the network. For example, a SIP User Agent is one kind of application endpoint. Authorizing Entity The authorizing entity is that entity responsible for authorizing QoS requests for a particular application flow. This may be a AAA server (with a subscriber database) or an application server or some other entity. Alfano et al. Expires - April 2003 [Page 5] Requirements for a QoS AAA Protocol October 2003 Network Element A network element is a network entity such as an IP router on the path between two endpoints, through which IP packets belonging to application flows pass. Typically only a small subset of the network elements along a path communicates with the AAA infrastructure for the purpose of QoS authorization. In a typical service provider scenario, the first-hop router will be required to play this role. A motivation of this architectural simplification is referred to as the New Jersey Turnpike Model and is described in detail in Section 4 of [11]. Network elements are responsible for enforcing the result of the authorization process. Subscriber Database A Subscriber Database holds information related to network users such as information about their subscribed service. A user might, for example, have a subscription for a 'gold' service that authorizes him for higher QoS parameters than 'normal' users. Termination Actions On-line accounting allows the on-line accounting authorization entity to terminate flows in real time. A termination action defines the action to be taken by the network element for the case where a flow has been terminated. For example flow packets might be dropped, might be redirected, or might be allowed to continue but not be counted. QoS signaling protocol A protocol used to carry QoS information between two end points and intercepted by entities along the path. The QoS signaling protocols discussed in this context follow the data path (i.e., they are path-coupled). QoS AAA protocol The QoS AAA protocol runs between a network element (acting as a AAA client) and the resource authorizing entity (acting as a AAA server). For example, upon receipt of a QoS request from the resource requesting entity, the network element might copy authentication credentials and QoS flow information into a AAA message which is forwarded to the resource authorizing entity, possibly via one or more proxy AAA servers. The authorizing entity returns an authorization decision (yes/no) for the flow, and accounting data would be sent to the authorizing entity while the flow is active. Alfano et al. Expires - April 2003 [Page 6] Requirements for a QoS AAA Protocol October 2003 4. Generic Requirements on a QoS Signaling Protocol While the details of a particular QoS signaling protocol are outside the scope of this document, we do list here some generic requirements that any QoS signaling protocol must meet in order to act as a front end for a QoS AAA protocol. 4.1 Identification of Resource Authorizing Entity The QoS signaling protocol MUST carry information sufficient to identify the resource authorizing entity. Note that the network element and the resource authorizing entity will often be in different administrative domains. 4.2 User Authentication/Authorization The QoS signaling protocol MUST carry information to allow the authorizing entity to compute the authorization decision. In most cases this information will allow the authorizing entity to authenticate the user. Note that authentication is not necessarily required since authorization can also be accomplished for an anonymous user. Section 5.7.1 of [13] points to these requirements for the NSIS area. RSVP extended the admission control procedure by adding user authentication as described in [14]. Additional authorization capability has been added with the help of authorization tokens as described in [15] and [16]. It is important to provide cryptographic authentication or to protect the authorization information (e.g., tokens) appropriately to counter identity spoofing and attacks against the authorization information (e.g., replay attacks). These attacks might lead to fraud as described in [17]. 4.3 Support for different authorization scenarios [11] and [12] describe a two and a three party approach for computing the authorization decision. The QoS signaling protocol SHOULD support these general authorization scenarios. This wide range of authorization scenarios is required to make the QoS AAA protocol applicable in all deployment environments. 4.4 Providing Authorization Information The QoS signaling protocol MUST carry sufficient information between the authorizing entity and the enforcing entity (and vice versa) to compute an authorization decision and to execute it. Alfano et al. Expires - April 2003 [Page 7] Requirements for a QoS AAA Protocol October 2003 This information might include flow identification, QoS objects for determining the authorization (in the direction to the authorizing entity) as well as for provisioning (in the direction from the authorizing entity to the enforcing entity) and price information. Flow information can be used for determining the authorization decision in those case where it meaningful. In many cases it MUST be possible to determine the price of the QoS reservation and to communicate the price to the user (or at least to provide sufficient information to allow the user to compute the price). As described in [11] one or both end-points may need to know the price information. 4.5 Reauthorization The QoS signaling protocol MUST allow the network to trigger a reauthorization procedure at any time to support periodic and event triggered authorization. 4.6 Integrity and Replay Protection The QoS signaling protocol MUST be integrity and replay protected. To support this requirement each signaling message would, for example, carry a keyed message digest to ensure that only valid requests are granted by the network. This is especially important when a user is being held responsible for charges associated with a QoS session. Prior to providing integrity and replay protection it is necessary to dynamically establish session keys. This is particularly important in a mobile environment as described in Section 7 of [11]. Integrity and replay protection is required for NSIS as described in [17] (see Section 4.2 and 4.3 of [17]). 4.7 Confidentiality Protection The QoS signaling protocol MUST provide confidentiality protection in those cases where authorization information is vulnerable to replay attacks. As an example, single-use authorization tokens may rely on the use of a secure channel. An adversary who is able to eavesdrop authorization tokens might be able to reuse them. They only provide a proof of possession and do not serve the purpose of cryptographic authentication where a liveness guarantee has to be provided by the parties executing the protocol. Alfano et al. Expires - April 2003 [Page 8] Requirements for a QoS AAA Protocol October 2003 5. Generic Requirements on a QoS AAA Protocol In this section we list some high-level requirements that must be met by a QoS AAA protocol. 5.1 Inter-domain Support The QoS AAA protocol MUST support inter-domain operation. In particular, users may roam outside their home network, leading to a situation where the network element and authorizing entity are in different administrative domains. This implies the existence of a roaming agreement between the two networks. In general, one or both end-points involved in a communication may be roaming, meaning that the network elements along the data path may belong to multiple administrative domains, none of which are the home domain of either end-point. 5.2 Identity-based Routing The QoS AAA protocol MUST route AAA requests to the authorizing entity based on the identity information given in the QoS signaling protocol. 6. Requirements for QoS Authentication In this section we list some QoS AAA requirements specific to authentication and authorization. 6.1 Flexible Authentication Support The QoS AAA protocol MUST support verification of authentication information present in QoS signaling messages. The QoS AAA protocol MUST support a variety of different authentication protocols. Different QoS architectures are likely to have a different security infrastructure with different requirements. The PacketCable architecture, for example, heavily utilizes Kerberos whereas the 3GPP architecture makes use of the UMTS AKA algorithm. Alfano et al. Expires - April 2003 [Page 9] Requirements for a QoS AAA Protocol October 2003 7. Requirements for QoS Authorization In this section we list some QoS AAA requirements specific to authorization. 7.1 Making an Authorization Decision The QoS AAA protocol MUST exchange sufficient information between the authorizing entity and the enforcing entity (and vice versa) to compute an authorization decision and to execute this decision. This information might include flow identification, QoS objects for determining the authorization as well as for provisioning and price information. The flow identification provided to the QoS AAA protocol MUST allow flow information to be under-specified ("wild carded"). This might be the case for aggregates and when endpoints are unknown at the time of initial resource authorization. 7.2 Triggering an Authorization Process The QoS AAA protocol MUST allow periodic and event triggered execution of the authorization process. The trigger for re-authorization might be originated at the enforcing entity or even at the authorizing entity. In any case it should be possible to carry information with the QoS AAA protocol to allow the enforcing or some other trusted entity to determine when to trigger authorization. For example, a time-based trigger, a volume-based trigger or even triggers based on consumed financial resources might lead to a reauthorization procedure. 7.3 Associating QoS Reservations and Application State The QoS AAA protocol MUST carry information sufficient for an application server to identify the appropriate application session. This allows an application session to be associated with a particular QoS reservation. Note that if flow information is sufficient to identify an application session then no separate identifier is required. Although this is not true for NSIS other QoS signaling protocols use different identifiers. Alfano et al. Expires - April 2003 [Page 10] Requirements for a QoS AAA Protocol October 2003 7.4 Dynamic Authorization The QoS AAA protocol MUST support dynamic authorization; that is, it MUST be possible to push updates towards the network element(s) from authorizing entities. This requirement would support runtime application state transitions or even a change in the subscriberÆs profile that would lead to a different authorization state for a specific QoS reservation. 7.5 Bearer Gating The QoS AAA protocol MUST allow the authorizing entity to gate authorized application flows. Even though a user might received an authorization for a given flow, some applications may want to toggle the flow on or off based on application state transitions. This control is called bearer gating. Unlike revocation functionality, gating leaves state information about the QoS reservation in place and it is only temporarily suspended. 8. Requirements for QoS Accounting In this section we list some QoS AAA requirements specific to accounting. 8.1 Accounting Records The QoS AAA protocol MUST define QoS accounting records containing duration or volume (byte count) usage information, or both duration and volume usage information. The records MUST also contain a description of the QoS attributes (e.g., bandwidth, delay, loss rate) that were supported for the flow. 8.2 Accounting Rules The QoS AAA protocol MUST allow the authorizing entity to transfer accounting rules that are applicable to specific flows. These rules would define the on-line ("pre-paid") versus off-line ("post-paid") nature of the accounting as well as convey other associated parameters such as record identifiers, rating information, usage quota, on-line termination actions, etc. The QoS AAA protocol MUST allow for accounting rules to be provided at authorization time as well as to be pushed later as dynamic updates. Alfano et al. Expires - April 2003 [Page 11] Requirements for a QoS AAA Protocol October 2003 8.3 Sending Accounting Records The network element MUST send accounting records for a particular application flow to the authorizing entity for that flow or to another entity identified by the authorizing entity. 8.4 Failure Notification The QoS AAA protocol MUST allow the network element to report failures to the authorizing entity. These failures (such as loss of connectivity due to movement of a mobile node or other reasons for packet loss) primarily address problems in the data path and do not cover problems with the QoS AAA protocol. 8.5 Accounting Correlation The QoS AAA protocol MUST support the exchange of sufficient information to allow for correlation between accounting records generated by the network elements and accounting records generated by an application server. For example, an application server might create and pass an accounting correlation identifier to the network element. This correlation identifier would then be stored for inclusion in subsequent accounting records. This would allow the home network to link the accounting information of the network element with those of the application server. 9. Interaction with other AAA Applications It is likely that an endpoint attached to a first-hop network element was authenticated and authorized for basic, best-effort Internet access prior to requesting any special QoS from the network. If the subscriber database for basic network access is the same as the one containing a QoS subscription, it may be expeditious to define some interactions between the AAA protocol used for basic access (e.g., NASREQ [10]) and the one outlined here for QoS. For example, it may be useful to return some QoS-related attributes to the first-hop network element at the time the endpoint is granted basic, best- effort access. This would allow for some future QoS requests to be granted based on the cached profile, rather than requiring a round- trip to the home subscriber database. This gives rise to the following requirement: The QoS AAA protocol MUST define a QoS profile that can be re-used in other AAA applications. Still, it must be possible to execute the QoS AAA protocol independently of other AAA protocols applications. Alfano et al. Expires - April 2003 [Page 12] Requirements for a QoS AAA Protocol October 2003 Also, it may be useful to allow application servers to push QoS authorization information to a network element prior to any explicit request from the endpoint. This could support application endpoints that do not support an explicit QoS signaling mechanism. In this case, the authorization may be pushed via the home AAA server, which presumably knows to which NAS the endpoint is currently attached. Alternatively, the QoS AAA protocol may define some sort of redirection facility that would allow application servers to send AAA messages directly to selected network elements such as a NAS. This operation could be considered a special case of dynamic authorization where no explicit request for QoS was made prior to the authorization: The QoS AAA protocol MUST support dynamic authorization initiated by the authorizing entity. 10. Scenarios This section provides a few example scenarios: An application in a mobile node wants to open a video session with a video server. The mobile node and the video server negotiate the resources to be used for the session and for which the application will be financially responsible. When resource negotiation has completed, the video server stores the resource information and assigns a session identifier to the information that can be used as the primary key for later information queries. This identifier has to be known to both parties - the mobile node and the video server. The mobile node starts to use a QoS signaling protocol. The signaling message will hit a network element (most likely the first hop router) in the visited network. The video server and the network element will verify that the mobile node has not requested more resources than what were negotiated and for which the application has agreed to be financially responsible. To link the application protocol session with this particular resource request, the mobile node passes the session identifier received from the video server to the network element via the QoS signaling protocol. The network element makes a request to the video server (or some other centralized node) as identified in the session identifier. The video server passes the relevant QoS state information to the network element in an answer message, associating the origin host information from the request with the state information stored by the video server. (This can then be used later for pushing information to the network element.) All accounting messages from a network entity include an accounting correlation id. Alfano et al. Expires - April 2003 [Page 13] Requirements for a QoS AAA Protocol October 2003 10.1 Bearer Gating The video server can control the flow of packets on the network element by sending packet flow gating information in the answer message delivered for resource authorization. If the flow of packets is not immediately enabled, some event at the video server will trigger the server to enable the flow. The video server sends a request containing flow gating information to the network element to allow the flow of packets. The network element returns the state of the packet flow in the response message to the video server. 10.2 Loss of Connectivity The network element determines connectivity to the end host has been lost. The video server needs this information in order to take corrective action, charge appropriately, and/or release resources associated with the session. The network element informs the video server of the loss of connectivity in a request message containing state information of the network element. The video server acknowledges the request in an answer message. The video server may then issue a session abort request message to other network functional entities. 11. Security Considerations The QoS AAA protocol whose requirements are given in this draft assumes that a trust relationship exists between the authorizing entity and the network element. This trust relationship does not need to be pre-existing at the protocol startup but could also be dynamically established. The relationship may be direct or it may be indirect via a AAA cloud consisting of brokers and proxies. Each link in this chain of relationships MUST be secured to prevent spoofed authorizations. This relationship implies that the bearer element should grant service based on the decision of the authorizing entity, presumably because the used resources will be paid for. The establishment of a trust relationship between the involved networks therefore also implies the setup of a financial settlement. The authentication outlined in Section 6 MUST be cryptographically strong and protected against replay and other attacks. Various threats against a QoS signaling protocol (and on the AAA infrastructure) are described in [17]. Once QoS resources have been authorized, it may be possible for an unauthorized party to subvert them for its own use. Steps MUST be taken to prevent an adversary from injecting or spoofing data packets, which could then receive preferred treatment (i.e., steal Alfano et al. Expires - April 2003 [Page 14] Requirements for a QoS AAA Protocol October 2003 other user's QoS resources). Although beyond the scope of this document cryptographic protection of the data traffic should be considered either at the network or at the link layer. Among other things, Section 9 implies to off-load some authorization decisions from the user's home network to the visted network. Making the user's profile available to entities outside the home network might raise some privacy concerns. 12. Reference [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Braden, R., Zhang, L., Berson, S., Herzog, S., Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [3] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J., and Van den Bosch, S., "Next Steps in Signaling: Framework", Internet Draft, Internet Engineering Task Force, September 2003. Work in progress. [4] 3GPP TS 29.208, "End-to-end Quality of Service (QoS) Signaling Flows", April 2003. [5] 3GPP TS 29.207, "Policy control over Go interface", March 2003. [6] 3GPP2 C.S0017-0 (also TIA IS-707-A), "Data Service Options for Spread Spectrum Systems." [7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and Schooler, E., "SIP: Session Initiation Protocol", RFC 3261, June 2002. [8] Handley, M., Jacobson, V., Perkins, C., "SDP: Session Description Protocol", Internet Draft, Internet Engineering Task Force, September 2003. Work In Progress. [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [10] Calhoun, P., Zorn, G., Spence, D., Mitton, D., "Diameter Network Access Server Application", Internet Draft, Internet Engineering Task Force, October, 2003. Work In Progress. [11] H. Tschofenig, M. Buechli, S. Van den Bosch and H. Schulzrinne: "NSIS Authentication, Authorization and Accounting Issues", Alfano et al. Expires - April 2003 [Page 15] Requirements for a QoS AAA Protocol October 2003 Internet Draft, Internet Engineering Task Force, March 2003. Work in progress. [12] H. Tschofenig, M. Buechli, S. Van den Bosch, H. Schulzrinne and T. Chen: "QoS NSLP Authorization Issues", Internet Draft, Internet Engineering Task Force, June 2003. Work in progress. [13] M. Brunner: "Requirements for QoS signaling protocols", Internet Draft, Internet Engineering Task Force, August 2003. Work in progress. [14] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., Hess, R.: "Identity Representation for RSVP", RFC 3182, October, 2001. [15] L. Hamer, B. Gage, and H. Shieh: "Framework for session set-up with media authorization," RFC 3521, Internet Engineering Task Force, April 2003. [16] L. Hamer, B. Gage, B. Kosinski, and H. Shieh: "Session Authorization Policy Element", RFC 3520, Internet Engineering Task Force, April 2003. [17] Tschofenig, H. and D. Kroeselberg: "Security Threats for NSIS", Internet Draft, Internet Engineering Task Force, June 2003. 13. Author's Addresses Frank M. Alfano Lucent Technologies Rm 9C-226L 1960 Lucent Lane Naperville, IL 60563 Phone: +1 630 979 7209 Email: falfano@lucent.com Peter J. McCann Lucent Technologies Rm 9C-226R 1960 Lucent Lane Naperville, IL 60563 Phone: +1 630 713 9359 Email: mccap@lucent.com Alfano et al. Expires - April 2003 [Page 16] Requirements for a QoS AAA Protocol October 2003 Thomas T. Towle Lucent Technologies Rm 9C-229 1960 Lucent Lane Naperville, IL 60563 Phone: +1 630 979 7303 Email: ttowle@lucent.com Richard Ejzak Lucent Technologies Rm 7H-245 1960 Lucent Lane Naperville, IL 60563 Phone: +1 630 979 7036 Email: ejzak@lucent.com Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Intellectual Property Statement At the time of submission the authors are not aware of any intellectual property rights that pertain to the implementation or use of the technology described in this document. However, this does not preclude the possibility that Lucent Technologies, Inc. or other entities may have such rights. The patent licensing policy of Lucent Technologies, Inc. is on file with the IETF Secretariat. The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. Alfano et al. Expires - April 2003 [Page 17] Requirements for a QoS AAA Protocol October 2003 The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Alfano et al. Expires - April 2003 [Page 18]