Diff: draft-ietf-rtgwg-yang-key-chain-15.txt - draft-ietf-rtgwg-yang-key-chain-16.txt

	< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/