Internet DRAFT - draft-baker-openstack-rbac-federated-identity
draft-baker-openstack-rbac-federated-identity
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]
