NSIS Internet Draft H. Tschofenig Siemens H. Schulzrinne Columbia U. R. Hancock A. McDonald Siemens/Roke Manor X. Fu Univ. Goettingen Document: draft-tschofenig-nsis-sid-00.txt Expires: December 2003 June 2003 Security Implications of the Session Identifier Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract As one result of the analysis activities in the NSIS group it was realized that mobility and the ability to change the flow identifier causes problems with existing QoS reservations. To be able to associate a signaling message with existing state an identifier other than the flow identifier had to be used. Such an abstraction is achieved with the session identifier which allows identification of established state independently of the flow characteristics. Tschofenig et al. Expires - December 2003 [Page 1] Security Implications of the Session Identifier June 2003 Although the introduction of a session identifier sounds simple and beneficial, it introduces a problem which is subsequently referred to as the session ownership problem. This document describes the session ownership problem, the implications for an NSIS protocol and summarizes already discussed solutions. Table of Contents 1. Introduction..................................................2 2. Problem Description...........................................3 2.1 Mobility..................................................3 2.2 Local Repair Case.........................................4 3. Solution Discussion...........................................5 3.1 Local solutions...........................................6 3.1.1 Authorization Token...................................6 3.1.2 Context Transfer......................................6 3.1.3 Centralized Entity....................................7 3.2 Global Solutions..........................................7 3.2.1 Purpose Built Key Based Approach......................7 3.2.2 Hash Series Based Approach............................8 3.2.3 Confidentiality protection of session identifier......9 4. Pending Issues...............................................10 5. Summary......................................................10 6. Security Considerations......................................11 7. Open Issues..................................................11 8. References...................................................11 Acknowledgments.................................................12 Author's Addresses..............................................12 1. Introduction As one result of the analysis activities in the NSIS group it was realized that mobility and the ability to change the flow identifier causes problems with existing QoS reservations. To be able to associate a signaling message with existing state an identifier other than the flow identifier had to be used. Such an abstraction is achieved with the session identifier which allows identification of established state independently of the flow characteristics. Although the introduction of a session identifier sounds simple and beneficial, it introduces a problem which is subsequently referred to as the session ownership problem. Although the problem is known for a very long time (discussion took place already at the 53rd IETF and even proposals for solving the problem have been mentioned) the topic still has some grey spots. Tschofenig et al. Expires - December 2003 [Page 2] Security Implications of the Session Identifier June 2003 This document describes the session ownership problem, the implications for an NSIS protocol and summarizes already discussed solutions. 2. Problem Description To allow signaling messages to refer to existing state some sort of identifier is required. In RSVP this identifier is based on the flow identifier. To support mobility and to introduce the ability to change the flow identifier mid-session and mid-path an additional identifier is required. Throughout this text we call this additional identifier the session identifier. Section 4.5.2 of [NSIS-FW] provides a description of the different identifiers used in NSIS. When a NSIS node receives a signaling message then it has to check whether state information already exists, or whether new state has to be established. The session identifier can quickly provide information whether state information is already available. Some of the described problems are less problematic in non-mobile environments since the first NSIS-aware router (for example the edge or access router) can associate authentication state with the session identifier, and hence ownership can be verified. However, if we assume a mobility scenario then the movement of a node makes this verification step much more difficult since each NSIS-aware node along the path could possibly be forced to do this verification. 2.1 Mobility Figure 1 shows an NSIS Initiator which established state information at NSIS nodes along the path as part of the signaling procedure. As a result Access Router 1, Router 3 and Router 4 (and other nodes) store state information including the Session Identifier SID-x. Tschofenig et al. Expires - December 2003 [Page 3] Security Implications of the Session Identifier June 2003 Session ID(SID-x) +--------+ +-----------------+ Router +------------> Session ID(SID-x)| | 4 | +---+----+ +--------+ | Router | +------+ 3 +******* | +---+----+ * | * | Session ID(SID-x) * Session ID(SID-x) +---+----+ +---+----+ | Access | | Access | | Router | | Router | | 1 | | 2 | +---+----+ +---+----+ | * | Session ID(SID-x) * Session ID(SID-x) +----+------+ +----+------+ | NSIS | | Adversary | | Initiator | | | +-----------+ +-----------+ Figure 1: Mobility Scenario The Session Identifier is included in signaling messages as a reference to the established state. If an adversary were able to obtain the Session Identifier for example by eavesdropping signaling messages it would be able to add the same Session Identifier SID-x to a new a signaling message. When the signaling message hits Router3 (as shown in Figure 3) then existing state information can be modified. The adversary can modify or delete the established reservation causing unexpected behavior for the legitimate user. The source of the problem is that Router 3 (cross-over router) is unable to decide whether the new signaling message was initiated from the owner of the session/reservation. In case that this threat is not addressed an adversary can launch denial of service, theft of service, and various other attacks. Note that the same problem might occur at the receiver side. 2.2 Local Repair Case In the above section an end host mobility scenario is described. Tschofenig et al. Expires - December 2003 [Page 4] Security Implications of the Session Identifier June 2003 To make the situation more difficult it must be mentioned that not only the initial signaling message originator is allowed to authorize NSIS specific operations during the lifetime of an established session. As part of the protocol any NSIS aware node along the path (and the path might change over time) could be involved in the signaling message exchange and it might be necessary to provide mobility support or to trigger a local repair procedure. Hence if only the initial signaling message originator is allowed to trigger signaling message exchange some protocol behavior will not be possible. - old path - +--------+ | Router | +....>| 2 +...+ . +--------+ . cross-over . . router +--------+ . . +--------+ | Router +..+ +.....>| Router | ------>| 1 +--+ +----->| 4 +--------> +--------+ | | +--------+ | +--------+ | +---->| Router +---+ | 3 | +--------+ - new path - Figure 2: Route Change Scenario 3. Solution Discussion Some possible means for verification and proofing ownership of a session are given below. These examples should give the reader information about the current state of the discussion. This section is divided into two parts: First, there is a subsection which proposes so-called "local solutions". These solutions are characterized by the location where this verification is done. This region is typically within the same administrative domain where the user is authenticated for the purpose of authorization. Note that an intra-domain handover does not necessarily mean that the cross-over router where the old path hits the new path is also in the same administrative domain. It could be external and therefore these local solutions might not be applicable. So-called "global solutions" work independently of the domain where the end host is currently attached. Tschofenig et al. Expires - December 2003 [Page 5] Security Implications of the Session Identifier June 2003 Note that local does not necessarily only refer to the first administrative domain. If a trust relationship with other domains also exist then verification is possible at other domains as well. 3.1 Local solutions The following solutions have one property in common which allows an entity to verify that a signaling message is actually legitimate to perform the indicated action: At the initial request some state is created which allows subsequent requests to be associated with this state. The created state can either be in the network itself (e.g. at a centralized entity) whereby the centralized entity needs to be queried to perform verification or some information is shipped around but allows local verification. 3.1.1 Authorization Token The authorization token approach requires that an entity in the network produces a token during the initial signaling message exchange. This token is cryptographically protected and must be verifiable by entities in the local domain. The authorization token must be protected to prevent an adversary at the wireless link to intercept the token and to reuse it. The authorization token allows link subsequent actions to an initial authorization (e.g. by including the token into the signaling message after a handover). The end host only forwards the authorization token. Hence the token itself does not provide authentication. This solution is referred as local since the token has to be granted and verified within the same domain (or within domains with a pre- defined trust relationship). A more sophisticated version would use a concept similar to Kerberos tickets whereby the end host actively participates in the protocol by showing the knowledge of the session key. As authorization information the ticket could include the session identifier. 3.1.2 Context Transfer Context Transfer is another approach the network to associate a new signaling message to a previous one. The Context Transfer protocol allows to move state information from one access router to another. The assumption thereby is that if state was create at one particular access router then the forwarded state would also allow the new access router to verify the incoming signaling message. Due to the transitive trust provided by hop-by-hop security protection in Tschofenig et al. Expires - December 2003 [Page 6] Security Implications of the Session Identifier June 2003 intermediate router would trust that the signaling message have been correctly verified and only the authorized entity issued the signaling message. A short discussion of context transfer in relationship with RSVP is provided in Section 1.2.6 of [Tho02]. The same considerations are also applicable to CT for NSIS. 3.1.3 Centralized Entity Using this approach a cross-over router where the new path hits the old path and where authorization is desired information inside the signaling message (e.g. a token which only points to state installed at the centralized entity or user credentials) could be used to perform this verification. For QoS signaling the Policy Decision Point would be a possible centralized entity. Different to authorization token approach the token does not need to be verified at an individual node itself. For the authorization token approach it is necessary to provide the necessary information within the token itself. In case of a central entity only a reference to the stored information needs to be provided. The distinction between the authorization token and this approach is therefore, from an NSIS protocol point of view, marginal. A solution could possible support both mechanisms easily (e.g. [RFC3521] and [RFC3520]). 3.2 Global Solutions 3.2.1 Purpose Built Key Based Approach This approach makes use of a cryptographic session identifier and follows the idea described in [PBK]. The identifier is created as: Session ID = PRF(Public Key) The output of the PRF function needs to be truncated if necessary to fit the length requirements of the Session ID. As a PRF function MD5 or SHA-1 could be used. The signaling initiator would therefore create a public / private key pair before starting NSIS signaling for a specific session. Every time the end host roams from one location to another the following information is added to the NSIS signaling message: - Session ID - Public Key Tschofenig et al. Expires - December 2003 [Page 7] Security Implications of the Session Identifier June 2003 - Digital Signature of some signaling message payloads including a timestamp A receiving entity (e.g. cross-over router) can verify that - the Session ID matches the hash of the public key - the private key, which was used to compute the digital signaling, matches to the public key (by verifying the digital signature) - the authorization indication is fresh (verifying the timestamp) Note that this approach does not require a public key infrastructure. It only makes use of the inability of an adversary to later compute a key pair whereby the hash of public matches the session identifier. Since the session identifier is stored at the individual routers along the path it is not possible adversary to masquerade the owner of the session id. As described above replay protection is provided with the help of timestamps. The disadvantages of this approach are: - Performance for the public key operation - Size of the messages (the public key has to be included in addition to other fields) - Only the creator of the key pair is able to authorize actions (if we ignore delegation approaches). This seems to be very restrictive. [WC02] follows a similar approach by distributing a public key along the path. Whenever an update is required then the message containing the previous session identifier, the new session identifier, the public key and a sequence number. The sequence number field is not only a short random number; instead it is a digital signature computed over the care-of address and the sequence number. A successful verification at the cross-over router stores the new values along the entire path. 3.2.2 Hash Series Based Approach The Hash Series approach provides better performance than the PBK- based approach. To set up the protocol a random T0 number is created and hashed n times as shown below. The length of the hash series is chosen by the creator with the value n: T1=hash(T0) T2=hash(T1) ... Tn=hash(Tn-1) The session identifier is chosen in such a way that it equals Tn. Tschofenig et al. Expires - December 2003 [Page 8] Security Implications of the Session Identifier June 2003 The hash values are then released in the reverse order. Every hash value is used only once and the number of the latest hash value has to be stored. Since the total number of hash values has to be set at protocol startup it is necessary to "change" the hash series after all values are exhausted. Since the hash series is associated to the session identifier it is also necessary to change the session identifier or to restart the protocol with a new session identifier. A signaling message would therefore include: - Session ID (=Tn) - Total number of hash values (n) - Current hash value (Ti) - Index of current hash value (i) A verifying entity would therefore recompute the hash chain to verify that the session id is valid. Furthermore it is necessary to compare the received hash value with the lasted one received (if no hash value got lost) Tx+1 would have to equal hash(Tx). To prevent reuse of a hash value by an adversary it is necessary that all nodes along the path store the latest valid value. 3.2.3 Confidentiality protection of session identifier This approach is very simple and follows the following arguments: - An adversary can only mount an attack if it knows the Session ID - The end host has to trust the intermediate nodes and networks to perform according to the expected behavior. Due to the flexible protocol operation it is necessary for intermediate nodes to act on behalf of the end host. Providing confidentiality protection to protect the Session ID makes it more very difficult for an adversary to eavesdrop the session identifier and to reuse it for a subsequent attack. Confidentiality protection of the session identifier therefore addresses attacks from outsiders (entities which do not actively participate in the NSIS signaling protocol). Hence it must be assured that the session identifier is never transmitted in clear between two signaling entities (e.g. in clear over the wireless link). Adversaries along the path (i.e. an NSIS node which was intercepted by an adversary) are not addressed by this approach. It is obvious that the session identifier must be chosen in a way which does not allow an adversary to guess it. One possibility is to choose the value for the Session Identifier randomly with each session. It must be ensured that the identifier is sufficient large (e.g. 128 bits). Tschofenig et al. Expires - December 2003 [Page 9] Security Implications of the Session Identifier June 2003 This approach was selected for CASP [CASP]. 4. Pending Issues - Replay protection Replay protection for the solutions described in Section 3 is hard. Assuming globally synchronized clocks for timestamp-based replay protection is possibly hard to justify. - Authorizing entity To keep the NSIS protocol flexible it seems that it is undesirable to restrict certain actions only to a single entity (e.g. to the signaling initiator). Some solutions discussed in Section 3 tend to force such an approach. The question therefore is: "Which entity is allowed to authorize which actions?" - Certain solutions discussed in Section 3 require the distribution (and storage) of information along the path. - Signaling message behavior NSIS signaling messages do not always travel end-to-end. Instead, in mobility scenarios it is sometimes desirable to start or to terminate the signaling message exchange somewhere along the path. Is this still valid or do all message have to travel end-to-end? - Local or global solution It is obviously much simpler to provide a solution which works locally. Since the ownership problem could possibly require verification at any node along the path it seems to be that a global solution should be targeted. 5. Summary To provide proper security for the session ownership problem a solution has to face many challenges including performance, state maintenance, replay protection and most important - the flexibility of the NSIS protocol itself. The above-described problem of authorization is not restricted to communication at the edge as described above. The problem basically occurs anywhere in the network whenever an old path becomes invalid and a reservation along a new path has to be established. The merge point (or cross-over router from the above mobility scenario) has to make sure that only the legitimate owner of the reservation issued this request. Tschofenig et al. Expires - December 2003 [Page 10] Security Implications of the Session Identifier June 2003 Introducing a session identifier for the purpose of more efficient mobility handling needs to be carefully compared to the additionally introduced complexity (for example by the corresponding security mechanism). The benefits gained by this new concept can easily be destroyed by heavy-weight security mechanisms or by introducing new security vulnerabilities. 6. Security Considerations This document addresses security issues of the Session ID. To provide a more detailed threat analysis it is necessary to resolve the pending issues listed in Section 4. This threat is also briefly described in [THREATS]. The solutions described in this document to not aim to provide protection for signaling messages itself. 7. Open Issues Adding multicast handling to an NSIS adds a number of further open issues. In case of multicast it is possible that nodes join and leave the multicast group. If sensitive information is transmitted to the active signaling entities then a previously joined node can later perform some actions even after leaving the multicast group. Sooner or later it is necessary to come up with a definition of the problem we are aiming to solve. Such a definition might look like: "An NSIS message is authentic if it originates from the initiator for a session, or from an NSIS node that has been authorized to act on behalf of the initiator by virtue of taking part in the NSIS signaling session." 8. References [THREATS] H. Tschofenig and D. Kroeselberg: "Security Threats for NSIS", Internet Draft, Internet Engineering Task Force, March 2003. Work in progress. [NSIS-FW] R. Hancock, I. Freytsis, G. Karagiannis, J. Loughney and S. Van den Bosch: "Next Steps in Signaling: Framework", Internet Draft, Internet Engineering Task Force, March 2003. Work in progress. [PBK] S. Bradner, A. Mankin, and J. Schiller, "A framework for purpose built keys (PBK)", Internet Draft, Internet Engineering Task Force, November 2002. Work in progress. Tschofenig et al. Expires - December 2003 [Page 11] Security Implications of the Session Identifier June 2003 [WC02] C. Westphal and H. Chaskar: "QoS Signaling Framework for Mobile IP", Internet Draft, Internet Engineering Task Force, June 2002. Expired. [CASP] H. Schulzrinne, H. Tschofenig, X. Fu, and A. McDonald, "CASP - Cross-Application Signaling Protocol", Internet Draft, Internet Engineering Task Force, 2003. Work in progress. [RFC3521] L. Hamer, B. Gage, and H. Shieh, "Framework for session set-up with media authorization," RFC 3521, Internet Engineering Task Force, April 2003. [RFC3520] L. Hamer, B. Gage, B. Kosinski, and H. Shieh, "Session Authorization Policy Element", RFC 3520, Internet Engineering Task Force, April 2003. [Tho02] M. Thomas: "Analysis of Mobile IP and RSVP Interactions", Internet Draft Internet Engineering Task Force, (work in progress), October 2002. Acknowledgments We would like to thank Rainer Falk for his comments to this draft. Author's Addresses Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Hannes.Tschofenig@siemens.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Robert Hancock Roke Manor Research Old Salisbury Lane Romsey Hampshire SO51 0ZN United Kingdom Email: robert.hancock@roke.co.uk Tschofenig et al. Expires - December 2003 [Page 12] Security Implications of the Session Identifier June 2003 Andrew McDonald Roke Manor Research Old Salisbury Lane Romsey, Hampshire UK EMail: andrew.mcdonald@roke.co.uk Xiaoming Fu Institute for Informatics University of Goettingen Lotzestrasse 16-18 37083 Goettinge Germany EMail: fu@cs.uni-goettingen.de Intellectual Property Statement 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which 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 (2001). 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 Tschofenig et al. Expires - December 2003 [Page 13] Security Implications of the Session Identifier June 2003 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. Tschofenig et al. Expires - December 2003 [Page 14]