idnits 2.17.1 draft-moustafa-krb-wg-mesh-nw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 17, 2011) is 4575 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3365' is defined on line 342, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Kerberos Working Group H. Moustafa 3 Internet-Draft France Telecom - Orange 4 Intended status: Informational G. Bourdon 5 Expires: April 19, 2012 France Telecom - Orange France 6 T. Yu 7 MIT Kerberos Consortium 8 October 17, 2011 10 Distributed Authentication in Wireless Mesh Networks Through Kerberos 11 Tickets 12 draft-moustafa-krb-wg-mesh-nw-02.txt 14 Abstract 16 This document presents the problem of authentication and 17 authorization in wireless mesh networks constituted by several users 18 communicating with application servers and communicating with each 19 other in a single or multi-hop fashion. Each user in this 20 environment can also play the role of an application provider. 22 Imagine a large music event where the provided network infrastructure 23 is enhanced with network storage equipment to allow visitors to 24 access content relating to the bands playing at the events, such as 25 recorded video of previous performances, supplementary audio and 26 video material relevant to the bands playing, etc. Certain content 27 is, however, not necessarily available to everyone under the same 28 conditions. Instead access control is applied before the full range 29 of audio, and video material can be accessed. Other content, such as 30 previews, might be offered for free. How can such authentication, 31 and authorization infrastructure be made available with minimal 32 configuration complexity for a temporary event like a music festival? 34 This document lists the requirements for a potentially needed 35 Kerberos extension and presents a solution proposal based on the 36 attempt to use a Kerberos extension for mutual authentication in 37 wireless mesh networks. 39 Status of this Memo 41 This Internet-Draft is submitted to IETF in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 19, 2012. 56 Copyright Notice 58 Copyright (c) 2011 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 1. Specification Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction and Problem Statement 79 Authentication and authorization to services access is still an open 80 problem in wireless mesh network distributed environments in which 81 several users would need to communicate to several application 82 servers and with each other in a single or multi-hop fashion, and 83 each user could play the role of an application provider. 85 The Kerberos authentication model [RFC4120] uses a symmetric 86 cryptography approach, offering a high security level and allowing 87 mutual authentication. The principle of using service tickets in 88 Kerberos allows for credentials distribution which is suitable for 89 wireless mesh networks distributed environments. However, the 90 centralized approach in Kerberos (where each user should communicate 91 with the authentication server each time he needs services 92 credentials) restricts its usage for authentication in such 93 distributed environments. Furthermore, Kerberos rather authenticates 94 each node with respect to the authentication server and to the 95 application server. The distributed credentials principle in 96 Kerberos (through Service tickets) is promising for allowing 97 authentication between each user and the application. However, the 98 authentication between each two users who communicate with each other 99 is still not covered by Service tickets, especially with the dynamic 100 nature of distributed environments in which users connectivity (that 101 could be single or multi-hop) change frequently with time. 103 Although the multi-hop communication is transparent to the 104 application, there is a need to handle the authentication and access 105 control among the different multi-hop communicating nodes to prevent 106 against malicious actions taken by the human users themselves. Based 107 on this fact, this draft proposes to use a common key obtained by 108 Kerberos for authentication among each two nodes who communicate 109 together in a multi-hop fashion. This common key is dynamic 110 (renewable with time) for security reasons in such dynamic and 111 distributed wireless environment that is less secure. 113 3. Requirements 115 This section presents a number of requirements motivated by the 116 problem defined in the previous section. These requirements are as 117 follows: 118 o Distributed environment consisting of fixed and mobile nodes. 119 o Dynamic neighbors and dynamic application providers (any node 120 could be an application provider at any time providing 121 applications to other nodes in the network, e.g. file sharing, 122 sending special announcement concerning the surrounding 123 environments, and sending alarms in case of problems). 124 o User Generated Content (UGC) application, in which each node could 125 be a source of content (mainly multimedia contents) for other 126 nodes in the network, e.g. transmitting video snapshots during 127 festival events. 128 o Hundreds of nodes (indoor or outdoor environment). 129 o Personal devices (of low power) individually used by users. 130 o Multihop communication. 131 o Authentication and access control of each user node by a trusted 132 third party. 133 o Access control of each user by a trusted third party in a way that 134 corresponds to the user subscription type and profile. 135 o Mutual authentication between each pair of communicating users. 136 o Limited bandwidth: need for minimizing traffic (minimizing the 137 communication with the KDC). 138 o Dynamic credentials (attributing dynamic credentials to be 139 distributed to each user). 141 4. Kerberos Extension Solution Proposal 143 This section presents a solution proposal extending the Kerberos 144 authentication model for authenticating each user node in wireless 145 mesh networks with respect to the network operator and with respect 146 to other users nodes participating in the network. 148 The Kerberos server resides in the local mesh network or in an 149 external network and each user node needs to communicate firstly with 150 this server in order to authenticate with respect to the operator and 151 to obtain the necessary credentials (Kerberos tickets) for 152 authentication with other users nodes and for accessing the offered 153 services in the mesh network. The communication can take place in a 154 single hop or through multi-hops (passing by intermediate users 155 nodes) according to the proximity of each user node from the 156 application providers nodes. 158 To prevent unreliable communication from taking place (intermediate 159 nodes could do DoS, messages truncating,...), this solution proposal 160 extends the classical Kerberos authentication model to adapt to the 161 multi-hop communication through introducing a new shared secret for 162 authentication and access control between intermediate nodes along 163 the multi-hop communication. But, if this secret is the same for all 164 the time, it could be compromised and the entire network would be 165 compromised. It is then proposed in this draft to obtain several 166 shared secrets during the service ticket request for the service for 167 which the multihop communication is needed. 169 The solution proposal takes the following sequence: 170 o Each user node wishing to access the services offered by the mesh 171 network starts by sending a first request to the KDC (TGT part) in 172 order to authenticate with respect to the operator and to obtain 173 the TGT ticket. The process is similar to the classical Kerberos 174 authentication approach, and the user, if legitimate, obtains the 175 corresponding TGT ticket. 176 o After obtaining the TGT, the user node re-contacts the KDC (TGS 177 part), through sending a TGS request, in order to obtain the 178 necessary credentials (including the service ticket for the 179 service for which multihop communication will be employed in 180 addition to the shared secrets for authentication during the 181 multihop communication) while presenting the obtained TGT ticket 182 as a proof of authenticity. The classical Kerberos TGS request 183 should be extended to illustrate the need of extra credentials for 184 authentication with intermediate nodes along the multi-hop 185 communication. The following figure illustrates this extension, 186 where a new flag is defined in the flags field in the reserved 187 bits between bits 12 and 25 taking the value 1 to indicate the 188 case of Kerberos in the multi-hop mode. 190 o 192 _ _ _ _ _ _ _ _ _ __ _ _ _ __ _ _ _ 193 |pvno| msg-type | padata | req-body | 194 |_ _ |_ __ _ _ _|_ _ _ __|_ _ _ _ _ | 195 | 196 | 197 | 198 V 199 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 200 |flags|cna-|realm|sna-|fr|ti|rtime|nonce|etype|addr|enc |addit. | 201 |_ _ _|_me |_ _ _|_me |om|ll|_ _ _|_ _ _|_ _ _|_ _ |authdata|tickets| 202 | 203 | 204 | 205 V 207 0_ _ _ _ _ _ 12_ _ _ _ _ _ _ _ _ _ 25_ _ _ _ _ _ _ _ _ _ _ _ _31 208 |_|_ ___ _ _| _| _ _ _ _ _|X |__ _ _ |_|_ _ _ _ _ _ _ _ _ _ _ |_| 210 Figure 1: Extended TGS-REQ 212 o Once the KDC (TGS part), receiving the TGS request from the user, 213 verifies the TGT ticket and the user authenticity, it sends to the 214 user the Kerberos TGS reply message extended to contain the 215 necessary credentials according to the user profile and according 216 to the required service. 217 o The extended Kerberos TGS reply message includes the service 218 ticket for the service for which the multihop wommunication will 219 be employed as well as the shared secrets. 220 o To avoid the shared secret compromise, several shared secrets are 221 obtained, where each shared secret is valid for a given time 222 interval. However, the shared secret distributions should be done 223 in a mean that would not compromise the security of the whole 224 network: 225 * If the shared secrets are required by each mesh node at each 226 time interval, this would generate lot of traffic during the 227 communication with the KDC. 228 * If the shared secrets for future time intervals are pre- 229 generated by the KDC and given in batch to each user, this 230 would optimize traffic, but if a node is compromised at an 231 interval of time, all the shared secrets would be known and the 232 network would be compromised. 233 o Then, the KDC sends to each mesh node in the extended TGS reply 234 message the current interval shared secret and the pre-generated 235 ones for the future, while each pre-generated shared secret is 236 encrypted with a key corresponding to the its related time 237 interval. This encryption key should be sent to each mesh node in 238 the corresponding time interval either through Kerberos protocol 239 or through a multicast routing protocol. The following figure 240 illustrates the extended TGS reply message. In this extended 241 message: i) a new flag is defined in the flags field in the 242 reserved bits between bits 14 and 31 taking the value 1 to 243 indicate the case of Kerberos in the multi-hop mode. ii) a new 244 field authorized-data is added which is identical to the 245 authorization data field existing in the service ticket and 246 containing elements, where the first element contains the current 247 time interval in its (type) part and the corresponding shared key 248 to this interval in its (data part). The other elements contains 249 the upcoming time intervals and the corresponding shared keys in 250 an encrypted form as explained above. 251 o 253 _ _ _ __ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 254 |pvno| msg-type| padata | crealm|cname | ticket| enc-part | 255 |_ _ |_ _ _ _ _|_ _ _ _ |_ _ _ _| _ _ |_ _ _ _|_ _ _ _ _ | 256 | 257 | 258 | 259 V 260 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 261 |key|last|non|key|flags|auth|start|end |renew|srea|sna|cad-|authorized| 262 |_ _|req_|_ce|exp|_ _ _|time|time |time|till_|_lm_|_me|_dr_|_ data_ _ | 263 | | 264 | | 265 V | 266 0_ _ _ _ _ _ _ _ _ _ _14_ _ _ _ _ _ _ _ _ _ _ _ 31 | 267 |_|_ ___ _ _ _ _ _ _ _|_|__ _ _ |X| _ _ _ _ _ _ |_| | 268 | 269 V 270 _ _ _ __ _ _ _ _ _ _ _ _ _ __ _ _ _ _ _ _ _ _ _ _ 271 | _ _ _ __ _ _ _ _ _ _ _ _ _ _ _ _ _ | 272 ||ad-type | ad-data| . . . . . |ad-type|ad-data|| 273 ||_ _ _ _ |_ _ _ _| |__ _ _ |_ _ _ _|| 274 |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _| 275 Elements 277 Figure 2: Extended TGS-REP 279 o Group keys can be also considered allowing to have a shared secret 280 for each group of mesh nodes and allowing each mesh node to 281 participate to more than one group and hence to have several group 282 keys. If one group key is compromised it could be deleted by the 283 KDC. Mesh nodes sharing the same group key are mesh nodes sharing 284 some common characteristics (making a cluster, hierarchal group 285 keys for example, ...). 287 5. Potential Use-cases 289 This section presents the potential use-cases for distributed 290 environments of wireless mesh networks having multi-hop communication 291 and requiring distributed authentication authorization. 292 o Temporary network infrastructure deployment for special events 293 (sport events, music festivals, ..). Network operators deploy 294 temporary low-cost infrastructure for temporary events and hence 295 counts on the communication of users with application servers that 296 are locally deployed. Also the users themselves can play the role 297 of application providers contributing to the diffusion of 298 multimedia services (video snapshots on the event,video streams 299 with inserted comments, video streaming for what was missed in the 300 event, downloading an interactive audio-visual program for the 301 event,. ..). In such use-case, there is a need for dynamic 302 credentials distribution on the different participating nodes and 303 there is also a need of controlling the access of each user to the 304 authorized service for a duration corresponding to his 305 subscription. 306 o Community networks, where a user owns the home gateway to the 307 Internet and allows other distributed users to have access to the 308 Internet through passing by his home gateway. Users may need to 309 pass by other users (in the community network) in order to reach 310 the home gateway. In this use-case, there is a need for 311 credentials distribution in a dynamic manner (adapting to the 312 random configuration of the community network) to allow mutual 313 authentication between each pair of communicating users and 314 between each user and the home gateway providing the Internet 315 access. 317 6. Security Considerations 319 This document focuses on the distributed authentication through the 320 Kerberos protocol and presents the requirements to be considered. 322 7. IANA Considerations 324 This document does not require actions by IANA. 326 8. Acknowledgment 328 We would like to thank Hannes Tschofenig for his comments on this 329 draft and for encouraging us to publish it. 331 Many thanks for Sam Hartman for all his useful comments and feedbacks 332 on this draft. 334 We would also like to thank our colleague Estelle Transy for all the 335 discussions during the use-cases definition. 337 9. Normative References 339 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 340 Requirement Levels", March 1997. 342 [RFC3365] Schiller, J., "Strong Security Requirements for Internet 343 Engineering Task Force Standard Protocols", August 2002. 345 [RFC4120] Neumann, C., Yu, T., Hartman, S., and K. Raeburn, "The 346 Kerberos Network Authentication Service (V5)", July 2005. 348 Authors' Addresses 350 Hassnaa Moustafa 351 France Telecom - Orange 352 38-40 rue du General Leclerc 353 Issy Les Moulineaux, 92794 Cedex 9 354 France 356 Email: hassnaa.moustafa@orange.com 358 Gilles Bourdon 359 France Telecom - Orange France 360 Immeuble Central 1, clos de la courtine 361 93162 Noisy le Grand, 362 France 364 Email: gilles.bourdon@orange.com 365 Tom Yu 366 MIT Kerberos Consortium 368 Email: tlyu@mit.edu