One document matched: draft-hares-i2rs-auth-trans-00.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ 
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4785 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4785.xml">
<!ENTITY RFC4949 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4949.xml">
<!ENTITY RFC4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY I-D.ietf-i2rs-problem SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-i2rs-pub-sub-requirements SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-pub-sub-requirements.xml">
<!ENTITY I-D.ietf-i2rs-traceabilty SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-traceability.xml">
<!ENTITY I-D.haas-i2rs-ephemeral-state-reqs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.haas-i2rs-ephemeral-state-reqs.xml">

]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
 <?rfc sortrefs="yes"?> 
 <?rfc compact="yes" ?>
 <?rfc subcompact="no" ?>  
 <?rfc iprnotified="no" ?>
  <?rfc strict="no" ?>

<rfc category="std" docName="draft-hares-i2rs-auth-trans-00"  ipr="trust200902">
<front>   
<title abbrev="I2RS Security Requirements">I2RS Security Related Requirements</title>
     <author fullname="Susan Hares" initials="S" surname="Hares">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>7453 Hickory Hill</street>
          <city>Saline</city>
          <region>MI</region>
          <code>48176</code>
          <country>USA</country>
        </postal>
        <email>shares@ndzh.com</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>
    <date year="2015" />
   <area>Routing Area</area>
   <workgroup>I2RS working group</workgroup>
    <keyword>RFC</keyword>
     <keyword>Request for Comments</keyword>
     <keyword>I-D</keyword>
     <keyword>Internet-Draft</keyword>
     <keyword>I2RS</keyword>

<abstract>
   <t> This presents an security-related requirements for the I2RS
   protocol for mutual authentication, transport protocols, 
   data transfer and transactions. 
   </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
   <t>The Interface to the Routing System (I2RS)  
   provides read and write access to the information and state within the
    routing process. The I2RS client
	interacts with one or more I2RS agents to collect information
    from network routing systems. </t>
	<t> This document describes the requirements for the
	I2RS protocol in the security-related areas of mutual authentication of the 
	I2RS client and agent, the transport protocol carrying the I2RS 
	protocol messages, and the atomicity of the transactions. 
    These requirements were initially described in the 
	<xref target="I-D.ietf-i2rs-architecture"></xref> document.  These
    security requirements are also part of the list of top ten requirements
    for the I2RS protocol indicated in the section below. </t>
	<t>
	  <xref target="I-D.haas-i2rs-ephemeral-state-reqs"></xref> discusses of I2RS roles-based write 
	  conflict resolution in the ephemeral data store using the I2RS Client Identity, I2RS Secondary Identity 
	  and priority. The draft <xref target="I-D.ietf-i2rs-traceability"></xref> describes the traceability
	  framework and its requirements for I2RS.  The draft <xref target="I-D.ietf-i2rs-pub-sub-requirements"></xref>
	  describe the requirements for I2RS to be able to publish information or have a remote client subscribe to an 
	  information data stream.  
	  </t> 
<section title="10 I2RS General Requirements">
<t>
<list style="symbols">
<t>1. The I2RS protocol SHOULD support highly reliable notifications
 (but not perfectly reliable notifications) from an I2RS agent to an  I2RS client.
</t>
<t>2. The I2RS protocol SHOULD support a high bandwidth, asynchronous interface, 
with real-time guarantees on getting data from an I2RS  agent by an I2RS client. 
</t>
<t>3. The I2RS protocol will operate on data models which may be protocol independent or protocol dependent.
</t>
<t>4. I2RS Agent needs to record the client identity when a node is created or modified. 
The I2RS Agent needs to be able to read the client identity of a node and use the
client identity's associated priority to resolve conflicts.   The secondary identity is useful for 
traceability and may also be recorded.</t>
<t>5. Client identity will have only one priority for the client identity. 
A collision on writes is considered an error, but priority is utilized to compare
requests from two different clients in order to modify an existing node entry.  
Only an entry from a client which is higher priority can modify an existing entry 
(First entry wins). Priority only has meaning at the time of use.  
</t>
<t>6. The Agent identity and the Client identity should be passed outside of the
 I2RS protocol in a authentication and authorization  protocol (AAA).  Client priority may be passed
 in the AAA protocol.  The values of identities are originally set by operators, and not  standardized.  
</t>
<t> 7.An I2RS Client and I2RS Agent mutually authenticate each other based on pre-established authenticated identities.  
</t>
<t>
8. Secondary identity data is read-only meta-data that is recorded by the I2RS agent associated with a data model's node is written, updated or deleted. Just like the primary identity, the secondary identity is only recorded when the data node is written or updated or deleted.  
</t>
<t> 9.I2RS agent can have a lower priority I2RS client attempting to 
modify a higher priority client's entry in a data model.  The filtering out of 
lower priority clients attempting to write or modify a higher priority client's entry in a 
data model SHOULD be effectively handled and not put an
undue strain on the I2RS agent. 
Note:  Jeff's suggests that priority is kept at the NACM at the client level 
(rather than the path level or the group level) will allow these lower priority clients
 to be filtered out using an extended NACM approach. This is only a suggestion of a method to provide the requirement 
 </t> 
<t>10. The I2RS protocol MUST support the use of a secure transport. 
However, certain functions such as notifications MAY use a non-secure transport.  
Each model or service (notification, logging) must define within the model or service the valid uses of a non-secure transport.
</t>
</list>
</t>
</section>
</section> 
<section title="Definitions" >
   <t>This document utilizes the definitions found in the
   following drafts:  <xref target="RFC4949"></xref>, and <xref target="I-D.ietf-i2rs-architecture"></xref>
   </t> 
  <t> Specifically, this document utilizes the following definitions:
  <list style="hanging">
	<t hangText="Authentication"><vspace blankLines="1"/>  <xref target="RFC4949" />
	 describes authentication as the process of verifying (i.e., establishing the truth of) 
	 an attribute value claimed by or for a system entity or system resource. Authentication
     has two steps: identify and verify. </t>
	<t hangText="Data Confidentiality"><vspace blankLines="1"/>  <xref target="RFC4949" />
	describes data confidentiality as having two properties: a) data is not disclosed to
	system entities unless they have been authorized to know, and b) data is not
	disclosed to unauthorized individuals, entities or processes.  The key point is that
	confidentiality implies that the originator has the ability to authorize where the 
	information goes.  Confidentiality is important for both read and write scope of the 
	data.</t>
	<t hangText="Data confidentiality service"><vspace blankLines="1"/>  <xref target="RFC4949" />
	also describes data confidentiality service as a security service that protects data 
	against unauthorized disclosure. Please note that an operator can designate 
	all people are authorized to view a piece of data which would mean a data confidentiality service 
	would be essentially a null function. </t> 
	<t hangText="Data Privacy"><vspace blankLines="1"/> <xref target="RFC4949" /> describes
	data privacy as a synonym for data confidentiality. This I2RS document will utilize
	data privacy as a synonym for data confidentiality. </t> 
	<t hangText="Mutual Authentication"><vspace blankLines="1"/>  <xref target="RFC4949" />
	 implies that mutual authentication exists between two interacting system
	 entities.  Mutual authentication in I2RS implies that both sides move from
	 a state of mutual suspicion to mutually authenticated communication afte
	 each system has been identified and validated by its peer system </t>
	 <t hangText="Mutual Suspicion"><vspace blankLines="1"/>  <xref target="RFC4949" />
	 defines mutual suspicion as a state that exists between two interacting system entities
      in which neither entity can trust the other to function correctly
      with regard to some security requirement.</t>
	<t hangText="Role"><vspace blankLines="1"/><xref target="RFC4949" /> describes
	role as a job function or employment position to which people or other system entities may be assigned
	in a system. In the I2RS interface, the I2RS agent roles relate to the roles that the I2RS client is
	utilizing. 	In the I2RS interface, the I2RS client negotiation is over the client's ability 
	to access resources made available through the agent's particular role. </t>
    <t hangText="Role-based Access control"><vspace blankLines="1"/><xref target="RFC4949" /> describes  	
	role-based access control as an identity-based access control wherein the system
      entities that are identified and controlled are functional
      positions in an organization or process.  Within <xref target="RFC4949" /> five relationships
	  are discussed: 1) administrators to assign identities to roles, 2) administrators to 
	  assign permissions to roles, 3) administrators to assign roles to roles, 
	  4) users to select identities in sessions, and 5) users to select roles in sessions. 
	  </t>
	<t hangText="Security audit trail"><vspace blankLines="1"/><xref target="RFC4949" /> (page 254) describes
	a security audit trail as a chronological record of system activities that is sufficient
      to enable the reconstruction and examination of the sequence
      environments and activities surrounding or leading to an
      operation, procedure, or event in a security-relevant transaction
      from inception to final results. Requirements to support a security audit is
      not covered in this document.  
	  The draft <xref target="I-D.ietf-i2rs-traceability"></xref> describes traceability for I2RS interface and 
	   protocol. </t>
	  <t hangText="I2RS integrity"><vspace blankLines="1" /> The data transfer as it is 
	  transmitted between client and agent cannot be modified by unauthorized parties without detection.</t>
	</list>  
	</t>
</section>
<section title="Security-Related Requirements" >
<t> The security for the I2RS protocol requires mutually authenticated I2RS client and I2RS agent
MUST be able to exchange data over a secure transport, and MUST use role-based security to
store data in I2RS data models in ephemeral state, and MUST provide atomicity of a transaction.
This section describes the requirements for the mutual authentication of the I2RS agent
and client, and the secure transport.  The issues relating to role-based security
to store data in I2RS data models in ephemeral state is covered in  
<xref target="I-D.haas-i2rs-ephemeral-state-reqs"> </xref>.  </t>
<section title="Mutual authentication of I2RS client and I2RS Agent ">  
<t>The I2RS architecture <xref target="I-D.ietf-i2rs-architecture"></xref>document states: 
<list> 
<t>
"Mutual authentication between the I2RS Client and I2RS Agent is
required. An I2RS Client must be able to trust that the I2RS
Agent is attached to the relevant Routing Element so that write/
modify operations are correctly applied and so that information
received from the I2RS Agent can be trusted by the I2RS Client."
</t>
</list></t>
<t>
This architecture set the following requirements:  
<list style="symbols">
<t> All I2RS clients and I2RS agents MUST have at least one unique identifier that uniquely identifies
each party. </t>
<t>The I2RS protocol MUST utilize these identifiers for mutual identification of
the I2RS client and I2RS agent. </t>
<t>An I2RS agent, upon receiving an I2RS message from a client, must
confirm that the client has a valid identity. </t>
<t> The client, upon receiving an I2RS
message from an agent, must confirm the I2RS identity. </t>
 <t> Identity distribution and the loading of these identities into I2RS agent
 and I2RS Client occur outside the I2RS protocol. </t>
 <t>
 The I2RS protocol SHOULD assume some mechanism (IETF or private) in order 
 to distribute or load identities  and that the I2RS client/agent will load
 the identities prior to the I2RS protocol establishing a connection 
 between I2RS client and I2RS agent. </t>
<t> Each Identity will be linked to one priority </t>
<t>Each Identity will be linked to one secondary identity for the period of a connection.</t>
</list>
</t>
</section> 
<section title="Transport Requirements Based on Mutual Authentication" >
<t> I2RS data security MUST be able to support transfer of the data
between the I2RS client to I2RS agent in a manner that is confidential, has message integrity,
and supports end-to-end integrity (in the case of stacked clients). 
</t> 
<t>
The I2RS data security mechanisms used for protecting the I2RS packets needs
to be associated with proper key management solutions. A key management solution needs
to guarantee that only the entities having sufficient privileges can get the keys to
encrypt/decrypt the sensitive data. In addition, the key management mechanisms need
to be able to update the keys before they have lost sufficient security strengths,
without breaking the connection between the agents and clients.
</t> 
<t>
The rules around what role is permitted to access and manipulate what 
information, combined with encryption to protect the data in transit 
is intended SHOULD ensure that data of any level of sensitivity is 
reasonably protected from being observed by those without permission 
to view it. In that case 'those' can refer to either other roles, 
sub-agents, or to attackers and assorted MITM (man-in-the-middle)monkeys.
</t>
<t> 
The I2RS protocol MUST support multiple transport
sessions providing protocol and data communication between the I2RS Agent
and the I2RS client. </t>
<section title="NETCONF over SSH">
<t>The NETCONF service over SSH is believed to provide the necessary
mutual authentication services required by I2RS. Per [RFC6242]: "The
identity of the SSH server MUST be verified and authenticated by the
SSH client according to local policy before password-based
authentication data or any configuration or state data is sent to or
received from the SSH server. The identity of the SSH client MUST
also be verified and authenticated by the SSH server according to
local policy to ensure that the incoming SSH client request is
legitimate before any configuration or state data is sent to or
received from the SSH client. Neither side should establish a
NETCONF over SSH connection with an unknown, unexpected, or incorrect
identity on the opposite side.</t>
</section>
<section title="NETCONF/RESTCONF over TLS">
<t>Agent validation of the I2RS client is mandated over TLS in an I2RS
context. The client shall also validate the Agent using its server
certificate.</t>
</section>
</section>
<section title="Data Confidentiality Requirements"> 
<t> In a critical infrastructure, certain data within routing elements is
sensitive and read/write operations on such data must be controlled in order to protect 
its confidentiality.  For example, most carriers do not want a router's 
configuration and data flow statistics known by hackers or their competitors.  
While carriers may share peering information, most carriers do not share 
configuration and traffic statistics. To achieve this, access control to sensitive
data needs to be provided, and the confidentiality protection on such data during
transportation needs to be enforced. 
</t> 
<t> 
It is normal to protect the confidentiality of the sensitive data during transportation
by encrypting them. Encryption obscures the data transported on the wire and protects
them against eavesdropping attacks. Because the encryption itself cannot guarantee the
integrity or fresh of data being transported, in practice, confidentiality protection
is normally provided with integrity protection. 
</t> 
</section>
<section title="Message Integrity Requirements">
<t> An integrity protection mechanism for I2RS should be able to ensure 1) the data being 
protected are not modified without detection during its transportation and 2) the data
is actually from where it is expected to come from 3) the data is not repeated from some
earlier interaction of the protocol. That is, when both confidentiality and integrity of
data is properly protected, it is possible to ensure that encrypted data are not modified
or replayed without detection.</t> 
<t> As a part of integrity protection, the replay protection approaches provided for I2RS
must consider both online and offline attackers, and have sufficient capability to deal
with intra connection and inter-connection attacks. For instance, when using symmetric keys,
sequence numbers which increase monotonically could be useful to help in distinguishing the
replayed messages, under the assistance of signatures or MACs (dependent on what types of 
keys are applied). In addition, in the cases where only offline attacker is considered,
random nonce could be effective.
</t> 
</section>
 <section title="Role-Based Data Model Security">
<t>
 The context of the I2RS client-agent communication may utilize a role which
 may/may not require message confidentiality, message integrity protection, 
 or replay attack protection. However, the I2RS Protocol MUST be able to 
 support message confidentiality, message integrity protection, and 
 replay attack protection. </t>
<t>   
 Role security for an agent involves pairing the identity to the role. 
 The data store can read information either by write or an event stream. 
 </t>
 <t> Role security MUST work when multiple transport connections are being used
 between the I2RS client and I2RS agent as the <xref target="I-D.ietf-i2rs-architecture">I2RS architecture</xref> states. 
 These transport message streams may start/stop without affecting the existence of the client/agent
 data exchange.  TCP supports a single stream of data. SCTP <xref target="RFC4960" /> provides
 security for multiple streams plus end-to-end transport of data. 
 </t> 
<t> I2RS clients may be used by multiple applications to configure routing 
 via I2RS agents, receive status reports, turn on the I2RS audit stream, or turn 
 on I2RS traceability.  An application software using I2RS client functions can host several 
 multiple secure identities, but each connection will use only one identity with one priority..
 Therefore, the security of each connection is unique. 
  </t>  
</section> 
</section>
<section title="Data Transaction Requirements"> 
<t>Each transaction should be treated as atomic and providing full
functionality. If the configuration change is not functionally
complete, then the transaction should fail and be rolled back
(rollback 0). Example, I2RS agents wants to configure BGP:
</t>
<t>
<figure> 
<artwork>

     routing-options {
          autonomous-system autonomous-system;
          }
     protocols {
        bgp {
            group group-name {
            peer-as autonomous-system;
           type type;
           neighbor address;
           }
        }
      }
</artwork>
</figure>
</t>
<t>
If a statement like neighbor address is missing or is mis-formatted,
like 300.127.5.23, configuration is not functional, transaction
should fail and rollback 0 should be performed by the I2RS agent on
the ephemeral config store. If the neighbor address is in the
transaction, but the address is not reachable or similar, transaction
is accepted, but notification will be sent that BGP peering cannot be
established.
</t>
</section>
<section anchor="Acks" title="Acknowledgement">
<t>The author would like to thank Wes George, Ahmed Abro, Qin Wu, Eric Yu, 
Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Atlas, and Jeff Haas for their
contributions to I2RS security requirement discussion, and this document.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>

 <section title="Security Considerations">
<t>This is a document about security architecture beyond the consideration for I2RS.
 Additional security definitions will be added in this section. </t>
</section>
  
</middle>  
<back>
<references title="Normative References">
   &RFC2119;
</references>
<references title="Informative References">
   &RFC4785;
   &RFC4949;
   &RFC4960;
   &I-D.ietf-i2rs-problem;
   &I-D.ietf-i2rs-architecture;
   &I-D.ietf-i2rs-rib-info-model; 
   &I-D.haas-i2rs-ephemeral-state-reqs;
   &I-D.ietf-i2rs-traceabilty;
   &I-D.ietf-i2rs-pub-sub-requirements; 
   </references>
  
</back>
</rfc>