Network Working Group F. Baker Internet-Draft Cisco Systems Intended status: Standards Track October 17, 2014 Expires: April 20, 2015 Federated Identity for IPv6 Role-base Access Control draft-baker-openstack-rbac-federated-identity-00 Abstract This note describes an IPv6 option intended to carry a Federated Identity for use in Role-Based Access Control. Rather than identify a person, it identifies a group of systems that the sender is a member of. Role-Based Access Control permits specified sets of systems to communicate with other specified sets of systems, with the intention of scalability. Status of This Memo This Internet-Draft is submitted 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/. 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 20, 2015. Copyright Notice Copyright (c) 2014 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 Baker Expires April 20, 2015 [Page 1] Internet-Draft RBAC Identity October 2014 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Federated identity Option . . . . . . . . . . . . . . . . . . 3 2.1. Option Format . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Use in the Destination Options Header . . . . . . . . 5 2.1.2. Use in the Hop-by-Hop Header . . . . . . . . . . . . 5 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 7. Informative References . . . . . . . . . . . . . . . . . . . 7 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In the course of developing draft-baker-ipv6-openstack-model, it was determined that a way was needed to encode a federated identity for use in Role-Based Access Control. This note describes an IPv6 [RFC2460] option that could be carried in the Hop-by-Hop or Destination Options Header. The format of an option is defined in section 4.2 of that document, and the Hop-by-Hop and Destination Options are defined in sections 4.3 and 4.6 of that document respectively. A "Federated Identity", in the words of the Wikipedia, "is the means of linking an electronic identity and attributes, stored across multiple distinct identity management systems." In this context, it is a fairly weak form of that; it is intended for quick interpretation in an access list at the Internet layer as opposed to deep analysis for login or other security purposes at the application layer, and rather than identifying an individual or a system, it identifies a set of systems whose members are authorized to communicate freely among themselves and may also be authorized to communicate with other identified sets of systems. Either two systems are authorized to communicate or they are not, and unauthorized traffic can be summarily discarded. The identifier is defined in a hierarchical fashion, for flexibility and scalability. "Role-Based Access Control", in this context, applies to groups of virtual or physical hosts, not individuals. In the simplest case, the several tenants of a multi-tenant data center might be identified, and authorized to communicate only with other systems within the same "tenant" or with identified systems in other tenants Baker Expires April 20, 2015 [Page 2] Internet-Draft RBAC Identity October 2014 that manage external access. One could imagine a company purchasing cloud services from multiple data center operators, and as a result wanting to identify the systems in its tenant in one cloud service as being authorized to communicate with the systems its tenant of the other. One could further imagine a given department within that company being authorized to speak only with itself and an identified set of other departments within the same company. To that end, when a datagram is sent, it is tagged with the federated identify of the sender (e.g., {datacenter, client, department}), and the receiving system filters traffic it receives to limit itself to a specific set of authorized communicants. 2. Federated identity Option The option is defined as a sequence of numbers that identify relevant parties hierarchically. The specific semantics (as in, what number identifies what party) are beyond the scope of this specification, but they may be interpreted as being successively more specific; as shown in Figure 1, the first might identify a cloud operator, the second, if present, might identify a client of that operator, and the third, if present, might identify a subset of that client's systems. In an application entirely used by Company A, there might be only one number, and it would identify sets of systems important to Company A such as business units. If Company A uses the services of a multi- tenant data center #1, it might require that there be two numbers, identifying Company A and its internal structure. If Company A uses the services of both multi-tenant data centers #1 and #2, and they are federated, the identifier might need to identify the data center, the client, and the structure of the client. Baker Expires April 20, 2015 [Page 3] Internet-Draft RBAC Identity October 2014 _.----------------------. _.----'' `------. ,--'' `---. ,-' DataCenter .---------------------. `-. ,' Company #2,---'' Unauthorized `----. `. ; ,' ,-----+-----. ,--+--------.`. : | ( ( Department 1)--//--( Department 2) ) | ; `. `-----+----+' `-----------',' | `. `----. | X Company A _.---' ,' '-. A|------X------------'' ,-' `---. u| X _.--' `------. t| X _.----'' `---h|---------X-------'' o| X _.--r+-----------X------. _.----'' i| X `------. ,--'' z| X `---. ,-' DataCenter e|--------------X-----. `-. ,' Company #2,---''d| X `----. `. ; ,' ,-----+-----. ,-+---------.`. : | ( ( Department 1) ( Department 2) ) | ; `. `-----------' `-----------',' | `. `----. Company A _.---' ,' '-. `--------------------'' ,-' `---. _.--' `------. _.----'' `----------------------'' Figure 1: Use case: Identifying authorized communicatants in an RBAC environment 2.1. Option Format A number (Figure 2) is represented as a base 128 number whose coefficients are stored in the lower 7 bits of a string of bytes. The upper bit of each byte is zero, except in the final byte, in which case it is 1. The most significant coefficient of a non-zero number is never zero. Baker Expires April 20, 2015 [Page 4] Internet-Draft RBAC Identity October 2014 8 = 8*128^0 +-+------+ |1| 8 | +-+------+ 987 = 7*128^1 + 91*128^0 +-+------+-+------+ |0| 7 |1| 91 | +-+------+-+------+ 121393 = 7*128^2 + 52*128^1 + 49*128^0 +-+------+-+------+-+------+ |0| 7 |0| 52 |1| 49 | +-+------+-+------+-+------+ Figure 2: Sample numbers The identifier {8, 987, 121393} looks like +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ | type | len=6 |1| 8 |0| 7 |1| 91 |0| 7 |0| 52 |1| 49 | +-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+ Figure 3 2.1.1. Use in the Destination Options Header In an environment in which the validation of the option only occurs in the receiving system or its hypervisor, this option is best placed in the Destination Options Header. 2.1.2. Use in the Hop-by-Hop Header In an environment in which the validation of the option occurs in transit, such as in a firewall or other router, this option is best placed in the Hop-by-Hop Header. 3. IANA Considerations This memo asks the IANA for no new parameters yet. It will. 4. Security Considerations The proposed option is intended for use in a context such as draft- baker-ipv6-openstack-model, in which tagging of data with a group identity of its sender coupled with a policy that a given destination may only be reachable through the network for a stated set of senders, whether implemented at the end station or somewhere en Baker Expires April 20, 2015 [Page 5] Internet-Draft RBAC Identity October 2014 route. It is not a complete security solution; if the use of TLS or other security apparatus would have been appropriate in its non- datacenter implementation, it is still appropriate. The tool presents a first-order removal of obvious bogons, similar to the behavior of a firewall. Some may argue that the presence of a firewall, whether implemented using RBAC or any other technology, fails Saltzer's End to End Arguments in System Design [Saltzer]. This is not the case, or at least not the case any worse than current Internet implementation does. A system that is never reachable is indistinguishable from one that does not exist, in the Internet. A correspondent may desire to reach it, but that is another matter. If the system were sometimes reachable, perhaps because a path sometimes went one way and sometimes another, that would subvert the intention of the endpoint, and would lead the administration to attempt to diagnose a fault. However, a system that is never reachable doesn't result in such procedures unless the administration thinks it should be reachable in the normal case, and a system in another network would not have such assumptions placed on it. 5. Privacy Considerations Privacy bears especial consideration in this case, as the defined identifier format could obviously be used for any purpose including carrying an individual's Social Security Number or other identifying information. Doing so, however, would defeat the intended purpose, which is to scalably identify a group of computers that the sender of a message is a member of, for the purposes of Role-Based Access Control. [RFC6973] observes that "...the extent to which protocol designers can foresee all of the privacy implications of a particular protocol at design time is limited. An individual protocol may be relatively benign on its own, and it may make use of privacy and security features at lower layers of the protocol stack (Internet Protocol Security, Transport Layer Security, and so forth) to mitigate the risk of attack. But when deployed within a larger system or used in a way not envisioned at design time, its use may create new privacy risks." In this case, the possibility is all too obvious. [RFC2804] and [RFC7258] go on from there to note that monitoring of the Internet, whether specific to a warrant or pervasive, although carried out with the best of intent (in their own view) by IT staff, law enforcement, or intelligence agencies, reduces the security of the system and provides a means by which attacks of various kinds can Baker Expires April 20, 2015 [Page 6] Internet-Draft RBAC Identity October 2014 be carried out. A recent example of the kinds of attacks that can result has involved Apple Computer, which at the time escrowed security keys for owners of its products. Some individuals had photographs stolen and published that were embarrassing to them, and Apple was accused of leaking the security information after being hacked. Apple responds that the hack, and the leak, never occurred. However, Apple subsequently chose to follow the advice of [RFC1984], which was to no longer open itself to the possibility of such a leak by escrowing the keys. It would be a mistake to use this option to identify a person in any way. It would subvert the intended scalability of RBAC, and would likely compromise the privacy of the individual. By extension, it could be argued that an option that identifies the company of the sender (such as {data center operator, customer}) simplifies traffic analysis of the sender's computers and may contribute to fingerprinting techniques that might further identify the computer. The discerning reader will note, however, that the IPv6 header already contains information that explicitly accomplishes that, in its source address. 6. Acknowledgements The subject arose from conversations within Cisco and with a Cisco customer regarding the use of federated identity in an OpenStack++ environment. Chris Marino specifically contributed. The privacy issues were discussed with Alissa Cooper, who made suggestions. 7. Informative References [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000. [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, July 2013. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, May 2014. Baker Expires April 20, 2015 [Page 7] Internet-Draft RBAC Identity October 2014 [Saltzer] Saltzer, JH., Reed, DP., and DD. Clark, "End-to-end arguments in system design", ACM Transactions on Computer Systems (TOCS) v.2 n.4, p277-288, Nov 1984. Appendix A. Change Log Initial Version: September 2014 Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Email: fred@cisco.com Baker Expires April 20, 2015 [Page 8]