One document matched: draft-baker-openstack-rbac-federated-identity-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section,
otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="3"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="std" docName="draft-baker-openstack-rbac-federated-identity-00"
ipr="trust200902">
<front>
<title abbrev="RBAC Identity">Federated Identity for IPv6 Role-base Access
Control</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street/>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<date/>
<area>Internet Engineering Task Force</area>
<workgroup/>
<abstract>
<t>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.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<?rfc ="5"?>
<section title="Introduction">
<t>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 <xref
target="RFC2460">IPv6</xref> 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.</t>
<t>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.</t>
<t>"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 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.</t>
<!--
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"></xref>.</t>
</section>
-->
</section>
<section anchor="sect2" title="Federated identity Option">
<t>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
<xref target="hierarchical"/>, 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.</t>
<figure anchor="hierarchical"
title="Use case: Identifying authorized communicatants in an RBAC environment">
<artwork align="center"><![CDATA[
_.----------------------.
_.----'' `------.
,--'' `---.
,-' 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 _.---' ,'
'-. `--------------------'' ,-'
`---. _.--'
`------. _.----''
`----------------------''
]]></artwork>
</figure>
<section anchor="format" title="Option Format">
<t>A number (<xref target="number"/>) 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.</t>
<figure anchor="number" title="Sample numbers">
<artwork align="center"><![CDATA[
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 |
+-+------+-+------+-+------+
]]></artwork>
</figure>
<t>The identifier {8, 987, 121393} looks like</t>
<figure anchor="identifier" title="">
<artwork align="center"><![CDATA[
+-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+
| type | len=6 |1| 8 |0| 7 |1| 91 |0| 7 |0| 52 |1| 49 |
+-------+-------+-+-----+-+-----+-+-----+-+-----+-+-----+-+-----+
]]></artwork>
</figure>
<section anchor="destopt"
title="Use in the Destination Options Header">
<t>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.</t>
</section>
<section anchor="hopbyhop" title="Use in the Hop-by-Hop Header">
<t>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.</t>
</section>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters yet. It will.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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 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.</t>
<t>Some may argue that the presence of a firewall, whether implemented
using RBAC or any other technology, fails Saltzer's <xref
target="Saltzer">End to End Arguments in System Design</xref>. 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.</t>
</section>
<section anchor="Privacy" title="Privacy Considerations">
<t>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.
<xref target="RFC6973"/> observes that <list style="empty">
<t>"...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."</t>
</list></t>
<t>In this case, the possibility is all too obvious.</t>
<t><xref target="RFC2804"/> and <xref target="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 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 <xref
target="RFC1984"/>, which was to no longer open itself to the
possibility of such a leak by escrowing the keys.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<!--
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
</references>
-->
<references title="Informative References">
<!--
<?rfc include="reference.I-D.gont-opsec-ipv6-eh-filtering" ?>
-->
<?rfc include="reference.RFC.2460"?>
<?rfc include="reference.RFC.1984" ?>
<?rfc include="reference.RFC.2804" ?>
<?rfc include="reference.RFC.6973" ?>
<?rfc include="reference.RFC.7258" ?>
<reference anchor="Saltzer">
<front>
<title>End-to-end arguments in system design</title>
<author initials="JH" surname="Saltzer">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DP" surname="Reed">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<author initials="DD" surname="Clark">
<organization>M.I.T. Laboratory for Computer
Science</organization>
</author>
<date month="Nov" year="1984"/>
</front>
<seriesInfo name="ACM Transactions on Computer Systems (TOCS)"
value="v.2 n.4, p277-288"/>
<format target="http://mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf"
type="PDF"/>
</reference>
</references>
<section anchor="log" title="Change Log">
<t><list style="hanging">
<t hangText="Initial Version:">September 2014</t>
</list></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:18:53 |