idnits 2.17.1 draft-dondeti-irtf-smug-gkm-mobility-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 308 looks like a reference -- Missing reference section? '2' on line 313 looks like a reference -- Missing reference section? '3' on line 317 looks like a reference -- Missing reference section? '4' on line 320 looks like a reference -- Missing reference section? '5' on line 324 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force L. Dondeti/Nortel 3 Internet Draft B. Decleene and S. Griffin/TASC 4 draft-dondeti-irtf-smug-gkm-mobility-00.txt T. Hardjono/Verisign 5 July 2001 J. Kurose, D. Towsley, 6 Expires: January 2002 C. Zhang and S. Vasudevan/UMass. 8 Group key management in wireless and mobile environments 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference mate- 23 rial or to cite them other than as "work in progress". 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 Abstract 30 In this document we consider the problem of key management in a 31 mobile wireless networking environment, such as a dynamic, dis- 32 tributed setting in which command and control nodes move along with 33 individual users. In this scenario, data must be securely multicast 34 from one source to many users, requiring that users be properly 35 keyed. Furthermore, because users move in and out of the session (due 36 to mobility, attrition, and reinforcement), in order to preserve con- 37 fidentiality, it becomes necessary to rekey each time a user enters 38 or leaves. We present a hierarchical framework and key distribution 39 algorithms for such a dynamic environment, with a focus on how keys 40 and trust relationships are transferred when users move between so- 41 called "areas" in the group management hierarchy. We present several 42 schemes including one that rekeys every time a member moves from area 43 to area and one that delays rekeying so long as security is not com- 44 promised. 46 Internet Draft Mobile group key management 48 Table of Contents 50 1 Introduction to secure mobile groups 51 2 Hierarchical group key management 52 3 Impact of mobility on key management 53 3.1 Mobile members 54 3.2 Mobile key distributors 55 4 Key management to address mobility 56 4.1 Baseline rekeying 57 4.2 Immediate rekeying 58 4.3 Delayed rekeying 59 5 Summary and future work 60 6 Authors' contact information 62 1 Introduction to secure mobile groups 64 Consider secure communication to a group of mobile nodes. The commu- 65 nication could be over wired or wireless networks. Several solutions 66 exist in the literature for secure group key management. A group man- 67 ager distributes a common key used for encryption of data to the 68 sender(s) as well as the members. For several applications, it is 69 necessary that perfect forward and backward access control be main- 70 tained in the group. To achieve perfect forward/backward access con- 71 trol, the group manager sends a new group key at each membership 72 change. 74 There are two types of solutions for scalable rekeying of large 75 groups. One involves maintenance of a logical key hierarchy (LKH) 76 [1,2], while the other calls for a group management hierarchy. A com- 77 bination of the two approaches is probably the best solution for 78 efficient rekeying. 80 When members are mobile, hierarchical group key management (in effect 81 decentralized group key management) works better than centralized 82 group key management used in LKH-based approaches. In hierarchical 83 group management (e.g. Iolus [3] and Intra-domain group key manage- 84 ment [4]), there are several "area key distributors (AKD)" (subgroup 85 managers in Iolus) to manage the group. If the AKDs are geographi- 86 cally distributed, mobile members can get access to new group keys as 87 long as they are "near" to one of the AKDs. 89 Internet Draft Mobile group key management 91 The notion of members moving between areas or subgroups is new to 92 group key management. We investigate the issues involved in area 93 rekeying when members move between areas. We present several differ- 94 ent rekeying algorithms and analyze their applicability. Note that in 95 some applications, senders must stop data transmission during rekey- 96 ing. Mobile group members may add to the rekeying overhead when they 97 move between areas. We propose algorithms that minimize the time off- 98 line due to rekeying. 100 2 Hierarchical group key management 102 A common approach for designing a scalable network service is to 103 adopt a hierarchical structure, and a number of recently-proposed key 104 management algorithms have adopted such an approach [3,4]. Broadly, 105 these rekeying algorithms operate by hierarchically dividing the key 106 management domain into smaller administratively scoped areas. The 107 details of hierarchical key management differ from one approach to 108 another, and so in our discussion below we adopt a framework based on 109 [4]. 111 Throughout the domain, a Domain Key Distributor (DKD) generates the 112 data key used by the sender for encrypting data. The DKD may be col- 113 located with the sender or shared throughout the domain by multiple 114 sessions. As discussed previously, whenever a new member joins a cur- 115 rent session or an existing member leaves a session, a new data key 116 must be generated and distributed to ensure both forward and backward 117 confidentiality. 119 The domain is further divided into disjoint areas. An area is unique 120 in that movement within the area does not require any additional sig- 121 naling with regard to rekeying; and the cost of rekeying members when 122 a join/leave occurs is considered reasonable. Areas may be small 123 (such as a fine-grained ad-hoc network) or large (such as a satellite 124 broadcast) depending upon the network topology and operational 125 arrangements. Similarly, an area can be either logically or geograph- 126 ically defined. 128 Within each area, an Area Key Distributor (AKD) is responsible for 129 distributing the data key to members within that area. Because the 130 distribution of the data key within an area must itself be secure, 131 area-local keys are used by the AKD to distribute a new data key to 132 members within the area. Approaches for intra-area rekeying include 133 Public Key Infrastructure (PKI), secure multicast, and logical tree- 134 based algorithms such as [2,1]. 136 From the definition of area, mobility impacts performance only when 137 members cross between areas. Without AKD reassignment, rekeying mes- 138 sages must cross heterogeneous network boundaries resulting in 140 Internet Draft Mobile group key management 142 additional performance degradation. Consequently, member movement 143 between areas requires a coordinated transfer of the security rela- 144 tionships. Inter-area rekeying algorithms address this problem by 145 introducing specific semantics for transferring between areas. 147 3 Impact of mobility on key management 149 Mobility complicates key management by allowing members to not only 150 leave or join a session but also transfer between networks while 151 remaining in the session. Since a mobile user may accumulate informa- 152 tion about the local security services for each area he/she visits, 153 the key management system must consider the level of trust to impart 154 to these mobile members and the performance implications should the 155 member leave the session. Furthermore, as a member moves, the net- 156 work latency between the member and the key management services may 157 change and result in additional performance degradation. 159 3.1 Mobile members 161 The performance of any inter-area rekeying algorithm strongly depends 162 upon the mobility characteristics of the members as well as their 163 join/leave characteristics. Members that remain in the session for 164 long periods of time and are highly mobile are likely to visit many 165 areas. As the number of these high-mobility members increase, the 166 amount of control overhead increases. Approaches that minimize the 167 amount of rekeying when a members moves between areas help address 168 this concern. 170 Fundamentally, inter-area rekeying requires members and/or key dis- 171 tributors to identify when a member is leaving one area and entering 172 a new area. Bind credentials that have been signed by the departing 173 area may be delivered to the member transferring to stream-line 174 his/her authentication onto the new area. Managing these credentials 175 is important to improving performance while ensuring confidentiality. 176 Alternatively, key distributors may coordinate between each other to 177 "hand-off" the member. 179 3.2 Mobile key distributors 181 Mobility of an AKD or DKD may result in substantial changes in the 182 hierarchical topology. To ensure performance, inter-area rekeying 183 must address the problems of new key distributor nomination/election, 184 member reassignment, and load balancing to ensure that the end-to-end 185 performance is maintained. 187 4 Key management to address mobility 188 Internet Draft Mobile group key management 190 In this document, we describe multiple inter-area key distribution 191 algorithms, where members may not only enter/leave the session but 192 may also move between areas. These algorithms are defined below. 194 4.1 Baseline rekeying 196 A direct approach for handling mobility across areas (called the 197 baseline algorithm) is to treat the movement as a leave from the old 198 area followed by a join to the new area. The member leaving the ses- 199 sion notifies the local AKD, which halts the current data transmis- 200 sion. Next, the local AKD updates the area key for the remaining mem- 201 bers by either securely unicasting to each member using their shared 202 private key, or exploiting a more sophisticated intra-area key proto- 203 col such as LKH [2]. Once this is updated securely, a new data key 204 can be distributed to all areas such that the departing member is 205 excluded. At this point, data transmission resumes. This approach 206 ensures forward confidentiality. 208 During the join, the process is similar. The new member informs the 209 local AKD of its intent to join. Data transmission is halted while a 210 new area key is distributed to the current members (through multi- 211 cast) and the new member (through unicast). Once complete, the new 212 data key is distributed to all of the members and transmission 213 resumes. This approach ensures backward confidentiality. 215 The disadvantage of the baseline algorithm is that data transmission 216 is unnecessarily interrupted twice during a transfer between areas 217 because the system cannot distinguish between a departing member and 218 a member that is simply moving. The result is degraded throughput and 219 additional computational complexity as extra keys are calculated. 221 4.2 Immediate rekeying 223 The immediate rekeying algorithm extends the baseline algorithm by 224 adding explicit semantics for a hand-off between areas. The member 225 initiates a transfer by notifying the two affected areas. Each area 226 updates the local area keys per their new membership. However, 227 unlike the baseline algorithm, no new data key is generated and the 228 data transmission continues uninterrupted. Note that when a member 229 actually leaves or joins the session, data transmission is inter- 230 rupted as new data and area keys are generated per the baseline algo- 231 rithm described previously. 233 4.3 Delayed rekeying 235 Both baseline and immediate rekeying algorithms rekey the local areas 236 as soon as a member transfers. As a result, a member that moves 237 rapidly between two areas may cause repeated local rekeying. In 239 Internet Draft Mobile group key management 241 baseline rekeying mobility of a single member affects all the members 242 in the domain (since the data key changes). 244 Delayed algorithms postpone local rekeying until a particular crite- 245 rion is satisfied. Members moving between multiple areas may accumu- 246 late multiple area keys and reuse these keys when they return to a 247 previously visited area. As always, if a member leaves or joins the 248 session, then the appropriate areas are rekeyed to ensure forward and 249 backward confidentiality. 251 In pure delayed rekeying, each AKD maintains a list of members that 252 have left the area but still hold valid keys for the area. When a 253 member transfers, the area that the member is entering is rekeyed to 254 prevent a member from falsely transferring into an area to get access 255 to the old keys (backward confidentiality). For the departed area, 256 the AKD does not rekey but instead adds the member to the Extra Key 257 Owner List (EKOL). This list is reset whenever a local rekey occurs. 258 When a member returns to an area, it is checked against the EKOL and 259 no new keys are generated if it is on the list. 261 A characteristic of the delayed algorithms is that they defer some of 262 the rekeying until a member departs. In this case, all of the areas 263 that the member has currently valid keys are rekeyed as well to pre- 264 vent unauthorized access. Thus, the impact of member mobility is 265 reduced at the cost of increased leave semantics. 267 One modification of this approach proposed by Chun et. al. [5] 268 allows members who have previously visited an area and are reauthen- 269 ticated to receive the current area key to be added without rekeying 270 of the new area. The benefit of this approach is that the number of 271 keys generated and distributed is substantially reduced. The algo- 272 rithm can be further extended by overlaying periodic rekeying of the 273 areas to prevent any outside member from holding the key beyond a 274 finite period of time. Alternatively, threshold rekeying triggers a 275 rekey of an area whenever any member collects more than a given num- 276 ber of keys. This ensures that no member is able to accumulate all 277 the keys by visiting all of the areas. 279 5 Summary and future work 281 In this document, we describe group rekeying in the presence of 282 mobile members. We propose that hierarchical group key management 283 works best for managing mobile members of a secure group. We intro- 284 duce several rekeying schemes when members move from one area to 285 another area, while still being member of a group. 287 Our ongoing work includes mathematical analysis of the various rekey- 288 ing schemes to investigate the time off-line and rekeying overhead 290 Internet Draft Mobile group key management 292 due to mobility. We are currently developing a prototype of the key 293 management framework (KMF) and the rekeying algorithms. 295 Apart from the analysis and implementation of the protocols proposed 296 so far, our focus is on the following topics: 298 o Implications of mobility on SA management 300 o Mobile AKDs 302 When an AKD moves, members within its area may decide to (s)elect 303 a new AKD to manage them. We are currently investigating AKD 304 (s)election algorithms. 306 6 Bibliography 308 [1] D. Balenson, D. McGrew, and A. Sherman, "Key management for large 309 dynamic groups: One-way function trees and amortized initialization," 310 Internet Draft, Internet Engineering Task Force, Aug. 2000. Work in 311 progress. 313 [2] D. M. Wallner, E. Harder, and R. C. Agee, "Key management for 314 multicast: Issues and architectures," RFC (Informational) 2627, 315 Internet Engineering Task Force, Sept. 1998. 317 [3] S. Mittra, "Iolus: A framework for scalable secure multicasting," 318 in ACM SIGCOMM , (Cannes, France), sep 1997. 320 [4] T. Hardjono, B. Cain, and I. Monga, "Intra-domain group key man- 321 agement protocol," internet draft, Internet Engineering Task Force, 322 Feb. 2000. Work in progress. 324 [5] C. Zhang, B. DeCleene, J. Kurose, and D. Towsley, "Comparison of 325 inter-area rekeying algorithms for secure wireless group communica- 326 tions," tech. rep., June 2001. Submitted for publication. 328 7 Authors' contact information 330 Lakshminath R. Dondeti 331 Nortel Networks 332 600 Technology Park Drive 333 Billerica, MA 01821, USA 334 (978) 288-6406 335 ldondeti@nortelnetworks.com 337 Thomas Hardjono 338 Verisign Inc. 340 Internet Draft Mobile group key management 342 401 Edgewater Place, Suite 280 343 Wakefield, MA 01880, USA 344 thardjono@verisign.com 346 Brian DeCleene 347 Sean Griffin 348 TASC Inc. 349 55 Walkers Brook Dr. 350 Reading, MA 01867, USA 351 btdecleene@tasc.com 353 Jim Kurose 354 Don Towsley 355 Chun Zhang 356 Sudarshan Vasudevan 357 Computer Science department 358 University of Massachusetts, Amherst, MA 359 {kurose,towsley,czhang,svasu}@cs.umass.edu