draft-ietf-rtgwg-yang-key-chain-15.txt   draft-ietf-rtgwg-yang-key-chain-16.txt 
Network Working Group A. Lindem, Ed. Network Working Group A. Lindem, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track Y. Qu Intended status: Standards Track Y. Qu
Expires: August 20, 2017 Huawei Expires: September 28, 2017 Huawei
D. Yeung D. Yeung
Arrcus, Inc Arrcus, Inc
I. Chen I. Chen
Jabil Jabil
J. Zhang J. Zhang
Juniper Networks Juniper Networks
Y. Yang March 27, 2017
SockRate
February 16, 2017
Routing Key Chain YANG Data Model Routing Key Chain YANG Data Model
draft-ietf-rtgwg-yang-key-chain-15.txt draft-ietf-rtgwg-yang-key-chain-16.txt
Abstract Abstract
This document describes the key chain YANG data model. A key chain This document describes the key chain YANG data model. Key chains
is a list of elements each containing a key string, send lifetime, are commonly used for routing protocol authentication and other
accept lifetime, and algorithm (authentication or encryption). By applications requiring symmetric keys. A key chain is a list of
properly overlapping the send and accept lifetimes of multiple key elements each containing a key string, send lifetime, accept
chain elements, key strings and algorithms may be gracefully updated. lifetime, and algorithm (authentication or encryption). By properly
By representing them in a YANG data model, key distribution can be overlapping the send and accept lifetimes of multiple key chain
automated. Key chains are commonly used for routing protocol elements, key strings and algorithms may be gracefully updated. By
authentication and other applications. In some applications, the representing them in a YANG data model, key distribution can be
protocols do not use the key chain element key directly, but rather a automated.
key derivation function is used to derive a short-lived key from the
key chain element key (e.g., the Master Keys used in the TCP In some applications, the protocols do not use the key chain element
Authentication Option. key directly, but rather a key derivation function is used to derive
a short-lived key from the key chain element key (e.g., the Master
Keys used in the TCP Authentication Option(TCP-AO)).
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 20, 2017. This Internet-Draft will expire on September 28, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4 2.2. Graceful Key Rollover using Key Chains . . . . . . . . . 4
3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5 3. Design of the Key Chain Model . . . . . . . . . . . . . . . . 5
3.1. Key Chain Operational State . . . . . . . . . . . . . . . 5 3.1. Key Chain Operational State . . . . . . . . . . . . . . . 6
3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6 3.2. Key Chain Model Features . . . . . . . . . . . . . . . . 6
3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6 3.3. Key Chain Model Tree . . . . . . . . . . . . . . . . . . 6
4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 9 4. Key Chain YANG Model . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.2. Informative References . . . . . . . . . . . . . . . . . 19 8.1. Normative References . . . . . . . . . . . . . . . . . . 19
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 20
A.1. Simple Key Chain with Always Valid Single Key . . . . . . 20 A.1. Simple Key Chain with Always Valid Single Key . . . . . . 20
A.2. Key Chain with Keys having Different Lifetimes . . . . . 21 A.2. Key Chain with Keys having Different Lifetimes . . . . . 21
A.3. Key Chain with Independent Send and Accept Lifetimes . . 22 A.3. Key Chain with Independent Send and Accept Lifetimes . . 23
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 23 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document describes the key chain YANG data model. A key chain This document describes the key chain YANG [YANG] data model. Key
is a list of elements each containing a key string, send lifetime, chains are commonly used for routing protocol authentication and
accept lifetime, and algorithm (authentication or encryption). By other applications requiring symmetric keys. A key chain is a list
properly overlapping the send and accept lifetimes of multiple key of elements each containing a key string, send lifetime, accept
chain elements, key strings and algorithms may be gracefully updated. lifetime, and algorithm (authentication or encryption). By properly
By representing them in a YANG data model, key distribution can be overlapping the send and accept lifetimes of multiple key chain
automated. Key chains are commonly used for routing protocol elements, key strings and algorithms may be gracefully updated. By
authentication and other applications. In some applications, the representing them in a YANG data model, key distribution can be
protocols do not use the key chain element key string directly, but automated.
rather a key derivation function is used to derive a short-lived key
from the key chain element key string (e.g., the Master Keys used in In some applications, the protocols do not use the key chain element
[TCP-AO]). key directly, but rather a key derivation function is used to derive
a short-lived key from the key chain element key (e.g., the Master
Keys used in [TCP-AO]).
1.1. Requirements Notation 1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC-KEYWORDS]. [RFC-KEYWORDS].
1.2. Tree Diagrams 1.2. Tree Diagrams
skipping to change at page 19, line 5 skipping to change at page 19, line 5
Registrant Contact: The IESG. Registrant Contact: The IESG.
XML: N/A, the requested URI is an XML namespace. XML: N/A, the requested URI is an XML namespace.
This document registers a YANG module in the YANG Module Names This document registers a YANG module in the YANG Module Names
registry [YANG]. registry [YANG].
name: ietf-key-chain namespace: urn:ietf:params:xml:ns:yang:ietf- name: ietf-key-chain namespace: urn:ietf:params:xml:ns:yang:ietf-
key-chain prefix: ietf-key-chain reference: RFC XXXX key-chain prefix: ietf-key-chain reference: RFC XXXX
7. References 7. Contributors
7.1. Normative References Contributors' Addresses
Yi Yang
SockRate
Email: yi.yang@sockrate.com
8. References
8.1. Normative References
[NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [NETCONF] Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
Bierman, "Network Configuration Protocol (NETCONF)", RFC Bierman, "Network Configuration Protocol (NETCONF)", RFC
6241, June 2011. 6241, June 2011.
[NETCONF-ACM] [NETCONF-ACM]
Bierman, A. and M. Bjorklund, "Network Configuration Bierman, A. and M. Bjorklund, "Network Configuration
Protocol (NETCONF) Access Control Model", RFC 6536, March Protocol (NETCONF) Access Control Model", RFC 6536, March
2012. 2012.
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFC's to Indicate Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[XML-REGISTRY] [XML-REGISTRY]
Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[YANG] Bjorklund, M., "YANG - A Data Modeling Language for the [YANG] Bjorklund, M., "The YANG 1.1 Data Modeling Language", RFC
Network Configuration Protocol (NETCONF)", RFC 6020, 7950, August 2016.
October 2010.
7.2. Informative References 8.2. Informative References
[AES-KEY-WRAP] [AES-KEY-WRAP]
Housley, R. and M. Dworkin, "Advanced Encryption Standard Housley, R. and M. Dworkin, "Advanced Encryption Standard
(AES) Key Wrap with Padding Algorithm", RFC 5649, August (AES) Key Wrap with Padding Algorithm", RFC 5649, August
2009. 2009.
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, June 2010. (BFD)", RFC 5880, June 2010.
[CRYPTO-KEYTABLE] [CRYPTO-KEYTABLE]
skipping to change at page 23, line 18 skipping to change at page 24, line 18
Thanks to Brian Weis for fruitful discussions on security Thanks to Brian Weis for fruitful discussions on security
requirements. requirements.
Thanks to Ines Robles for Routing Directorate QA review comments. Thanks to Ines Robles for Routing Directorate QA review comments.
Thanks to Ladislav Lhotka for YANG Doctor comments. Thanks to Ladislav Lhotka for YANG Doctor comments.
Thanks to Martin Bjorklund for additional YANG Doctor comments. Thanks to Martin Bjorklund for additional YANG Doctor comments.
Thanks to Tom Petch for comments during IETF last call.
Authors' Addresses Authors' Addresses
Acee Lindem (editor) Acee Lindem (editor)
Cisco Systems Cisco Systems
301 Midenhall Way 301 Midenhall Way
Cary, NC 27513 Cary, NC 27513
USA USA
Email: acee@cisco.com Email: acee@cisco.com
skipping to change at page 24, line 11 skipping to change at line 1109
Jabil Jabil
Email: ing-wher_chen@jabil.com Email: ing-wher_chen@jabil.com
Jeffrey Zhang Jeffrey Zhang
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: zzhang@juniper.net Email: zzhang@juniper.net
Yi Yang
SockRate
Email: yi.yang@sockrate.com
 End of changes. 16 change blocks. 
44 lines changed or deleted 57 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/