NSIS H. Tschofenig Internet-Draft J. Kross Expires: January 10, 2005 Siemens AG July 12, 2004 Extended QoS Authorization for the QoS NSLP draft-tschofenig-nsis-qos-ext-authz-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. This Internet-Draft will expire on January 10, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Proper authorization is essential for a Quality of Service signaling protocol. Three authorization models have been identified: a two-party model, a token-based three-party model, and a generic three-party model This document discusses two possible solution for the generic three-party model: a challenge/response based and an EAP-based approach. Tschofenig & Kross Expires January 10, 2005 [Page 1] Internet-Draft Extended QoS NSLP Authorization July 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Alternatives . . . . . . . . . . . . . . . . . . . . 6 4.1 Challenge/Response-based Authentication/Authorization . . 6 4.2 EAP-based Authentication/Authorization . . . . . . . . . . 7 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Challenge/Response-based Authentication/Authorization . . 10 5.2 EAP-based Authentication/Authorization . . . . . . . . . . 10 5.3 Integrity Object . . . . . . . . . . . . . . . . . . . . . 11 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Security considerations . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Tschofenig & Kross Expires January 10, 2005 [Page 2] Internet-Draft Extended QoS NSLP Authorization July 2004 1. Introduction Three authorization models are described in Section 3.6 of [I-D.ietf-nsis-qos-nslp]: o Two party approach o Token based three party approach o Generic three party approach The two party approach is sketched in Section 3.6.1 of [I-D.ietf-nsis-qos-nslp], the token based three party approach is described in Section 3.6.2 of [I-D.ietf-nsis-qos-nslp] (based on [RFC3520] and [RFC3521]), and an overview of the generic three party approach is provided with Section 3.6.3 of [I-D.ietf-nsis-qos-nslp]. It is obvious that these authorization approaches offer different security and address different deployment scenarios. This document focuses on a more detailed discussion of the generic three party approach. Section 3 provides an overview of the generic three party approach. Section 4 lists two possible solution approaches. For completeness, object payloads are described in Section 5. A short conclusion is given in Section 6. Tschofenig & Kross Expires January 10, 2005 [Page 3] Internet-Draft Extended QoS NSLP Authorization July 2004 2. Terminology 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 [RFC2119]. Tschofenig & Kross Expires January 10, 2005 [Page 4] Internet-Draft Extended QoS NSLP Authorization July 2004 3. Overview This section offers message flows and protocol-specific details about authorization for QoS reservations for the generic three party approach. Figure 1 illustrates a case where an entity A (e.g., an end host) sends an NSIS QoS signaling message towards an entity B (e.g, a NSIS aware router). This request cannot be authorized by entity B itself but is rather forwarded to another entity C. The protocol used between entity A and entity B is based on NSIS whereas the protocol used between entity B and entity C is, for example, Diameter. A proposal for a Diameter QoS application is provided with [I-D.alfano-aaa-qosprot]. +--------------+ | Entity C | | authorizing | | resource | | request | +-----------+--+ ^ | | | QoS | | QoS authz| |authz req.| | res. | | QoS | v +-------------+ request +--+-----------+ | Entity |----------------->| Entity B | | requesting | | performing | | resource |granted / rejected| QoS | | A |<-----------------| reservation | +-------------+ +--------------+ Figure 1: Three party approach In the following, two alternative solution proposals for this model are shown: o Challenge/Response-based Authentication and Authorization o EAP-based Authentication and Authorization Tschofenig & Kross Expires January 10, 2005 [Page 5] Internet-Draft Extended QoS NSLP Authorization July 2004 4. Protocol Alternatives 4.1 Challenge/Response-based Authentication/Authorization Figure 2 shows a message flow for the generic three party approach with a challenge-response mechanism. In this case, after entity B asked entity C for authorization of a QoS request, entity C issues a challenge to entity A, which is passed on by entity B. Entity A resubmits its QoS request, including a response to the challenge. This is again forwarded to entity C, which verifies whether entity A is the one it claims to be, and if so, and after checking for entity A's authorization to use the resources it requests, either grants or denies the request. +--------------------+ | Entity C | | authenticating / | | authorizing | | resource | | request | +----+-------------+-+ ^ |c ^ | | |h |R | | |a |e | | |l |s | QoS | |l |p |authz QoS | |e |o | res. authz| |n |n | req.| |g |s | | |e |e | QoS | v | v +-------------+ request +---------+----------+ | Entity |----------------->| Entity B | | requesting | challenge | performing | | resource |<-----------------| QoS | | A | response | reservation | | +----------------->| | | |granted / rejected| | | |<-----------------+ | +-------------+ +--------------------+ Figure 2: Three party challenge-response based approach Please note that the QoS NSLP does not explicitly send a successful response message for the challenge/response protocol after a QoS reservation request. Instead the successful outcome of the protocol Tschofenig & Kross Expires January 10, 2005 [Page 6] Internet-Draft Extended QoS NSLP Authorization July 2004 run is implicated by the successul commitment of the entire QoS reservation. An unsuccessful outcome of the challenge/response protocol, however, would be indicated explicitly by a reject message returned immediately - the error codes still need to be defined in [I-D.ietf-nsis-qos-nslp]. The properties of this approach are intentionally similar to the digest-authentication used with SIP (see [RFC3261]). This approach provides better security properties than a token-based authorization approach since a stronger liveness check needs to be provided. The QoS request and the result of the challenge/response authentication and authorization need to be associated with each other. Furthermore, it is necessary to bind subsequent refresh messages to the initial authentication and authorization protocol step. This is typically accomplished with the establishment of session keys and the protection of signaling messages between entity A and B. The necessary steps for the QoS NSLP are the following: o A challenge/response protocol needs to be defined or selected. A number of protocols can be reused, including the digest-authentication approach listed in [RFC3261]. This authentication and key exchange protocol needs to provide mutual authentication, replay protection and session key establishment. It seems to be reasonable to investigate some of the requirements raised in [I-D.walker-ieee802-req] regarding the selection of such a protocol. o Integrity protection needs to be applied to signaling messages exchanged between the entity A and entity B once a session key is available. o Since the authentication and key establishment is executed betwen entity A and entity C, it is necessary to forward the established keying material from entity C to entity B (using AAA protocols). o In some circumstances it might be necessary to combine the security protection at the NTLP with the security protection at the NSLP. This can, for example, be accomplished by combining the session keys of both security protocols as suggested in [I-D.puthenkulam-eap-binding]. Such a binding is necessary if the reused challenge/response protocol is also used in other protocols. 4.2 EAP-based Authentication/Authorization The Extensible Authentication Protocol (EAP) serves as a container Tschofenig & Kross Expires January 10, 2005 [Page 7] Internet-Draft Extended QoS NSLP Authorization July 2004 for EAP methods. EAP methods themselves are authentication and key exchange protocols. EAP is agnostic with regard to the underlying protocol carrying the EAP payloads. The main difference between the EAP-based approach discussed in this section, and the challenge/response based approach discussed in Section 4.1 is related to the flexible choice of authentication and key exchange protocols with EAP on the one hand, and some degree of inefficiency introduced with EAP (such as the EAP-Request/Identity, EAP-Response/Identity and EAP-Success messages) on the other hand. Due to the usage of EAP in IEEE 802.1X and also in PANA, the security properties have been studied extensively. The discussions in the EAP keying framework (see [I-D.ietf-eap-keying]) are also applicable. Please note that EAP is not necessarily a three party protocol - EAP also supports the two party scenario. An example message flow is shown in Figure 3 which uses the EAP-AKA method [I-D.arkko-pppext-eap-aka] for authentication and session key establishment. Please note that the AAA messages triggered by this exchange are not shown for editorial reasons. +---------+ +---------+ | MN | | R1 | +---------+ +---------+ (a) + <---------------------------------------------> + | Discovery Request/Response (NTLP) | | | (b) | ----------------------------------------------> | | C-Mode | | NTLP/NSLP QoS CREATE Req. | | (EAP-Auth/Authz requested; | Initial | EAP-Identity) | Setup | | (c) | <---------------------------------------------- | | C-Mode | | NTLP/NSLP QoS CREATE Resp. | | (EAP-Request/AKA-Challenge | | (AT_RAND, AT_AUTN, AT_MAC)) | | (Algorithm/Parameter Negotiation) | (d) | ----------------------------------------------> | | C-Mode | | NTLP/NSLP QoS CREATE Req. | | (EAP-Response/AKA-Challenge | | (AT_RES, AT_MAC)) | | (Algorithm/Parameter Negotiation) | +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ Tschofenig & Kross Expires January 10, 2005 [Page 8] Internet-Draft Extended QoS NSLP Authorization July 2004 (e) | Authentication Authorization finished | | Secure channel at the NSLP layer established | +~+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+~+ (f) | <---------------------------------------------- | | NTLP/NSLP QoS CREATE Resp. | | NTLP/NSLP QoS CREATE Req. | | (EAP-Success) | | (Secure Confirmation) | | | + + .......... + + | ----------------------------------------------> | (g) | NTLP/NSLP QoS REFRSH msg | Refresh | | Msg | <---------------------------------------------- | | NTLP/NSLP QoS ACK msg | + + Figure 3: EAP based Auth/Authz exchange using EAP-AKA The message exchange shown in Figure 3 starts with the optional discovery of the next QoS NSLP aware node (messages (a)). The first QoS NSLP message with a resource request is sent with the Network Access Identity and a request to perform EAP-based authentication (message (b)). Note that this exchange assumes that the EAP-Request/ Identity and the EAP-Response/Identity exchange is omitted. This exchange is optional in EAP if the identity can be provided by other means. Router 1 contacts the AAA infrastructure, and the EAP server starts the message exchange. The AAA message communication is not shown. Subsequently, two messages (messages (c) and (d)) are exchanged between the EAP peer and the EAP server which contain EAP-AKA specific information. After successful authentication and authorization, session keys are derived and provided to R1 via AAA mechanisms (see [I-D.ietf-aaa-eap] and [RFC3579]). These session keys can then be used to protect subsequent NSLP messages as indicated by (e). The EAP-Success message can already experience such a protection (see message (f)). Furthermore, it is useful to repeat the previously sent objects. Subsequent refresh messages (g) are protected with the previously established session keys and are therefore associated with the previous authentication and authorization protocol execution. Tschofenig & Kross Expires January 10, 2005 [Page 9] Internet-Draft Extended QoS NSLP Authorization July 2004 5. Payload Formats 5.1 Challenge/Response-based Authentication/Authorization For carrying the credentials for the challenge/response-based authentication and authorization approach within the QoS NSLP, it is proposed to use a new Policy Element, called CR policy element. Its format is shown in Figure 4. +-------------+-------------+-------------+-------------+ | Length | P-Type = AUTHZ_CR | +---------------------------+---------------------------+ | | // CR Packet (Opaque to QoS NSLP) // | | +-------------------------------------------------------+ Figure 4: Format of CR Policy Element CR Packet: The CR Packet contains the information required for the Challenge/Response handshake. Further details will be described in a future version of this document. 5.2 EAP-based Authentication/Authorization Figure 3 illustrates an example message flow for EAP-based authentication and authorization. This section proposes how to integrate the data required for the EAP exchange into the QoS NSLP message format. [I-D.ietf-nsis-qos-nslp] describes the generic format for Policy Elements. It is proposed that the EAP data is carried within a new Policy Element, called EAP Policy Element. It follows the generic format of Policy elements as defined in Appendix A.7.3 of [I-D.ietf-nsis-qos-nslp]. Figure 5 illustrates the specific format. Tschofenig & Kross Expires January 10, 2005 [Page 10] Internet-Draft Extended QoS NSLP Authorization July 2004 +-------------+-------------+-------------+-------------+ | Length | P-Type = AUTHZ_EAP | +---------------------------+---------------------------+ | | // EAP Packet (Opaque to QoS NSLP) // | | +-------------------------------------------------------+ Figure 5: Format of EAP Policy Element EAP Packet: The EAP Packet contains an EAP packet in the format of [RFC3748], section 4. 5.3 Integrity Object A future version of this document will describe the payload format of an Integrity Object. Tschofenig & Kross Expires January 10, 2005 [Page 11] Internet-Draft Extended QoS NSLP Authorization July 2004 6. Conclusion The QoS NSLP has to be provided for the generic three party case in order to be complete. This document discusses two possible solutions: the challenge/response and the EAP-based approach The working group needs to make the following two decisions: o Should a challenge/response or an EAP-based scheme be developed? o Should this work be included in the main QoS NSLP [I-D.ietf-nsis-qos-nslp] document? There are some technical aspects that need to be addressed, as explained throughout the text. Hence, the enhancement is more complex than just adding one new payload to the NSLP. Some security issues and also non-security issues need to be solved. For example, EAP itself is only a container and does not provide fragmentation and reliable transmission of EAP payloads. Carrying EAP within the QoS NSLP requires further investigations since different transport protocols have to be supported by GIMPS (see [I-D.schulzrinne-nsis-ntlp]). These issues have already been discussed in, for example, PANA [I-D.ietf-pana-pana]. Tschofenig & Kross Expires January 10, 2005 [Page 12] Internet-Draft Extended QoS NSLP Authorization July 2004 7. Security considerations Selected security aspects with the challenge/response based approach have been mentioned in Section 4.1 and with respect to EAP in Section 4.2. If security protection is provided by GIMPS (which is an instantiation of the NTLP) and also at the NSLP with the mechanisms discussed in this document, then the two phases should be combined since security vulnerabilities are introduced otherwise. For example, running EAP over TLS for client-side authentication could be one possibility but it raises issues with the discovered man-in-the-middle attack problems for tunneled authentication (see [I-D.puthenkulam-eap-binding]). There is certainly a tradeoff between the flexibility of EAP and the simplicity of a challenge/response protocol. In some scenarios, it is necessary to cope with the 'lying NAS' problem. With the usage of EAP, it is necessary to provide the EAP server with enough information to perform the authorization steps. However, EAP methods themselves are independent of the environment in which they are executed. Hence, an adversary (acting as an NSIS NSLP node) could misuse an EAP exchange to create the illusion for the EAP server that the context is different (e.g., wireless LAN access). The work in the area [I-D.arkko-eap-service-identity-auth] and [I-D.mariblanca-aaa-eap-lla] is applicable in this context. The goal is to give both, the EAP peer and the EAP server, enough assurance that the Authenticator (i.e., QoS NSLP in this context) is not lying. It might be worth mentioning that the introduction of COPS in RSVP (see [RFC2749]) and the usage of POLICY_OBJECT [RFC3182] already provided a first attempt in offering a generic three party authorization model. Hence, the problem is not artifical. Unfortunately, the multiple-roundtrip communication and the AAA infrastructure was not fully worked out at that time. The deficiencies in a roaming environment have first been mentioned with [I-D.thomas-nsis-rsvp-analysis]. A more detailed treatment of the security properties are provided with [I-D.ietf-nsis-rsvp-sec-properties]. Tschofenig & Kross Expires January 10, 2005 [Page 13] Internet-Draft Extended QoS NSLP Authorization July 2004 8. References 8.1 Normative References [I-D.ietf-nsis-qos-nslp] Bosch, S., Karagiannis, G. and A. McDonald, "NSLP for Quality-of-Service signaling", draft-ietf-nsis-qos-nslp-03 (work in progress), May 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J. and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. 8.2 Informative References [I-D.alfano-aaa-qosprot] Alfano, F., McCann, P. and H. Tschofenig, "Diameter Quality of Service Application", draft-alfano-aaa-qosprot-00 (work in progress), July 2004, . [I-D.arkko-eap-service-identity-auth] Arkko, J. and P. Eronen, "Authenticated Service Identities for the Extensible Authentication Protocol (EAP)", draft-arkko-eap-service-identity-auth-00 (work in progress), April 2004, . [I-D.arkko-pppext-eap-aka] Arkko, J. and H. Haverinen, "EAP AKA Authentication", draft-arkko-pppext-eap-aka-12 (work in progress), April 2004, . [I-D.ietf-aaa-eap] Eronen, P., Hiller, T. and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", draft-ietf-aaa-eap-08 (work in progress), June 2004, . [I-D.ietf-eap-keying] Aboba, B., "EAP Key Management Framework", Tschofenig & Kross Expires January 10, 2005 [Page 14] Internet-Draft Extended QoS NSLP Authorization July 2004 draft-ietf-eap-keying-01 (work in progress), October 2003, . [I-D.ietf-nsis-nslp-natfw] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "A NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-02 (work in progress), May 2004. [I-D.ietf-nsis-ntlp] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-02 (work in progress), May 2004. [I-D.ietf-nsis-rsvp-sec-properties] Tschofenig, H. and R. Graveman, "RSVP Security Properties", draft-ietf-nsis-rsvp-sec-properties-04 (work in progress), February 2004, . [I-D.ietf-pana-pana] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", draft-ietf-pana-pana-04 (work in progress), May 2004, . [I-D.mariblanca-aaa-eap-lla] Mariblanca, D., "EAP lower layer attributes for AAA protocols", draft-mariblanca-aaa-eap-lla-01 (work in progress), June 2004, . [I-D.puthenkulam-eap-binding] Puthenkulam, J., "The Compound Authentication Binding Problem", draft-puthenkulam-eap-binding-04 (work in progress), October 2003, . [I-D.schulzrinne-nsis-ntlp] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for Signaling", draft-schulzrinne-nsis-ntlp-00 (work in progress), June 2003, . [I-D.thomas-nsis-rsvp-analysis] Thomas, M., "Analysis of Mobile IP and RSVP Interactions", draft-thomas-nsis-rsvp-analysis-00 (work in progress), November 2002, Tschofenig & Kross Expires January 10, 2005 [Page 15] Internet-Draft Extended QoS NSLP Authorization July 2004 . [I-D.walker-ieee802-req] Stanley, D., "EAP Method Requirements for Wireless LANs", draft-walker-ieee802-req-01 (work in progress), May 2004, . [RFC2749] Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R. and A. Sastry, "COPS usage for RSVP", RFC 2749, January 2000, . [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S. and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001, . [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002, . [RFC3520] Hamer, L., Gage, B., Kosinski, B. and H. Shieh, "Session Authorization Policy Element", RFC 3520, April 2003. [RFC3521] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session Set-up with Media Authorization", RFC 3521, April 2003. Authors' Addresses Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany EMail: Hannes.Tschofenig@siemens.com Joachim Kross Siemens AG Otto-Hahn-Ring 6 Munich, Bayern 81739 Germany Tschofenig & Kross Expires January 10, 2005 [Page 16] Internet-Draft Extended QoS NSLP Authorization July 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr. 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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig & Kross Expires January 10, 2005 [Page 17]