draft-ietf-i2rs-protocol-security-requirements-10.txt   draft-ietf-i2rs-protocol-security-requirements-11.txt 
I2RS working group S. Hares I2RS working group S. Hares
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational D. Migault Intended status: Informational D. Migault
Expires: March 12, 2017 J. Halpern Expires: March 19, 2017 J. Halpern
Ericsson Ericsson
September 8, 2016 September 15, 2016
I2RS Security Related Requirements I2RS Security Related Requirements
draft-ietf-i2rs-protocol-security-requirements-10 draft-ietf-i2rs-protocol-security-requirements-11
Abstract Abstract
This presents security-related requirements for the I2RS protocol This presents security-related requirements for the I2RS protocol
which provides a new interface to the routing system described in the which provides a new interface to the routing system described in the
I2RS architecture document (RFC7921). The I2RS protocol is a re-use I2RS architecture document (RFC7921). The I2RS protocol is a re-use
protocol implemented by re-using portions of existing IETF protocols protocol implemented by re-using portions of existing IETF protocols
and adding new features to these protocols. The I2RS protocol re- and adding new features to these protocols. The I2RS protocol re-
uses security features of a secure transport (E.g. TLS, SSH, DTLS) uses security features of a secure transport (E.g. TLS, SSH, DTLS)
such as encryption, message integrity, mutual peer authentication, such as encryption, message integrity, mutual peer authentication,
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 March 12, 2017. This Internet-Draft will expire on March 19, 2017.
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 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5 2.2. Security Definitions . . . . . . . . . . . . . . . . . . 5
2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5 2.3. I2RS Specific Definitions . . . . . . . . . . . . . . . . 5
3. Security Features and Protocols: Re-used and New . . . . . . 7 3. Security Features and Protocols: Re-used and New . . . . . . 7
3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7 3.1. Security Protocols Re-Used by the I2RS Protocol . . . . . 7
3.2. New Security Features . . . . . . . . . . . . . . . . . . 8 3.2. New Features Related to Security . . . . . . . . . . . . 8
3.3. I2RS Protocol Security Requirements vs. IETF Management 3.3. I2RS Protocol Security Requirements vs. IETF Management
Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9 Protocols . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security-Related Requirements . . . . . . . . . . . . . . . . 10 4. Security-Related Requirements . . . . . . . . . . . . . . . . 10
4.1. I2RS Peers(agent and client) Identity Authentication . . 11 4.1. I2RS Peers(agent and client) Identity Authentication . . 11
4.2. Identity Validation Before Role-Based Message Actions . . 12 4.2. Identity Validation Before Role-Based Message Actions . . 12
4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12 4.3. Peer Identity, Priority, and Client Redundancy . . . . . 12
4.4. Multi-Channel Transport: Secure Transport and Insecure 4.4. Multi-Channel Transport: Secure Transport and Insecure
Transport . . . . . . . . . . . . . . . . . . . . . . . . 14 Transport . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Management Protocol Security . . . . . . . . . . . . . . 16 4.5. Management Protocol Security . . . . . . . . . . . . . . 16
4.6. Role-Based Data Model Security . . . . . . . . . . . . . 17 4.6. Role-Based Data Model Security . . . . . . . . . . . . . 17
skipping to change at page 8, line 13 skipping to change at page 8, line 13
utilized for the I2RS protocols SHOULD support automatic rotation. utilized for the I2RS protocols SHOULD support automatic rotation.
An I2RS implementer may use AAA protocols over secure transport to An I2RS implementer may use AAA protocols over secure transport to
distribute the identities for I2RS client and I2RS agent and role distribute the identities for I2RS client and I2RS agent and role
authorization information. Two AAA protocols are: Diameter [RFC6733] authorization information. Two AAA protocols are: Diameter [RFC6733]
and Radius [RFC2865]. To provide the best security I2RS peer and Radius [RFC2865]. To provide the best security I2RS peer
identities, the AAA protocols MUST be run over a secure transport identities, the AAA protocols MUST be run over a secure transport
(Diameter over secure transport (TLS over TCP) [RFC6733]), Radius (Diameter over secure transport (TLS over TCP) [RFC6733]), Radius
over a secure transport (TLS) [RFC6614]). over a secure transport (TLS) [RFC6614]).
3.2. New Security Features 3.2. New Features Related to Security
The new features are priority, an opaque secondary identifier, and an The new features are priority, an opaque secondary identifier, and an
insecure protocol for read-only data constrained to specific standard insecure protocol for read-only data constrained to specific standard
usages. The I2RS protocol allows multi-headed control by several usages. The I2RS protocol allows multi-headed control by several
I2RS clients. This multi-headed control is based on the assumption I2RS clients. This multi-headed control is based on the assumption
that the operator deploying the I2RS clients, I2RS agents, and the that the operator deploying the I2RS clients, I2RS agents, and the
I2rs protocol will coordinate the read, write, and notification scope I2rs protocol will coordinate the read, write, and notification scope
so the I2RS clients will not contend for the same write scope. so the I2RS clients will not contend for the same write scope.
However, just in case there is an unforseen overlap of I2RS clients However, just in case there is an unforseen overlap of I2RS clients
attempting to write a particular piece of data, the I2RS architecture attempting to write a particular piece of data, the I2RS architecture
skipping to change at page 17, line 13 skipping to change at page 17, line 13
protection on such data during transportation needs to be enforced. protection on such data during transportation needs to be enforced.
Integrity of data is important even if the I2RS protocol is sending Integrity of data is important even if the I2RS protocol is sending
non-confidential data over an insecure connection. The ability to non-confidential data over an insecure connection. The ability to
trace I2RS protocol messages that enact I2RS transactions provides a trace I2RS protocol messages that enact I2RS transactions provides a
minimal aid to helping operators check how messages enact minimal aid to helping operators check how messages enact
transactions on a secure or insecure transport. transactions on a secure or insecure transport.
4.6. Role-Based Data Model Security 4.6. Role-Based Data Model Security
The I2RS Architecture [RFC7921] defines a role or security role as The I2RS Architecture [RFC7921] specifies access control by "role"
specifying read, write, or notification access by a I2RS client to where role is a method of making access control more manageable by
data within an agent's data model. creating a grouping of users so that access control can be specified
for a role rather than for each of the individuals. Therefore, I2RS
role specifies the access control for a group as being read, write,
or notification.
SEC-REQ-19: The rules around what I2RS security role is permitted SEC-REQ-19: The rules around what I2RS security role is permitted
to access and manipulate what information over a secure transport to access and manipulate what information over a secure transport
(which protects the data in transit) SHOULD ensure that data of (which protects the data in transit) SHOULD ensure that data of
any level of sensitivity is reasonably protected from being any level of sensitivity is reasonably protected from being
observed by those without permission to view it, so that privacy observed by those without permission to view it, so that privacy
requirements are met. requirements are met.
SEC-REQ-20: Role security MUST work when multiple transport SEC-REQ-20: Role security MUST work when multiple transport
connections are being used between the I2RS client and I2RS agent connections are being used between the I2RS client and I2RS agent
skipping to change at page 18, line 33 skipping to change at page 18, line 35
6. IANA Considerations 6. IANA Considerations
This draft is requirements, and does not request anything of IANA. This draft is requirements, and does not request anything of IANA.
7. Acknowledgement 7. Acknowledgement
The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric The authors would like to thank Wes George, Ahmed Abro, Qin Wu, Eric
Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia Yu, Joel Halpern, Scott Brim, Nancy Cam-Winget, DaCheng Zhang, Alia
Atlas, and Jeff Haas for their contributions to the I2RS security Atlas, and Jeff Haas for their contributions to the I2RS security
requirements discussion and this document. The authors would like to requirements discussion and this document. The authors would like to
thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Alvaro thank Bob Moskowitz, Kathleen Moriarty, Stephen Farrell, Radia
Retana, Ben Campbell, and Alissa Cooper for their review of these Perlman, Alvaro Retana, Ben Campbell, and Alissa Cooper for their
requirements. review of these requirements.
8. References 8. References
8.1. Normative References 8.1. Normative References
[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.
skipping to change at page 19, line 45 skipping to change at page 19, line 45
Haas, J. and S. Hares, "I2RS Ephemeral State Haas, J. and S. Hares, "I2RS Ephemeral State
Requirements", draft-ietf-i2rs-ephemeral-state-16 (work in Requirements", draft-ietf-i2rs-ephemeral-state-16 (work in
progress), August 2016. progress), August 2016.
[I-D.ietf-netconf-restconf] [I-D.ietf-netconf-restconf]
Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", draft-ietf-netconf-restconf-16 (work in Protocol", draft-ietf-netconf-restconf-16 (work in
progress), August 2016. progress), August 2016.
[I-D.ietf-taps-transports] [I-D.ietf-taps-transports]
Fairhurst, G., Trammell, B., and M. Kuehlewind, "Services Fairhurst, G., Trammell, B., and M. KĂźhlewind,
provided by IETF transport protocols and congestion "Services provided by IETF transport protocols and
control mechanisms", draft-ietf-taps-transports-11 (work congestion control mechanisms", draft-ietf-taps-
in progress), July 2016. transports-11 (work in progress), July 2016.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", "Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, DOI 10.17487/RFC2865, June 2000, RFC 2865, DOI 10.17487/RFC2865, June 2000,
<http://www.rfc-editor.org/info/rfc2865>. <http://www.rfc-editor.org/info/rfc2865>.
[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. 9 change blocks. 
16 lines changed or deleted 19 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/