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]