Internet Draft J. Vollbrecht Document: Interlink Networks,Inc. Category: Informational G. Carle S. Zander T. Zseby GMD FOKUS February 2001 Session ID Status of this Memo This document is an Internet-Draft and is in full conformance with 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. The authors would like to note that although this draft is in a very early stage of development it has been submitted to motivate discussion about the topic. Abstract This draft describes bindings that are needed for auditing and accounting in an interdomain generic AAA environment. It introduces the concept of a session ID that is used to bind together a set of related activities. These activities can be single messages, transactions or sessions. For accounting different accounting records must be tied together and linked to a user ID in order to produce a bill. Auditing requires a binding of authentication, authorization and accounting and the actual service delivered in order to trace back all occurred actions. For both there must be a link between the different sub-sessions a service is composed of. This draft presents different approaches on how this binding can be achieved. Furthermore requirements for the session ID which is used for the binding are given and it is shown how the session ID can be created with regard to the generic AAA architecture [1]. Finally some examples are given. Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 1] Internet Draft Session ID February 2001 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Binding Objectives............................................5 4. Binding Concepts..............................................6 5. Related Work..................................................6 5.1 RADIUS......................................................7 5.2 DIAMETER....................................................7 5.3 WWW based services..........................................8 6. Session ID Requirements.......................................9 7. Generation of Session IDs....................................10 8. Auditing.....................................................10 9. Accounting...................................................11 10. Anonymous Service Usage......................................11 11. Examples.....................................................11 12. Security Considerations......................................11 13. References...................................................12 14. Acknowledgments..............................................12 15. Author's Addresses...........................................12 16. Full Copyright Statement.....................................13 1. Introduction The Generic AAA Architecture described in [1] is an infrastructure that supports authentication, authorization and accounting for generic services. A session is linked to one or more "users" which might be an individual, a hardware device or a piece of software. A "user" may act as a "customer" or with the permission of the customer. The user might be identified with a public key, a user-ID, an IP address, a phone number etc. A session also relates to one or more service "providers" which support the session with resources of some sort. Furthermore a session may incorporate one or more "broker" which supports information on existing providers. This draft describes the concept of a session ID which is needed in [1] for the binding of: - Authentication, Authorization and Accounting with the Service provisioning process (Service Session) - Accounting records (maybe generated by different hosts) which provide the accounting data for the services a user has used - Different service sessions that logically belong together Authentication, authorization and service usage needs to be linked to make a later auditing and accounting possible. This is even more important if these functions are performed by different entities (in different domains). In the case of fraud it must be checked whether the authentication authenticated a wrong person or the rights granted by the authorization process were wrong. The service usage must be linked to authentication and authorization to associate the Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 2] Internet Draft Session ID February 2001 accounted data in the service session to the person which requested the service and has been identified during the authentication. Furthermore in the case of misuse it must be possible to backtrack the malicious service user which hopefully could be done having a link to the authentication and authorization. A session should have a session ID which allows each provider and user in the session to audit session activity and compare it with what other providers and users believe happened in the session. The session ID should allow a provider to merge accounting data for the different activities and generate a bill. Each user and provider may have a different view on the overall session. In particular a user or provider may only know a part of the session that took place. In case we have more than one accounting record generated per session (service) the session ID is used to link the different records together. In [3] it is shown that even in the simple dialup service we haven at least two accounting records (start and stop) which must be tied together to provide useful information for later billing. Other services may well produce more than two records for example if interim reports are used or we have different service equipment involved (e.g. print service). A service which is provided with the architecture described in [1] may be composed of different services from different providers. For the user this may still look like a single service. To correlate accounting and auditing information the different sessions which are part of a service need to be linked together. This can be achieved via session IDs. Several alternatives for linking are possible. One alternative would be the use of a common session ID. Another alternative would be to use individual session IDs for each subsession, in combination with a binding function (or a binding service) that would allow to obtain information about the related services. In the accounting case it might not be necessary to link to the session ID if there is a separate billing for each accounted process. A session ID must be unique for each provider-user combination. This means that each provider and user may have to create a piece of the session ID to guarantee that it is unique to it. It is also possible that the provider creates the whole session ID by using user and provider information. 2. Terminology Service: A service is a performance offered by a provider. In contrast to goods, services are usually intangible and production and consuming happens simultaneously. Services can be very different. A service can be for instance a 2 hour videoconference including audio, video and whiteboard, the guaranteed transmission of 100000 packets with a high priority, the provisioning of accounting records, etc. Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 3] Internet Draft Session ID February 2001 Session: A session is a service provisioning over time. Start and stop of the session is determined by the service definition. Examples for sessions are audio/video flows, downloading data, collecting continuous (interim) accounting data, etc. Also the concatenation of transactions can be called a session. A session may have subsessions and transactions. A session has three different phases: session establishment, service session, session teardown. Super- and Subsession: A session can be a super- or subsession. A session is called a supersession if it has one or more subsessions which are a part of the supersession. A subsession is a session which is part of a supersession. All sessions together form the session graph. In case of a hierarchical relationship we have a session tree with a root session which is the supersession for all other sessions. Whether a particular session is a super- or subsession depends on the viewpoint (e.g. a supersession of a subsession can be a subsession of another supersession). The supersession should have knowledge of all subsessions. In certain cases it also might be desirable to be able to determine the supersession ID from the subsession ID. Nevertheless, for privacy reasons knowledge about the subsession should not automatically imply knowledge about the supersession. Privacy may be compromised if the ID of the supersession contains some cleartext information which might for instance reveal participants. Even if the supersession encrypts these information the knowledge that there exists a supersession may be problematic. Even if the communication between two parties is encrypted the fact that someone knows that there is a communication between them might be already compromising. Peer Session: A peer-session is a session which is on the same level with another session (this means it is neither a super- nor a sub-session). Peer- sessions may interact which each other. Transaction: A transaction consists of request and response messages that are exchanged. Transactions differ from sessions because they do not require a "continuous" flow of data. Examples for transactions are the authorization of a service, buying a book, etc. Transactions can be part of a session. Simple transactions consist of a single request-response message pair. An authentication and/or authorization transaction is often used to determine if a session is allowed prior to actual session establishment. Authentication Transaction: An authentication transaction is the exchange of request/response messages to perform authentication. Authorization Transaction: Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 4] Internet Draft Session ID February 2001 An authorization transaction is the exchange of request/response messages to perform authorization. During a session reauthorization transactions might be necessary. Accounting Transaction: An accounting transaction is the exchange of request/response messages to perform accounting. Accounting can be performed in the form of accounting transactions that report on resource usage by a session. Accounting transaction can occur during a session if accounting or charging indications are needed [pol based acct] or only at the start and the end of the session. Accounting Session: An accounting session consists of subsequent accounting records. It can be seen as the concatenation of single messages or as concatenation of multiple accounting transactions. Auditing: Auditing is the process of examining information on a provided services to check whether the service has been provided correctly and the contractual negotiated parameters have been met. // Auditing should be performed by an independent third party in order to prevent fraud. Auditing Transactions: Auditing transactions are message exchanges used in the process of auditing a session. This could be requests to store or to query auditing information. AAA Transactions: AAA messages and transactions may be considered a form of signaling used to control a session. AAA transactions should have unique transaction IDs, different from the session ID, which can be used to associate the transactions with the session. Binding: Binding is the process of building associations between different messages, transactions and sessions which logically belong together for accounting and auditing purposes. 3. Binding Objectives There are different objectives to bind messages, sessions and transactions together. A) Binding authentication, authorization transactions to the main service session and accounting: This is required in order to concatenate information about the user (user ID) to the session and the involved transactions. For accounting it is important to map the user ID to the corresponding accounting records. For auditing it is also of interest how the user has been authenticated (e.g. strong or weak mechanism) and authorized. Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 5] Internet Draft Session ID February 2001 B) Binding together accounting records for one service session: This is needed to recognize which accounting records belong to the same service session. The bound accounting records form the accounting session. C) Binding together sub-sessions which belong to a service-package or super-session: This would be for example the binding of audio- and video session for a videoconference (super-session). Binding of sub-sessions to a super-session is useful to concatenate the services used by one user simultaneously and the accounting data for this session. A) and B) would be the "traditional" (see section 5) session ID. The purpose of A) is auditing and to also link user authorization to accounting while B) is needed for accounting and auditing. C) would link different services (even from different domains) together. The IDs could be named differently according to the bindings they provide. 4. Binding Concepts In the following we first describe two different concepts for binding messages, sessions and transactions together: - Hierarchical binding: With an hierarchical binding sub-session ID are derived from the super-session (or parent-session) ID. Here we have to distinguish whether one should be able to determine the supersession ID from subsession IDs. For instance whether the ID of a videoconference session could be derived from the audio- session ID. This might violate privacy requirements. - Peer-to-peer binding: With a peer-to-peer binding two sessions at an equal level are concatenated (e.g. an audio-session that consists of two audio-sessions in different provider networks). Information on the binding between two sessions can be stored at the concatenation points where both sessions are known (e.g. AAA server or the border routers between two providers). Second the binding could also distinguished according to the following: - Implicit (late) binding: No explicit binding is created during session lifetime. Binding is created if needed (e.g. for auditing) based on service relevant information like user name, IP address, etc. - Explicit binding: The binding is created during the session lifetime and/or shortly after. 5. Related Work Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 6] Internet Draft Session ID February 2001 This chapter gives an overview of existing services which already use the concept of a session ID. 5.1 RADIUS [2] defines the RADIUS protocol which is used for authorization and accounting a dial-in service. A RADIUS session is defined as follows: Each service provided by the NAS to a dial-in user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that. For accounting purposes a session ID is generated [3]. RADIUS generates on accounting records at the start and the stop of a session. The RADIUS Acct-Session-ID attribute is used to match the two reports of a session and is defined as follows: This attribute is a unique Accounting ID to make it easy to match start and stop records in a log file. The start and stop records for a given session MUST have the same Acct-Session-ID. It is strongly recommended that the Acct-Session-ID be a printable ASCII string. For example, one implementation uses a string with an 8-digit upper case hexadecimal number, the first two digits increment on each reboot (wrapping every 256 reboots) and the next 6 digits counting from 0 for the first person logging in after a reboot up to 2^24-1, about 16 million. Other encodings are possible. Another attribute which is defined in [3] is the Acct-Multi-Session-ID. This attribute links together multiple related sessions and thus can be seen as kind of supersession ID with regard to the session ID of one session. The attribute is defined as follows: This attribute is a unique Accounting ID to make it easy to link together multiple related sessions in a log file. Each session linked together would have a unique Acct-Session-ID but the same Acct-Multi-Session-ID. It is strongly recommended that the Acct-Multi-Session-ID be a printable ASCII string. 5.2 DIAMETER The successor of RADIUS is the basis for the forthcoming AAA protocol DIAMETER [4]. DIAMETER has a session ID for binding the different AAA transaction together. Therefore a Session-ID AVP has been defined. The initial request for authentication and/or authorization of a user would include the Session-ID. The Session-ID is then used in all subsequent messages to identify the user's session. The session state (associated with a Session-ID) is freed upon receipt of the Session-Termination-Request, Session- Termination-Answer and according to rules established in a particular extension/application of DIAMETER. The Session-ID AVP is defined as follows: The Session-ID AVP (AVP Code 263) is of type Data and is used to identify a specific session (see section 3.0). All messages pertaining to a specific session MUST include only one Session-ID AVP and the same value MUST be used Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 7] Internet Draft Session ID February 2001 throughout the life of a session. When present, the Session-ID SHOULD appear immediately following the DIAMETER Header. For messages that do not pertain to a specific session, multiple Session-ID AVPs MAY be present as long as they are encapsulated within different Grouped-AVP AVPs [messages which do not belong to any session!]. The Session-ID MUST be globally unique at any given time since it is used by the server to identify the session (or flow). The format of the session identifier SHOULD be as follows: The monotonically increasing 32 bit value SHOULD NOT start at zero upon reboot, but rather start at a random value. This will minimize the possibility of overlapping Session-IDs after a reboot. Alternatively, an implementation MAY keep track of the increasing value in non-volatile memory. The optional value is implementation specific but may include a modem's device ID, a layer 2 address, timestamp, etc. The session ID is created by the DIAMETER device initiating the session, which in most cases is done by the client. Note that a Session-ID MAY be used by more than one extension (e.g. authentication for a specific service and accounting, both of which have separate extensions). The Session-Timeout AVP can be used by a server to tell the client the maximum session duration. The client may use this attribute to indicate the maximum length that it is willing to accept. 5.3 WWW based services WWW based services are content services, electronic shops and web based messaging services etc. Since HTTP is a stateless protocol for the provision of certain services there is need to keep state over a number of different HTTP requests. A session ID is used in web based services to allow the following: tracking of user, keep state for a user over different pages/http requests, limited form of authentication (prevent replay attacks). There are two traditional methods of propagating a session ID which have been used before HTTP state management was invented [6]: URL parameter or cookies. Cookies are optimal but not reliable since the client can disable the use of them. A session ID used for authentication is normally a short-lived cookie which is only kept in browser memory and is not written to disk. However if used for keeping state the session ID may be stored on disk, so that the state can be resumed even after shutoff and restart of the computer. [6] describes a way to create stateful sessions with HTTP requests and responses. The state management mechanism allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which is called a "session". This context might be used to create, for example, a "shopping cart", in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user's previous Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 8] Internet Draft Session ID February 2001 reading affects which offerings are presented. Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends. In [5] it is shown that the HTTP State Management mechanism is both useful and controversial compared to the traditional methods. It is useful because numerous applications of HTTP benefit from the ability to save state between HTTP transactions, without encoding such state in URLs. It is controversial because the mechanism has been used to accomplish things for which it was not designed and is not well-suited. Some of these uses have attracted a great deal of public criticism because they threaten to violate the privacy of web users, specifically by leaking potentially sensitive information to third parties such as the Web sites a user has visited. There are also other uses of HTTP State Management which are inappropriate even though they do not threaten user privacy. [other protocols to look at: SIP, SDP, RTSP] 6. Session ID Requirements Global uniqueness: To uniquely identify a session a session ID must be globally unique which means unique in time and location. The might be relaxed to unique within a given time period or within a certain spatial scope. For instance if we have to audit session data for 10 years the session ID must be unique within this period. If it is assured that a session does not cross certain boundaries the uniqueness requirement may be relaxed to "unique within this boundaries". Privacy: A session ID must not enable a third party to be able to derive the "real" ID of the user from the session ID. The session ID should only be resolvable to the entity which generated it. For the provisioning of anonymous services it might be required that the session ID is nor resolvable at all. In case of a fully anonymous session the session ID has to be build without even knowing user specific parameter. Therefore no relation to the user is given. Furthermore no information should be logged which would give a hint on the real ID. Efficiency: The generation and linkage of session IDs must be sufficiently fast compared to the overall process of service authentication and authorization to avoid unnecessary latency. Especially it must be avoided to increase latency in service provision due to the transport of session IDs between providers. Security: A session ID must be non predictable. Otherwise it may be possible to take over another persons session. It must not be possible to derive user data from the session ID. This can be avoided by using a Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 9] Internet Draft Session ID February 2001 one way hash over the data (e.g. [8]). There may be situations where it is allowed to directly use user data in the session ID. For security reasons session IDs could be transmitted via encrypted channels (e.g. IPSEC). Flexibility: There may be different solutions of generating/assigning session ID and binding session IDs together which can be used in different situations. One method can be tailored to a specific service (usage). However all methods must be compatible in a way such that accounting and auditing is not limited to an unacceptable degree. Granularity: The solution must allow for the finest grained auditing possible of a provided service. However cases in which there is only lax auditing required should also be supported efficiently. 7. Generation of Session IDs When and where should the session ID be generated? To tie the three As together the session ID must be generated as part of the authentication process. The session ID may be build using parameter from the authentication request as well as IP address or DNS name of the requester. The authentication may be performed by the service equipment (e.g. dialup the NAS) or by another entity. In case of a free service there may be no authentication and authorization. In this case the session ID is generated by the service equipment at the start of the service usage. How is the Session ID generated? A global unique session ID can created in the generic AAA architecture as follows. The ID is composed of three different parts: ID = user_ID + service_ID + AAA_ID The user_ID is an ID which is created by the service. This ID may be based on user specific information. The ID may contain user specific information in cleartext or it may be a cryptographic hash over some user information. The service_ID is the ID which is used to identify the service at the AAA server. The AAA server needs some kind of ID to map a certain request to a certain service i.e. pass the request to the ASM. The AAA_ID is a global unique ID of the AAA server providing the requested service. The ID of the AAA needs to be globally unique anyway. 8. Auditing Auditing is used to examine the correct provisioning of the service. The auditing process should be defined in a way that it is accepted by both sides (provider and user) as a valid process to proof that the provider has fulfilled the provisioning task correctly even in a legal action. Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 10] Internet Draft Session ID February 2001 A session ID is required here to map all actions, messages, transactions and sub-sessions to the specific user. Since Auditing requires traceability of all performed actions, the auditability of a service is usually in direct contrast to anonymity. For privacy reasons it is possible to restrict access to the data used for auditing to a few trusted instances and/or to distribute the knowledge of the concatenated actions in a way that only the concatenation of information from different instances gives a the whole view. A session ID is always needed except we provide no auditing function at all. This may be the case for a cheap service. Auditing capability may be an added value for the customer. On the other hand the government may force providers to audit specific activities and/or data. 9. Accounting The binding of accounting records to a specific user is required to generate a bill. Furthermore a session ID is used to tie together accounting messages and transactions. This can be subsequent records for one session, records form different sources or providers. 10. Anonymous Service Usage The ability to provide an anonymous services is very important. The anonymity of the service user can prevent proper auditing and therefore is in direct contrast to the requirement for auditability of the service. We distinguish between a full anonymous services where it is not possible at all to obtain the user-session mapping and a partial anonymous services where certain instances are able to resolve the user-session mapping. 11. Examples In this section there should be several examples on how the session ID could be used for accounting and auditing with the generic AAA architecture [1]. The same examples as in [7] could be used. Video on Demand (with QoS) VPN (with QoS) Content service (with QoS) Dialup (with Mobility/Roaming) Bandwidth request Network printing E-commerce Anonymous service 12. Security Considerations Privacy Forging/Spoofing Session IDs Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 11] Internet Draft Session ID February 2001 Encryption 13. References [1] C. de Laat, G. Gross, L. Gommans, J. Vollbrecht, D. Spence, "Generic AAA Architecture", IETF RFC2903, August 2000 [2] Rigney C., Rubens A., Simpson W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. [3] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. [4] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman. "DIAMETER Base Protocol", draft-calhoun-diameter-17.txt, IETF work in Progress, September 2000. [5] K. Moore, N. Freed: " Use of HTTP State Management", IETF RFC2964, October 2000 [6] D. Kristol, L. Montulli: "HTTP State Management Mechanism", IETF RFC2965, October 2000 [7] J. Vollbrecht, P. Calhoun, S. Farrell, L. Gommans, G. Gross, B. de Bruijn, C. de Laat, M. Holdrege, D. Spence, et al, "AAA Authorization Application Examples", Informational RFC 2905, August 2000. [8] R. Rivest: "The MD5 Message-Digest Algorithm" IETF RFC1321, April 1992 14. Acknowledgments 15. Author's Addresses John R. Vollbrecht Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA Phone: +1 734 821 1205 Fax: +1 734 821 1235 EMail: jrv@interlinknetworks.com Georg Carle GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7149 Email: carle@fokus.gmd.de Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 12] Internet Draft Session ID February 2001 Sebastian Zander GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7287 Email: zander@fokus.gmd.de Tanja Zseby GMD FOKUS Kaiserin-Augusta-Allee 31 10589 Berlin Germany Phone: +49-30-34 63 7153 Email: zseby@fokus.gmd.de 16. Full Copyright Statement Copyright (C) The Internet Society (2000). 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. Vollbrecht, Carle, Zander, Zseby Expires August 2001 [Page 13] -- _________________________________________________________________________ dr.ir. C.Th.A.M. de Laat, Faculty of Physics and Astronomy, Utrecht University, Princetonplein 5, NL-3584CC Utrecht, The Netherlands. Tel: (31)30-2534585 , mobile: 06-51566438 , Fax:(31)30-2537555 web: http://www.phys.uu.nl/~delaat , mail: c.t.a.m.delaat@phys.uu.nl