Subject: Draft submission: NETCONF access control framework

From: Vincent Cridlig <[email-masked]>
Date: Tue, 07 Nov 2006 16:45:41 +0100

Hi,

Please find the joint file draft-cridlig-netconf-rbac.txt. Any comments 
are welcome.

I implemented this proposition in our Netconf agent prototype in Python 
so it should be feasable in acceptable time also in other languages 
and/or plateforms.

Here is a set of comments to open discussion:

1- The proposition is very strict with the default operation in 
edit-config, because it is hard to anticipate what will be done exactly 
without seeing the configuration data.

2- notify ("n") privilege could be easily added, and would allow to 
filter the data sent in notifications in the same way as get-config 
replies. As I am not very confident with the notification draft, I 
prefer to omit notifications for now.

3- It is possible to extend the proposition with function-centric 
approach, but still with more complexity and the possibility to 
introduce inconsistencies: I was thinking of something like that:
<permission op="w">
    <method name="create-vlan">
    <scope>/foo/bar/vlan</scope>
    <scope>/foo/bar/if</scope>
</permission>
Some parameters may be added as variables:
<permission op="w">
    <method name="create-vlan">
       <param>ifname</param>
    </method>
    <scope>/foo/bar/vlan</scope>
    <scope>/foo/bar/if[name=$ifname]</scope>
</permission>
It describes the data involved in the function context.

4- For more security, the login/password and login/public-key tuples 
should be stored in a certificate instead of within the policy. This is 
to make sure that the proprietary of the public-key is really the 
identity described by the login (using a third-party). Also the password 
should be a hash of the password.

5- I can send some links to the most famous RBAC papers if needed.

Regards,
Vincent Cridlig

Network Working Group                                         V. Cridlig
Internet-Draft                                          November 7, 2006
Intended status: Standards Track
Expires: May 11, 2007

                    NETCONF access control framework
                     draft-cridlig-netconf-rbac.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 11, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Cridlig                   Expires May 11, 2007                  [Page 1]

Internet-Draft      NETCONF access control framework       November 2006

Abstract

   This document defines a role-based access control framework for the
   NETCONF configuration protocol.

Table of Contents

   1.  Requirements notation  . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  General overview . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Role-Based Access Control in NETCONF . . . . . . . . . . .  4
   3.  RBAC-related operations  . . . . . . . . . . . . . . . . . . .  6
     3.1.  Activating a role  . . . . . . . . . . . . . . . . . . . .  6
     3.2.  Deactivating a role  . . . . . . . . . . . . . . . . . . .  7
     3.3.  Role (de)activation typical use case . . . . . . . . . . .  7
   4.  RBAC policy data model . . . . . . . . . . . . . . . . . . . .  9
     4.1.  RBAC components definition . . . . . . . . . . . . . . . .  9
     4.2.  RBAC policy example  . . . . . . . . . . . . . . . . . . . 10
     4.3.  XML schema for RBAC  . . . . . . . . . . . . . . . . . . . 12
     4.4.  Updating the RBAC policy . . . . . . . . . . . . . . . . . 15
   5.  Consequences on existing operations  . . . . . . . . . . . . . 16
     5.1.  get and get-config operations  . . . . . . . . . . . . . . 16
     5.2.  edit-config operation  . . . . . . . . . . . . . . . . . . 16
     5.3.  copy-config operations . . . . . . . . . . . . . . . . . . 17
     5.4.  delete-config operations . . . . . . . . . . . . . . . . . 17
   6.  (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping  . . . . . . . 18
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 20
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21
   Intellectual Property and Copyright Statements . . . . . . . . . . 22

Cridlig                   Expires May 11, 2007                  [Page 2]

Internet-Draft      NETCONF access control framework       November 2006

1.  Requirements notation

   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 [RFC2119].

Cridlig                   Expires May 11, 2007                  [Page 3]

Internet-Draft      NETCONF access control framework       November 2006

2.  Introduction

2.1.  General overview

   The current document defines an access control framework for NETCONF.
   This framework relies on the Role-Based Access Control (RBAC) model
   and intends to protect NETCONF manager access to resources.  The
   access control process intentionally removes the underlying protocol
   options from the decisions.  In particular, it does not depend on
   whether the underlying protocol is BEEP, SSH or SOAP.  It assumes
   that this protocol is secure by especially providing authentication,
   integrity and confidentiality.  This choice was made because it is
   not reasonable to have one access control policy for each of this
   protocol and for each of their internal options or security services.
   Another design choice is that each NETCONF agent stores its own
   access control policy like in VACM.  Consequently, the RBAC policy
   remains customizable for each NETCONF agent in order to fulfill all
   requirements and scenarii.

   A NETCONF agent has one instance of the RBAC policy that applies to
   all the supported datastores (running, candidate, startup).

2.2.  Role-Based Access Control in NETCONF

   The RBAC model has many advantages over the other access control
   models.  In particular, it is scalable in terms of maintainability
   even with a huge number of users.  RBAC helps to organize the
   permissions into higher level job functions called roles.  As an
   example in the NETCONF context, a role can be a firewall management
   role, a security management role, a routing management role.  Roles
   can be specialized in a hierarchy.  For example, the security
   management role can be a senior role of the firewall management role
   and therefore, inherits the permissions of this junior role (firewall
   management role).  In the context of this document, an RBAC user is a
   NETCONF manager.  The latter can be assigned to one or several roles.
   RBAC is fairly well adapted to Netconf because it includes the
   concept of session, within which permissions can be activated
   dynamically.  An RBAC session is mapped to a NETCONF session.

   The NETCONF agent stores an RBAC policy, containing the user, role
   and permission definitions and their assignements.

Cridlig                   Expires May 11, 2007                  [Page 4]

Internet-Draft      NETCONF access control framework       November 2006

   Role-Based Access Control model

                          hierarchy
                            ----
                           |    |
      |----------|      |----------|      |----------|
      |   User   |------|   Role   |------|Permission|
      |----------|      |----------|      |----------|
               \          /
                \        /
               |----------|
               | Session  |
               |----------|

                                 Figure 1

   This RBAC policy MAY be stored in an XML file and MAY be part of the
   agent data model.  Therefore the RBAC policy MAY be manageable
   through NETCONF itself, as it is for VACM in SNMPv3.  This allows a
   large-scale deployement of the access control policy.  This document
   defines a XML-based data model to store the RBAC policy.

   The specified model and the involved new operations defined in the
   current document are covered by a new capability:
   "urn:ietf:params:xml:ns:netconf:rbac:1.0", abbreviated as "#rbac" in
   the rest of the document.

Cridlig                   Expires May 11, 2007                  [Page 5]

Internet-Draft      NETCONF access control framework       November 2006

3.  RBAC-related operations

   In the dynamic RBAC model, roles must be activated at run time.
   Indeed, the permissions of an RBAC user are not constantly available.
   An RBAC user has to activate a role to be granted the related
   permissions.  This decreases misconfiguration risks since only a
   subset of the configuration data is accessible at a given time.
   However, this subset can be the whole configuration datastore if the
   role allows it.  Two operations are necessary to allow role
   activation and deactivation.  These operations are sent by the
   manager to the agent and are wrapped into an <rbac> operation.  The
   <rbac> operation is a direct child of the NETCONF <rpc> operation.

3.1.  Activating a role

   <activate-role>

      Description:

         Activating a role allows a user to be granted the permissions
         related to this role in the current NETCONF session.  This
         operation can happen at any time after the hello exchange is
         done.  The manager sends an activate-role operation containing
         a specified role name to the agent.  The agent checks its local
         RBAC policy to decide whether the user can activate this role
         or not.  In order to activate a role, a user MUST be assigned
         to this role and the role must be enabled.  An enabled role is
         a role that can be activated.

      Parameters:

         Role name:

            The name of the role to be activated.

      Positive Response:

         If the user is assigned to the requested role, and the role is
         not activated yet in the current session, then the agent sends
         an <rpc-reply> containing an <ok> element.

      Negative Response:

         An <rpc-error> element is included within the <rpc-reply> if
         the request cannot be completed for any reason.  A role
         activation will fail if the user is not assigned to the
         requested role, or if the role is already activated or if any
         other constraint prevents the user from activating the role.

Cridlig                   Expires May 11, 2007                  [Page 6]

Internet-Draft      NETCONF access control framework       November 2006

3.2.  Deactivating a role

   <deactivate-role>

      Description:

         Deactivating a role allows a user to revoke the permissions
         related to this role in the current NETCONF session.  This
         operation can happen at any time after the hello exchange is
         done.  The manager sends a deactivate-role operation containing
         a specified role name to the agent.  The agent checks its local
         RBAC policy to decide whether the user can deactivate this role
         or not.

      Parameters:

         Role name:

            The name of the role to deactivate.

      Positive Response:

         If the role was activated in the current session, then the
         agent sends an <rpc-reply> containing an <ok> element.

      Negative Response:

         An <rpc-error> element is included within the <rpc-reply> if
         the request cannot be completed for any reason.  A role
         deactivation will fail if the user had not activate the role
         previously in the session.

3.3.  Role (de)activation typical use case

Cridlig                   Expires May 11, 2007                  [Page 7]

Internet-Draft      NETCONF access control framework       November 2006

   Role (de)activation process:

         Manager                        Agent
           |                              |
           |        <hello> exchange      |
           |<---------------------------->|
           |                              |
           |                              |
           |    <(de)activate-role>       |
           |----------------------------->|
           |                              |  check policy   -----------
           |                              |<--------------->| database |
           |          <ok/>               |                 -----------
           |<-----------------------------|
           |                              |
           |                              |

                                 Figure 2

   When a NETCONF session is terminated (for example, after a <close-
   session> or a <kill-session>), then all active roles MUST be
   deactivated within the current session.

   When a NETCONF session is started (after the hello exchange), then a
   set of default roles MAY be activated by default on a per-user base,
   without requiring the <activate-role> operation.  This default
   activation on Netconf session startup saves some messages and avoid
   the need of a user activity.  The set of roles activated by default
   MAY be chosen by the manager.

Cridlig                   Expires May 11, 2007                  [Page 8]

Internet-Draft      NETCONF access control framework       November 2006

4.  RBAC policy data model

   This section defines an XML-based data model representing an RBAC
   policy.  It specifies the main components of RBAC: users, roles and
   permissions.  Sessions are not part of the saved data model, since it
   is the dynamic part of RBAC.  Sessions state (activated and
   deactivated roles) always remains in memory.

4.1.  RBAC components definition

   The following items list the components of the RBAC model and their
   internal relationships (assignments):

      User: A user consists of the following attributes:

         login: the name of the user.

         password: the password of the user.

         public-key: the public key of the user.

      Role: A role consists of the following attributes:

         name: the name of the current role.

         junior-roles: a set of junior roles of the current role.

      Permission: A permission consists of the following parameters:

         scope: a representation of the protected resource, typically a
         MIB name (could be an XPath expression for more granularity).
         <scope> is a child of <permission>

         operation: read (r), write (w) or notify (n).

      Permission-to-Role Assignement (pra):

         permRef: reference to a permission.

         roleRef: reference to a role.

      User-to-Role Assignement (ura):

         userRef: reference to a user.

         roleRef: reference to a role.

Cridlig                   Expires May 11, 2007                  [Page 9]

Internet-Draft      NETCONF access control framework       November 2006

4.2.  RBAC policy example

   This example consists of 5 roles.  RoutingManager role has read
   access to the routing configuration.  InteriorRoutingManager and
   ExteriorRoutingManager roles inherit the privileges of
   RoutingManager.  InteriorRoutingManager can also write on OSPF and
   RIP configurations.  ExteriorRoutingManager can write on BGP
   configuration.  SuperRoutingManager inherits all previous roles and
   can write on all routing configurations.  SuperManager has full
   privileges on all the configuration.

   RBAC policy example

  <?xml version="1.0" encoding="UTF-8"?>
  <rbac xmlns="urn:loria:madynes:ensuite:yencap:module:RBAC:1.0">
    <prefixes>
      <prefix name="ycp"
              value="urn:loria:madynes:ensuite:yencap:1.0"/>
      <prefix name="bgp"
              value="urn:loria:madynes:ensuite:yencap:module:BGP:1.0"/>
      <prefix name="rip"
              value="urn:loria:madynes:ensuite:yencap:module:RIP:1.0"/>
      <prefix name="ospf"
              value="urn:loria:madynes:ensuite:yencap:module:OSPF:1.0"/>
      <prefix name="ac"
              value="urn:loria:madynes:ensuite:yencap:module:RBAC:1.0"/>
    </prefixes>

    <users>
      <user id="4">
        <login>netconf</login>
        <password>netconf</password>
        <public-key keytype="rsa">AAAAB3NzaC1yc2E...
                ...50RfDJ6M=</public-key>
      </user>
    </users>

    <roles>
      <role id="1">
        <name>RoutingManager</name>
      </role>
      <role id="2">
        <name>InteriorRoutingManager</name>
        <junior-roles>
          <junior-role roleRef="1"/>
        </junior-roles>
      </role>
      <role id="3">

Cridlig                   Expires May 11, 2007                 [Page 10]

Internet-Draft      NETCONF access control framework       November 2006

        <name>ExteriorRoutingManager</name>
        <junior-roles>
          <junior-role roleRef="1"/>
        </junior-roles>
      </role>
      <role id="5">
        <name>SuperRoutingManager</name>
        <junior-roles>
          <junior-role roleRef="2"/>
          <junior-role roleRef="3"/>
          <junior-role roleRef="4"/>
        </junior-roles>
      </role>
      <role id="6">
        <name>SuperManager</name>
        <junior-roles>
          <junior-role roleRef="5"/>
        </junior-roles>
      </role>
    </roles>

    <permissions>
      <permission id="1" op="r">
        <scope>/ycp:netconf/ycp:routing</scope>
      </permission>
      <permission id="2" op="w">
        <scope>/ycp:netconf/ycp:routing/bgp:bgp</scope>
      </permission>
      <permission id="3" op="w">
        <scope>/ycp:netconf/ycp:routing/rip:rip</scope>
      </permission>
      <permission id="4" op="w">
        <scope>/ycp:netconf/ycp:routing/ospf:ospf</scope>
      </permission>
      <permission id="5" op="w">
        <scope>/ycp:netconf/ycp:routing</scope>
      </permission>
      <permission id="6" op="rw">
        <scope>/ycp:netconf</scope>
      </permission>
      <permission id="7" op="w">
        <scope>/ycp:netconf/ycp:routing/ospf:ospf</scope>
      </permission>
    </permissions>

    <uras>
      <ura roleRef="5" userRef="4"/>
      <ura roleRef="6" userRef="4"/>

Cridlig                   Expires May 11, 2007                 [Page 11]

Internet-Draft      NETCONF access control framework       November 2006

    </uras>

    <pras>
      <pra roleRef="1" permRef="1"/>
      <pra roleRef="2" permRef="3"/>
      <pra roleRef="2" permRef="4"/>
      <pra roleRef="3" permRef="2"/>
      <pra roleRef="5" permRef="5"/>
      <pra roleRef="6" permRef="6"/>
    </pras>
  </rbac>

                                 Figure 3

4.3.  XML schema for RBAC

   Here is the XML schema for the RBAC policy.

   RBAC XML Schema

<xs:schema
  targetNamespace="urn:madynes:params:xml:ns:netconf:rbac:1.0"
  elementFormDefault="qualified"
  attributeFormDefault="unqualified"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  xmlns="urn:madynes:params:xml:ns:netconf:rbac:1.0">

  <xs:element name="rbac" type="rbacType"/>

  <xs:complexType name="prefixesType">
    <xs:sequence>
      <xs:element name="prefix" type="prefixType" minOccurs="0"
                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="prefixType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="name" type="xs:string" use="required"/>
        <xs:attribute name="value" type="xs:string" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:complexType name="userType">
    <xs:sequence>

Cridlig                   Expires May 11, 2007                 [Page 12]

Internet-Draft      NETCONF access control framework       November 2006

      <xs:element name="login" type="xs:string"/>
      <xs:element name="password" type="xs:string"/>
      <xs:element name="public-key" type="public-keyType"
                     minOccurs="0"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:integer"/>
  </xs:complexType>

  <xs:complexType name="public-keyType">
    <xs:simpleContent>
      <xs:extension base="xs:string">
        <xs:attribute name="keytype" type="keytypeType" use="required"/>
      </xs:extension>
    </xs:simpleContent>
  </xs:complexType>

  <xs:simpleType name="keytypeType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="rsa"/>
      <xs:enumeration value="dsa"/>
    </xs:restriction>
  </xs:simpleType>

  <xs:complexType name="roleType">
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="junior-roles" type="junior-rolesType"/>
    </xs:sequence>
    <xs:attribute name="id" type="xs:integer"/>
  </xs:complexType>

  <xs:complexType name="usersType">
    <xs:sequence>
      <xs:element name="user" type="userType" minOccurs="0"
                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="rolesType">
    <xs:sequence>
      <xs:element name="role" type="roleType" minOccurs="0"
                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="permissionsType">
    <xs:sequence>
      <xs:element name="permission" type="permissionType" minOccurs="0"

Cridlig                   Expires May 11, 2007                 [Page 13]

Internet-Draft      NETCONF access control framework       November 2006

                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="permissionType">
    <xs:sequence>
      <xs:element name="scope" type="xs:string"/>
    </xs:sequence>
    <xs:attribute name="op">
      <xs:simpleType>
        <xs:restriction base="xs:string">
          <xs:enumeration value="r"/>
          <xs:enumeration value="w"/>
          <xs:enumeration value="rw"/>
        </xs:restriction>
      </xs:simpleType>
    </xs:attribute>
    <xs:attribute name="id" type="xs:integer"/>
  </xs:complexType>

  <xs:complexType name="urasType">
    <xs:sequence>
      <xs:element name="ura" type="uraType" minOccurs="0"
                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="uraType">
    <xs:attribute name="userRef" type="xs:string"/>
    <xs:attribute name="roleRef" type="xs:string"/>
  </xs:complexType>

  <xs:complexType name="prasType">
    <xs:sequence>
      <xs:element name="pra" type="praType" minOccurs="0"
                     maxOccurs="unbounded"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="praType">
    <xs:attribute name="permissionRef" type="xs:string"/>
    <xs:attribute name="roleRef" type="xs:string"/>
  </xs:complexType>

  <xs:complexType name="rbacType">
    <xs:sequence>
      <xs:element name="prefixes" type="prefixesType"/>
      <xs:element name="users" type="usersType"/>

Cridlig                   Expires May 11, 2007                 [Page 14]

Internet-Draft      NETCONF access control framework       November 2006

      <xs:element name="roles" type="rolesType"/>
      <xs:element name="permissions" type="permissionsType"/>
      <xs:element name="uras" type="urasType"/>
      <xs:element name="pras" type="prasType"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="junior-rolesType">
    <xs:sequence>
      <xs:element name="junior-role" type="junior-roleType"
                     minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="junior-roleType">
    <xs:attribute name="roleRef" type="xs:string"/>
  </xs:complexType>

</xs:schema>

                                 Figure 4

4.4.  Updating the RBAC policy

   Whenever an update is done in the RBAC policy, it MUST be immediately
   applied to the current NETCONF sessions.

   A user can be removed if and only if it does not appear in any user-
   to-role assignement.  A permission can be removed if and only if it
   does not appear in any permission-to-role assignement.  A role can be
   removed if and only if it does not appear in any permission-to-role
   and user-to-role assignement.

   If a user is removed from the policy, all its current NETCONF
   sessions must be killed.  If a user-to-role assignement is removed
   from the policy, this role must be deactivated in all sessions
   belonging to this user where this role is active.  If a permission-
   to-role assignement is removed, the permission MUST be removed from
   the set of active permissions in all NETCONF sessions having this
   role or one of its senior role activated.  If a permission-to-role
   assignement is created, the permission must be activated in every
   session where the related role or one of its senior role is active.

Cridlig                   Expires May 11, 2007                 [Page 15]

Internet-Draft      NETCONF access control framework       November 2006

5.  Consequences on existing operations

   The #rbac capability does not require any change to the formats of
   existing NETCONF operations.  However, an additional processing is
   required on the agent side when it receives some request.  In all
   cases, the agent MUST consider the active roles within the current
   session.  These active roles relate to permissions expressed as a
   tuple (operation, scope).  From the set of active permissions, the
   agent is able to build the corresponding sets of authorized scopes
   for read "r" and write "w" operations.  Scopes are expressed as XPath
   expressions.

5.1.  get and get-config operations

   When processing a get or get-config operation, some changes are
   required due to the RBAC policy enforcement.  After or before
   applying the subtree filtering (or XPath) request to the desired
   configuration, an additional processing MUST take place to apply the
   RBAC policy.  It consists of selecting the allowed XML nodes and
   pruning the others depending on the currently active roles.

   All children and parents of the selected nodes are marked as
   authorized nodes.  While the propagation to the top nodes is
   necessary to keep the structure of the document, the propagation to
   the children is a consequence of the subtree-based access control
   arbitrary choice.  It is more scalable to select subtrees rather than
   individual nodes in the access control policy.  Only positive
   authorizations are allowed in order to avoid conflicts and to
   constraint the security manager to explicitely give access to
   resources, all remaining resource being unauthorized by default.  All
   nodes marked as authorized are kept in the XML reply.  All other
   nodes are pruned.

5.2.  edit-config operation

   As for the get/get-config, when a NETCONF manager is authorized to
   write on an XML node, she is also allowed to modify the whole subtree
   whose root is this XML node.  On receipt of an edit-config request,
   the agent applies the XPath expressions of the write "w" permissions
   set on the request.  All children and parents of the selected nodes
   are marked as authorized nodes.  If a "replace", "create", "delete",
   or "merge" operation is set in one of the parents of the selected
   nodes, access is denied.  This requires to set the operation
   attribute as close as possible to the node to update.

Cridlig                   Expires May 11, 2007                 [Page 16]

Internet-Draft      NETCONF access control framework       November 2006

5.3.  copy-config operations

   To perform a copy-config operation, a NETCONF manager MUST have write
   "w" access on the root node of the configuration datastore.

5.4.  delete-config operations

   To perform a delete-config operation, a NETCONF manager MUST have
   write "w" access on the root node of the configuration datastore.

Cridlig                   Expires May 11, 2007                 [Page 17]

Internet-Draft      NETCONF access control framework       November 2006

6.  (SSH, BEEP, SOAP/SSL)-user to RBAC-user mapping

   The SSH user name is directly mapped to the RBAC user name, whatever
   is the authentication method (password or public/private key).

Cridlig                   Expires May 11, 2007                 [Page 18]

Internet-Draft      NETCONF access control framework       November 2006

7.  Security Considerations

   None.

Cridlig                   Expires May 11, 2007                 [Page 19]

Internet-Draft      NETCONF access control framework       November 2006

8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Cridlig                   Expires May 11, 2007                 [Page 20]

Internet-Draft      NETCONF access control framework       November 2006

Author's Address

   Vincent Cridlig

Cridlig                   Expires May 11, 2007                 [Page 21]

Internet-Draft      NETCONF access control framework       November 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Cridlig                   Expires May 11, 2007                 [Page 22]