draft-ietf-i2rs-protocol-security-requirements-04.txt   draft-ietf-i2rs-protocol-security-requirements-05.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track D. Migault Intended status: Informational D. Migault
Expires: November 6, 2016 J. Halpern Expires: November 21, 2016 J. Halpern
Ericsson Ericsson
May 5, 2016 May 20, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-04 draft-ietf-i2rs-protocol-security-requirements-05
Abstract Abstract
This presents security-related requirements for the I2RS protocol for This presents security-related requirements for the I2RS protocol for
mutual authentication, transport protocols, data transfer and mutual authentication, transport protocols, data transfer and
transactions. transactions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 6, 2016. This Internet-Draft will expire on November 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3 2.1. Security Definitions . . . . . . . . . . . . . . . . . . 3
2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 6 2.2. I2RS Specific Definitions . . . . . . . . . . . . . . . . 6
3. Security-Related Requirements . . . . . . . . . . . . . . . . 7 3. Security-Related Requirements . . . . . . . . . . . . . . . . 7
3.1. Mutual authentication of an I2RS client and an I2RS Agent 8 3.1. Mutual authentication of an I2RS client and an I2RS Agent 8
3.2. Transport Requirements Based on Mutual Authentication . . 8 3.2. Transport Requirements Based on Mutual Authentication . . 9
3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10 3.3. Data Confidentiality Requirements . . . . . . . . . . . . 10
3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10 3.4. Data Integrity Requirements . . . . . . . . . . . . . . . 10
3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11 3.5. Role-Based Data Model Security . . . . . . . . . . . . . 11
3.6. Security of the environment . . . . . . . . . . . . . . . 11 3.6. Security of the environment . . . . . . . . . . . . . . . 12
4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 4. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The Interface to the Routing System (I2RS) provides read and write The Interface to the Routing System (I2RS) provides read and write
access to information and state within the routing process. An I2RS access to information and state within the routing process. An I2RS
client interacts with one or more I2RS agents to collect information client interacts with one or more I2RS agents to collect information
from network routing systems. from network routing systems.
This document describes the requirements for the I2RS protocol in the This document describes the requirements for the I2RS protocol in the
skipping to change at page 7, line 14 skipping to change at page 7, line 14
I2RS transaction I2RS transaction
is a unit of I2RS functionality. Some examples of I2RS is a unit of I2RS functionality. Some examples of I2RS
transactions are: transactions are:
* The I2RS client issues a read request to a I2RS agent, and the * The I2RS client issues a read request to a I2RS agent, and the
I2RS Agent responding to the read request I2RS Agent responding to the read request
* The I2RS client issues a write of ephemeral configuration * The I2RS client issues a write of ephemeral configuration
values into an I2RS agent'sbr data model, followed by the I2RS values into an I2RS agent's data model, followed by the I2RS
agent response to the write. agent response to the write.
* An I2RS client may issue an action request, the I2RS agent * An I2RS client may issue an action request, the I2RS agent
responds to the action-request, and then responds when action responds to the action-request, and then responds when action
is complete. Actions can be single step processes or multiple is complete. Actions can be single step processes or multiple
step process. step process.
* An I2RS client requests to receive an event notification, and * An I2RS client requests to receive an event notification, and
the I2RS Agent sets up to send the events. the I2RS Agent sets up to send the events.
skipping to change at page 8, line 5 skipping to change at page 7, line 51
The security for the I2RS protocol requires mutually authenticated The security for the I2RS protocol requires mutually authenticated
I2RS clients and I2RS agents. The I2RS client and I2RS agent using I2RS clients and I2RS agents. The I2RS client and I2RS agent using
the I2RS protocol MUST be able to exchange data over a secure the I2RS protocol MUST be able to exchange data over a secure
transport, but some functions may operate on a non-secure transport. transport, but some functions may operate on a non-secure transport.
The I2RS protocol MUST be able to provide atomicity of an I2RS The I2RS protocol MUST be able to provide atomicity of an I2RS
transaction, but it is not required to have multi-message atomicity transaction, but it is not required to have multi-message atomicity
and roll-back mechanism transactions. Multiple messages transactions and roll-back mechanism transactions. Multiple messages transactions
may be impacted by the interdependency of data. This section may be impacted by the interdependency of data. This section
discusses the details of these security requirements. discusses the details of these security requirements.
There are dependencies in some of the requirements below. For
confidentiality (section 3.3) and integrity (section 3.4) to be
achieved, the client-agent must have mutual authentication (section
3.1) and secure transport (section 3.2). I2RS allows the use of an
insecure transport for portions of data models that clearly indicate
insecure transport. If insecure transport is used, then
confidentiality and integrity cannot be achieved.
3.1. Mutual authentication of an I2RS client and an I2RS Agent 3.1. Mutual authentication of an I2RS client and an I2RS Agent
The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following
requirements: requirements:
o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an o SEC-REQ-01: All I2RS clients and I2RS agents MUST have an
identity, and at least one unique identifier that uniquely identity, and at least one unique identifier that uniquely
identifies each party in the I2RS protocol context. identifies each party in the I2RS protocol context.
o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for o SEC-REQ-02: The I2RS protocol MUST utilize these identifiers for
skipping to change at page 10, line 37 skipping to change at page 10, line 42
3) the data is not repeated from some earlier interaction of the 3) the data is not repeated from some earlier interaction of the
protocol. (That is, when both confidentiality and integrity of protocol. (That is, when both confidentiality and integrity of
data is properly protected, it is possible to ensure that data is properly protected, it is possible to ensure that
encrypted data is not modified or replayed without detection.) encrypted data is not modified or replayed without detection.)
SEC-REQ-15: The integrity that the message data is not repeated means SEC-REQ-15: The integrity that the message data is not repeated means
that I2RS client to I2RS agent transport SHOULD protect against that I2RS client to I2RS agent transport SHOULD protect against
replay attack replay attack
Requirements SEC-REQ-13 and SEC-REQ-14 are SHOULD requirements only Requirements SEC-REQ-14 and SEC-REQ-16 are SHOULD requirements only
because it is recognized that some I2RS Client to I2RS agent because it is recognized that some I2RS Client to I2RS agent
communication occurs over a non-secure channel. The I2RS client to communication occurs over a non-secure channel. The I2RS client to
I2RS agent over a secure channel would implement these features. In I2RS agent over a secure channel would implement these features. In
order to provide some traceability or notification for the non-secure order to provide some traceability or notification for the non-secure
protocol, SEC-REQ-16 suggests traceability and notification are protocol, SEC-REQ-16 suggests traceability and notification are
important to include for any non-secure protocol. important to include for any non-secure protocol.
SEC-REQ-16: The I2RS message traceability and notification SEC-REQ-16: The I2RS message traceability and notification
requirements requirements found in [I-D.ietf-i2rs-traceability] and requirements requirements found in [I-D.ietf-i2rs-traceability] and
[I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in [I-D.ietf-i2rs-pub-sub-requirements] SHOULD be supported in
communication channel that is non-secure to trace or notify about communication channel that is non-secure to trace or notify about
potential security issues. potential security issues.
3.5. Role-Based Data Model Security 3.5. Role-Based Data Model Security
The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or The I2RS Architecture [I-D.ietf-i2rs-architecture] defines a role or
security role as specifying read, write, or notification access by a security role as specifying read, write, or notification access by a
I2RS client to data within an agent's data model. I2RS client to data within an agent's data model.
skipping to change at page 12, line 35 skipping to change at page 12, line 41
[I-D.ietf-i2rs-architecture] [I-D.ietf-i2rs-architecture]
Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", draft-ietf-i2rs-architecture-15 (work in System", draft-ietf-i2rs-architecture-15 (work in
progress), April 2016. progress), April 2016.
[I-D.ietf-i2rs-problem-statement] [I-D.ietf-i2rs-problem-statement]
Atlas, A., Nadeau, T., and D. Ward, "Interface to the Atlas, A., Nadeau, T., and D. Ward, "Interface to the
Routing System Problem Statement", draft-ietf-i2rs- Routing System Problem Statement", draft-ietf-i2rs-
problem-statement-10 (work in progress), February 2016. problem-statement-11 (work in progress), May 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic
Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107,
June 2005, <http://www.rfc-editor.org/info/rfc4107>. June 2005, <http://www.rfc-editor.org/info/rfc4107>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-i2rs-ephemeral-state] [I-D.ietf-i2rs-ephemeral-state]
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-05 (work in Requirements", draft-ietf-i2rs-ephemeral-state-06 (work in
progress), March 2016. progress), May 2016.
[I-D.ietf-i2rs-pub-sub-requirements] [I-D.ietf-i2rs-pub-sub-requirements]
Voit, E., Clemm, A., and A. Prieto, "Requirements for Voit, E., Clemm, A., and A. Prieto, "Requirements for
Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub- Subscription to YANG Datastores", draft-ietf-i2rs-pub-sub-
requirements-07 (work in progress), May 2016. requirements-09 (work in progress), May 2016.
[I-D.ietf-i2rs-security-environment-reqs] [I-D.ietf-i2rs-security-environment-reqs]
Migault, D., Halpern, J., and S. Hares, "I2RS Environment Migault, D., Halpern, J., and S. Hares, "I2RS Environment
Security Requirements", draft-ietf-i2rs-security- Security Requirements", draft-ietf-i2rs-security-
environment-reqs-01 (work in progress), April 2016. environment-reqs-01 (work in progress), April 2016.
[I-D.ietf-i2rs-traceability] [I-D.ietf-i2rs-traceability]
Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to Clarke, J., Salgueiro, G., and C. Pignataro, "Interface to
the Routing System (I2RS) Traceability: Framework and the Routing System (I2RS) Traceability: Framework and
Information Model", draft-ietf-i2rs-traceability-09 (work Information Model", draft-ietf-i2rs-traceability-11 (work
in progress), May 2016. in progress), May 2016.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007,
<http://www.rfc-editor.org/info/rfc4949>. <http://www.rfc-editor.org/info/rfc4949>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007, RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>. <http://www.rfc-editor.org/info/rfc4960>.
 End of changes. 15 change blocks. 
15 lines changed or deleted 24 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/