Kerberos Working Group H. Moustafa Internet-Draft France Telecom - Orange Intended status: Informational G. Bourdon Expires: April 19, 2012 France Telecom - Orange France T. Yu MIT Kerberos Consortium October 17, 2011 Distributed Authentication in Wireless Mesh Networks Through Kerberos Tickets draft-moustafa-krb-wg-mesh-nw-02.txt Abstract This document presents the problem of authentication and authorization in wireless mesh networks constituted by several users communicating with application servers and communicating with each other in a single or multi-hop fashion. Each user in this environment can also play the role of an application provider. Imagine a large music event where the provided network infrastructure is enhanced with network storage equipment to allow visitors to access content relating to the bands playing at the events, such as recorded video of previous performances, supplementary audio and video material relevant to the bands playing, etc. Certain content is, however, not necessarily available to everyone under the same conditions. Instead access control is applied before the full range of audio, and video material can be accessed. Other content, such as previews, might be offered for free. How can such authentication, and authorization infrastructure be made available with minimal configuration complexity for a temporary event like a music festival? This document lists the requirements for a potentially needed Kerberos extension and presents a solution proposal based on the attempt to use a Kerberos extension for mutual authentication in wireless mesh networks. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Moustafa, et al. Expires April 19, 2012 [Page 1] Internet-Draft Distributed Authentication October 2011 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." This Internet-Draft will expire on April 19, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Specification Requirements 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]. 2. Introduction and Problem Statement Authentication and authorization to services access is still an open problem in wireless mesh network distributed environments in which several users would need to communicate to several application servers and with each other in a single or multi-hop fashion, and each user could play the role of an application provider. The Kerberos authentication model [RFC4120] uses a symmetric cryptography approach, offering a high security level and allowing mutual authentication. The principle of using service tickets in Kerberos allows for credentials distribution which is suitable for wireless mesh networks distributed environments. However, the centralized approach in Kerberos (where each user should communicate with the authentication server each time he needs services credentials) restricts its usage for authentication in such distributed environments. Furthermore, Kerberos rather authenticates each node with respect to the authentication server and to the Moustafa, et al. Expires April 19, 2012 [Page 2] Internet-Draft Distributed Authentication October 2011 application server. The distributed credentials principle in Kerberos (through Service tickets) is promising for allowing authentication between each user and the application. However, the authentication between each two users who communicate with each other is still not covered by Service tickets, especially with the dynamic nature of distributed environments in which users connectivity (that could be single or multi-hop) change frequently with time. Although the multi-hop communication is transparent to the application, there is a need to handle the authentication and access control among the different multi-hop communicating nodes to prevent against malicious actions taken by the human users themselves. Based on this fact, this draft proposes to use a common key obtained by Kerberos for authentication among each two nodes who communicate together in a multi-hop fashion. This common key is dynamic (renewable with time) for security reasons in such dynamic and distributed wireless environment that is less secure. 3. Requirements This section presents a number of requirements motivated by the problem defined in the previous section. These requirements are as follows: o Distributed environment consisting of fixed and mobile nodes. o Dynamic neighbors and dynamic application providers (any node could be an application provider at any time providing applications to other nodes in the network, e.g. file sharing, sending special announcement concerning the surrounding environments, and sending alarms in case of problems). o User Generated Content (UGC) application, in which each node could be a source of content (mainly multimedia contents) for other nodes in the network, e.g. transmitting video snapshots during festival events. o Hundreds of nodes (indoor or outdoor environment). o Personal devices (of low power) individually used by users. o Multihop communication. o Authentication and access control of each user node by a trusted third party. o Access control of each user by a trusted third party in a way that corresponds to the user subscription type and profile. o Mutual authentication between each pair of communicating users. o Limited bandwidth: need for minimizing traffic (minimizing the communication with the KDC). o Dynamic credentials (attributing dynamic credentials to be distributed to each user). Moustafa, et al. Expires April 19, 2012 [Page 3] Internet-Draft Distributed Authentication October 2011 4. Kerberos Extension Solution Proposal This section presents a solution proposal extending the Kerberos authentication model for authenticating each user node in wireless mesh networks with respect to the network operator and with respect to other users nodes participating in the network. The Kerberos server resides in the local mesh network or in an external network and each user node needs to communicate firstly with this server in order to authenticate with respect to the operator and to obtain the necessary credentials (Kerberos tickets) for authentication with other users nodes and for accessing the offered services in the mesh network. The communication can take place in a single hop or through multi-hops (passing by intermediate users nodes) according to the proximity of each user node from the application providers nodes. To prevent unreliable communication from taking place (intermediate nodes could do DoS, messages truncating,...), this solution proposal extends the classical Kerberos authentication model to adapt to the multi-hop communication through introducing a new shared secret for authentication and access control between intermediate nodes along the multi-hop communication. But, if this secret is the same for all the time, it could be compromised and the entire network would be compromised. It is then proposed in this draft to obtain several shared secrets during the service ticket request for the service for which the multihop communication is needed. The solution proposal takes the following sequence: o Each user node wishing to access the services offered by the mesh network starts by sending a first request to the KDC (TGT part) in order to authenticate with respect to the operator and to obtain the TGT ticket. The process is similar to the classical Kerberos authentication approach, and the user, if legitimate, obtains the corresponding TGT ticket. o After obtaining the TGT, the user node re-contacts the KDC (TGS part), through sending a TGS request, in order to obtain the necessary credentials (including the service ticket for the service for which multihop communication will be employed in addition to the shared secrets for authentication during the multihop communication) while presenting the obtained TGT ticket as a proof of authenticity. The classical Kerberos TGS request should be extended to illustrate the need of extra credentials for authentication with intermediate nodes along the multi-hop communication. The following figure illustrates this extension, where a new flag is defined in the flags field in the reserved bits between bits 12 and 25 taking the value 1 to indicate the case of Kerberos in the multi-hop mode. Moustafa, et al. Expires April 19, 2012 [Page 4] Internet-Draft Distributed Authentication October 2011 o _ _ _ _ _ _ _ _ _ __ _ _ _ __ _ _ _ |pvno| msg-type | padata | req-body | |_ _ |_ __ _ _ _|_ _ _ __|_ _ _ _ _ | | | | V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |flags|cna-|realm|sna-|fr|ti|rtime|nonce|etype|addr|enc |addit. | |_ _ _|_me |_ _ _|_me |om|ll|_ _ _|_ _ _|_ _ _|_ _ |authdata|tickets| | | | V 0_ _ _ _ _ _ 12_ _ _ _ _ _ _ _ _ _ 25_ _ _ _ _ _ _ _ _ _ _ _ _31 |_|_ ___ _ _| _| _ _ _ _ _|X |__ _ _ |_|_ _ _ _ _ _ _ _ _ _ _ |_| Figure 1: Extended TGS-REQ o Once the KDC (TGS part), receiving the TGS request from the user, verifies the TGT ticket and the user authenticity, it sends to the user the Kerberos TGS reply message extended to contain the necessary credentials according to the user profile and according to the required service. o The extended Kerberos TGS reply message includes the service ticket for the service for which the multihop wommunication will be employed as well as the shared secrets. o To avoid the shared secret compromise, several shared secrets are obtained, where each shared secret is valid for a given time interval. However, the shared secret distributions should be done in a mean that would not compromise the security of the whole network: * If the shared secrets are required by each mesh node at each time interval, this would generate lot of traffic during the communication with the KDC. * If the shared secrets for future time intervals are pre- generated by the KDC and given in batch to each user, this would optimize traffic, but if a node is compromised at an Moustafa, et al. Expires April 19, 2012 [Page 5] Internet-Draft Distributed Authentication October 2011 interval of time, all the shared secrets would be known and the network would be compromised. o Then, the KDC sends to each mesh node in the extended TGS reply message the current interval shared secret and the pre-generated ones for the future, while each pre-generated shared secret is encrypted with a key corresponding to the its related time interval. This encryption key should be sent to each mesh node in the corresponding time interval either through Kerberos protocol or through a multicast routing protocol. The following figure illustrates the extended TGS reply message. In this extended message: i) a new flag is defined in the flags field in the reserved bits between bits 14 and 31 taking the value 1 to indicate the case of Kerberos in the multi-hop mode. ii) a new field authorized-data is added which is identical to the authorization data field existing in the service ticket and containing elements, where the first element contains the current time interval in its (type) part and the corresponding shared key to this interval in its (data part). The other elements contains the upcoming time intervals and the corresponding shared keys in an encrypted form as explained above. o _ _ _ __ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |pvno| msg-type| padata | crealm|cname | ticket| enc-part | |_ _ |_ _ _ _ _|_ _ _ _ |_ _ _ _| _ _ |_ _ _ _|_ _ _ _ _ | | | | V _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |key|last|non|key|flags|auth|start|end |renew|srea|sna|cad-|authorized| |_ _|req_|_ce|exp|_ _ _|time|time |time|till_|_lm_|_me|_dr_|_ data_ _ | | | | | V | 0_ _ _ _ _ _ _ _ _ _ _14_ _ _ _ _ _ _ _ _ _ _ _ 31 | |_|_ ___ _ _ _ _ _ _ _|_|__ _ _ |X| _ _ _ _ _ _ |_| | | V _ _ _ __ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ | _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ | ||ad-type | ad-data| . . . . . |ad-type|ad-data|| ||_ _ _ _ |_ _ _ _| |__ _ _ |_ _ _ _|| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| Elements Moustafa, et al. Expires April 19, 2012 [Page 6] Internet-Draft Distributed Authentication October 2011 Figure 2: Extended TGS-REP o Group keys can be also considered allowing to have a shared secret for each group of mesh nodes and allowing each mesh node to participate to more than one group and hence to have several group keys. If one group key is compromised it could be deleted by the KDC. Mesh nodes sharing the same group key are mesh nodes sharing some common characteristics (making a cluster, hierarchal group keys for example, ...). 5. Potential Use-cases This section presents the potential use-cases for distributed environments of wireless mesh networks having multi-hop communication and requiring distributed authentication authorization. o Temporary network infrastructure deployment for special events (sport events, music festivals, ..). Network operators deploy temporary low-cost infrastructure for temporary events and hence counts on the communication of users with application servers that are locally deployed. Also the users themselves can play the role of application providers contributing to the diffusion of multimedia services (video snapshots on the event,video streams with inserted comments, video streaming for what was missed in the event, downloading an interactive audio-visual program for the event,. ..). In such use-case, there is a need for dynamic credentials distribution on the different participating nodes and there is also a need of controlling the access of each user to the authorized service for a duration corresponding to his subscription. o Community networks, where a user owns the home gateway to the Internet and allows other distributed users to have access to the Internet through passing by his home gateway. Users may need to pass by other users (in the community network) in order to reach the home gateway. In this use-case, there is a need for credentials distribution in a dynamic manner (adapting to the random configuration of the community network) to allow mutual authentication between each pair of communicating users and between each user and the home gateway providing the Internet access. 6. Security Considerations This document focuses on the distributed authentication through the Kerberos protocol and presents the requirements to be considered. Moustafa, et al. Expires April 19, 2012 [Page 7] Internet-Draft Distributed Authentication October 2011 7. IANA Considerations This document does not require actions by IANA. 8. Acknowledgment We would like to thank Hannes Tschofenig for his comments on this draft and for encouraging us to publish it. Many thanks for Sam Hartman for all his useful comments and feedbacks on this draft. We would also like to thank our colleague Estelle Transy for all the discussions during the use-cases definition. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [RFC3365] Schiller, J., "Strong Security Requirements for Internet Engineering Task Force Standard Protocols", August 2002. [RFC4120] Neumann, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", July 2005. Authors' Addresses Hassnaa Moustafa France Telecom - Orange 38-40 rue du General Leclerc Issy Les Moulineaux, 92794 Cedex 9 France Email: hassnaa.moustafa@orange.com Gilles Bourdon France Telecom - Orange France Immeuble Central 1, clos de la courtine 93162 Noisy le Grand, France Email: gilles.bourdon@orange.com Moustafa, et al. Expires April 19, 2012 [Page 8] Internet-Draft Distributed Authentication October 2011 Tom Yu MIT Kerberos Consortium Email: tlyu@mit.edu Moustafa, et al. Expires April 19, 2012 [Page 9]