idnits 2.17.1 draft-baker-openstack-rbac-federated-identity-00.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 date (October 17, 2014) is 3479 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track October 17, 2014 5 Expires: April 20, 2015 7 Federated Identity for IPv6 Role-base Access Control 8 draft-baker-openstack-rbac-federated-identity-00 10 Abstract 12 This note describes an IPv6 option intended to carry a Federated 13 Identity for use in Role-Based Access Control. Rather than identify 14 a person, it identifies a group of systems that the sender is a 15 member of. Role-Based Access Control permits specified sets of 16 systems to communicate with other specified sets of systems, with the 17 intention of scalability. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 20, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Federated identity Option . . . . . . . . . . . . . . . . . . 3 55 2.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.1. Use in the Destination Options Header . . . . . . . . 5 57 2.1.2. Use in the Hop-by-Hop Header . . . . . . . . . . . . 5 58 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 59 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 60 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 7. Informative References . . . . . . . . . . . . . . . . . . . 7 63 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 In the course of developing draft-baker-ipv6-openstack-model, it was 69 determined that a way was needed to encode a federated identity for 70 use in Role-Based Access Control. This note describes an IPv6 71 [RFC2460] option that could be carried in the Hop-by-Hop or 72 Destination Options Header. The format of an option is defined in 73 section 4.2 of that document, and the Hop-by-Hop and Destination 74 Options are defined in sections 4.3 and 4.6 of that document 75 respectively. 77 A "Federated Identity", in the words of the Wikipedia, "is the means 78 of linking an electronic identity and attributes, stored across 79 multiple distinct identity management systems." In this context, it 80 is a fairly weak form of that; it is intended for quick 81 interpretation in an access list at the Internet layer as opposed to 82 deep analysis for login or other security purposes at the application 83 layer, and rather than identifying an individual or a system, it 84 identifies a set of systems whose members are authorized to 85 communicate freely among themselves and may also be authorized to 86 communicate with other identified sets of systems. Either two 87 systems are authorized to communicate or they are not, and 88 unauthorized traffic can be summarily discarded. The identifier is 89 defined in a hierarchical fashion, for flexibility and scalability. 91 "Role-Based Access Control", in this context, applies to groups of 92 virtual or physical hosts, not individuals. In the simplest case, 93 the several tenants of a multi-tenant data center might be 94 identified, and authorized to communicate only with other systems 95 within the same "tenant" or with identified systems in other tenants 96 that manage external access. One could imagine a company purchasing 97 cloud services from multiple data center operators, and as a result 98 wanting to identify the systems in its tenant in one cloud service as 99 being authorized to communicate with the systems its tenant of the 100 other. One could further imagine a given department within that 101 company being authorized to speak only with itself and an identified 102 set of other departments within the same company. To that end, when 103 a datagram is sent, it is tagged with the federated identify of the 104 sender (e.g., {datacenter, client, department}), and the receiving 105 system filters traffic it receives to limit itself to a specific set 106 of authorized communicants. 108 2. Federated identity Option 110 The option is defined as a sequence of numbers that identify relevant 111 parties hierarchically. The specific semantics (as in, what number 112 identifies what party) are beyond the scope of this specification, 113 but they may be interpreted as being successively more specific; as 114 shown in Figure 1, the first might identify a cloud operator, the 115 second, if present, might identify a client of that operator, and the 116 third, if present, might identify a subset of that client's systems. 117 In an application entirely used by Company A, there might be only one 118 number, and it would identify sets of systems important to Company A 119 such as business units. If Company A uses the services of a multi- 120 tenant data center #1, it might require that there be two numbers, 121 identifying Company A and its internal structure. If Company A uses 122 the services of both multi-tenant data centers #1 and #2, and they 123 are federated, the identifier might need to identify the data center, 124 the client, and the structure of the client. 126 _.----------------------. 127 _.----'' `------. 128 ,--'' `---. 129 ,-' DataCenter .---------------------. `-. 130 ,' Company #2,---'' Unauthorized `----. `. 131 ; ,' ,-----+-----. ,--+--------.`. : 132 | ( ( Department 1)--//--( Department 2) ) | 133 ; `. `-----+----+' `-----------',' | 134 `. `----. | X Company A _.---' ,' 135 '-. A|------X------------'' ,-' 136 `---. u| X _.--' 137 `------. t| X _.----'' 138 `---h|---------X-------'' 139 o| X 140 _.--r+-----------X------. 141 _.----'' i| X `------. 142 ,--'' z| X `---. 143 ,-' DataCenter e|--------------X-----. `-. 144 ,' Company #2,---''d| X `----. `. 145 ; ,' ,-----+-----. ,-+---------.`. : 146 | ( ( Department 1) ( Department 2) ) | 147 ; `. `-----------' `-----------',' | 148 `. `----. Company A _.---' ,' 149 '-. `--------------------'' ,-' 150 `---. _.--' 151 `------. _.----'' 152 `----------------------'' 154 Figure 1: Use case: Identifying authorized communicatants in an RBAC 155 environment 157 2.1. Option Format 159 A number (Figure 2) is represented as a base 128 number whose 160 coefficients are stored in the lower 7 bits of a string of bytes. 161 The upper bit of each byte is zero, except in the final byte, in 162 which case it is 1. The most significant coefficient of a non-zero 163 number is never zero. 165 8 = 8*128^0 166 +-+------+ 167 |1| 8 | 168 +-+------+ 170 987 = 7*128^1 + 91*128^0 171 +-+------+-+------+ 172 |0| 7 |1| 91 | 173 +-+------+-+------+ 175 121393 = 7*128^2 + 52*128^1 + 49*128^0 176 +-+------+-+------+-+------+ 177 |0| 7 |0| 52 |1| 49 | 178 +-+------+-+------+-+------+ 180 Figure 2: Sample numbers 182 The identifier {8, 987, 121393} looks like 184 +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ 185 | type | len=6 |1| 8 |0| 7 |1| 91 |0| 7 |0| 52 |1| 49 | 186 +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ 188 Figure 3 190 2.1.1. Use in the Destination Options Header 192 In an environment in which the validation of the option only occurs 193 in the receiving system or its hypervisor, this option is best placed 194 in the Destination Options Header. 196 2.1.2. Use in the Hop-by-Hop Header 198 In an environment in which the validation of the option occurs in 199 transit, such as in a firewall or other router, this option is best 200 placed in the Hop-by-Hop Header. 202 3. IANA Considerations 204 This memo asks the IANA for no new parameters yet. It will. 206 4. Security Considerations 208 The proposed option is intended for use in a context such as draft- 209 baker-ipv6-openstack-model, in which tagging of data with a group 210 identity of its sender coupled with a policy that a given destination 211 may only be reachable through the network for a stated set of 212 senders, whether implemented at the end station or somewhere en 213 route. It is not a complete security solution; if the use of TLS or 214 other security apparatus would have been appropriate in its non- 215 datacenter implementation, it is still appropriate. The tool 216 presents a first-order removal of obvious bogons, similar to the 217 behavior of a firewall. 219 Some may argue that the presence of a firewall, whether implemented 220 using RBAC or any other technology, fails Saltzer's End to End 221 Arguments in System Design [Saltzer]. This is not the case, or at 222 least not the case any worse than current Internet implementation 223 does. A system that is never reachable is indistinguishable from one 224 that does not exist, in the Internet. A correspondent may desire to 225 reach it, but that is another matter. If the system were sometimes 226 reachable, perhaps because a path sometimes went one way and 227 sometimes another, that would subvert the intention of the endpoint, 228 and would lead the administration to attempt to diagnose a fault. 229 However, a system that is never reachable doesn't result in such 230 procedures unless the administration thinks it should be reachable in 231 the normal case, and a system in another network would not have such 232 assumptions placed on it. 234 5. Privacy Considerations 236 Privacy bears especial consideration in this case, as the defined 237 identifier format could obviously be used for any purpose including 238 carrying an individual's Social Security Number or other identifying 239 information. Doing so, however, would defeat the intended purpose, 240 which is to scalably identify a group of computers that the sender of 241 a message is a member of, for the purposes of Role-Based Access 242 Control. [RFC6973] observes that 244 "...the extent to which protocol designers can foresee all of the 245 privacy implications of a particular protocol at design time is 246 limited. An individual protocol may be relatively benign on its 247 own, and it may make use of privacy and security features at lower 248 layers of the protocol stack (Internet Protocol Security, 249 Transport Layer Security, and so forth) to mitigate the risk of 250 attack. But when deployed within a larger system or used in a way 251 not envisioned at design time, its use may create new privacy 252 risks." 254 In this case, the possibility is all too obvious. 256 [RFC2804] and [RFC7258] go on from there to note that monitoring of 257 the Internet, whether specific to a warrant or pervasive, although 258 carried out with the best of intent (in their own view) by IT staff, 259 law enforcement, or intelligence agencies, reduces the security of 260 the system and provides a means by which attacks of various kinds can 261 be carried out. A recent example of the kinds of attacks that can 262 result has involved Apple Computer, which at the time escrowed 263 security keys for owners of its products. Some individuals had 264 photographs stolen and published that were embarrassing to them, and 265 Apple was accused of leaking the security information after being 266 hacked. Apple responds that the hack, and the leak, never occurred. 267 However, Apple subsequently chose to follow the advice of [RFC1984], 268 which was to no longer open itself to the possibility of such a leak 269 by escrowing the keys. 271 It would be a mistake to use this option to identify a person in any 272 way. It would subvert the intended scalability of RBAC, and would 273 likely compromise the privacy of the individual. 275 By extension, it could be argued that an option that identifies the 276 company of the sender (such as {data center operator, customer}) 277 simplifies traffic analysis of the sender's computers and may 278 contribute to fingerprinting techniques that might further identify 279 the computer. The discerning reader will note, however, that the 280 IPv6 header already contains information that explicitly accomplishes 281 that, in its source address. 283 6. Acknowledgements 285 The subject arose from conversations within Cisco and with a Cisco 286 customer regarding the use of federated identity in an OpenStack++ 287 environment. Chris Marino specifically contributed. The privacy 288 issues were discussed with Alissa Cooper, who made suggestions. 290 7. Informative References 292 [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG 293 Statement on Cryptographic Technology and the Internet", 294 RFC 1984, August 1996. 296 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 297 (IPv6) Specification", RFC 2460, December 1998. 299 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 300 2000. 302 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 303 Morris, J., Hansen, M., and R. Smith, "Privacy 304 Considerations for Internet Protocols", RFC 6973, July 305 2013. 307 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 308 Attack", BCP 188, RFC 7258, May 2014. 310 [Saltzer] Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end 311 arguments in system design", ACM Transactions on Computer 312 Systems (TOCS) v.2 n.4, p277-288, Nov 1984. 314 Appendix A. Change Log 316 Initial Version: September 2014 318 Author's Address 320 Fred Baker 321 Cisco Systems 322 Santa Barbara, California 93117 323 USA 325 Email: fred@cisco.com