idnits 2.17.1 draft-chen-rtg-key-table-yang-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 9, 2015) is 3333 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 334, but no explicit reference was found in the text == Unused Reference: 'I-D.acee-rtg-yang-key-chain' is defined on line 342, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-acee-rtg-yang-key-chain-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft I. Chen 3 Ericsson 4 Intended Status: Standards Track 5 Expires in 6 months March 9, 2015 7 YANG Data Model for RFC 7210 Key Table 8 10 Status of this Memo 12 Distribution of this memo is unlimited. 14 This Internet-Draft is submitted in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on date. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as 38 the document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Abstract 52 This document defines a YANG data model to describe the key table 53 defined in RFC 7210. The data model defined in this document 54 augments the existing key-chain model with additional key attributes 55 specified in RFC 7210. 57 Table of Contents 59 1. Introduction ....................................................3 60 1.1 Tree Diagram ................................................3 61 2. Design of the Data Model ........................................3 62 3. YANG Module .....................................................4 63 4. Security Considerations .........................................8 64 5. IANA Considerations .............................................8 65 6. References ......................................................8 67 1. Introduction 69 This document defines a YANG data model that supports the key table 70 described in [RFC7210]. It reuses the [key-chain] data model by 71 augmenting [key-chain] data model and adding into the [key-chain] 72 data model the attributes that are defined in [RFC7210] but not 73 currently defined in the [key-chain] data model. 75 1.1. Tree diagram 77 A simplified graphical representation of the data model is presented 78 in Section 2. 80 The meaning of the symbols in these diagrams is as follows: 82 o Brackets "[" and "]" enclose list keys. 84 o Curly braces "{" and "}" contain names of optional features that 85 make the corresponding node conditional. 87 o Abbreviations before data node names: "rw" means configuration 88 (read-write), and "ro" state data (read-only). 90 o Symbols after data node names: "?" means an optional node and "*" 91 denotes a "list" or "leaf-list". 93 o Parentheses enclose choice and case nodes, and case nodes are also 94 marked with a colon (":"). 96 o Ellipsis ("...") stands for contents of subtrees that are not 97 shown. 99 2. Design of the Data Model 101 This data model is based on the [key-chain] data model which intends 102 to manage keys by grouping a set of keys into a key-chain. A routing 103 protocol that requires authentication keys for authentication 104 purposes subsequently references a key-chain containing the keys that 105 the routing protocol intends to used for authentication. 107 To incorporate all the key attributes defined in [RFC7210] into the 108 [key-chain] data model, this data model augments the [key-chain] data 109 model by adding additional leafs into each key defined in [key- 110 chain]. 112 module: ietf-rfc7210 114 augment /kc:key-chains/kc:key: 115 +--rw admin-key-name? string {rfc7210-admin-key-name}? 116 +--rw local-key-name? string {rfc7210-local-key-name}? 117 +--rw peer-key-name? string {rfc7210-peer-key-name}? 118 +--rw peers* string {rfc-7210-peers}? 119 +--rw interfaces* string {rfc-7210-interfaces}? 120 +--rw protocol? identityref {rfc-7210-protocol}? 121 +--rw protocol-specific-info? string {rfc-7210-protocol- 122 specific-info}? 123 +--rw (kdf)? {rfc-7210-KDF}? 124 | +--:(no-kdf) 125 | | +--rw no-kdf? empty 126 | +--:(aes-128-cmac-kdf) 127 | | +--rw aes-128-cmac-kdf? empty 128 | +--:(hmac-sha-1-kdf) 129 | +--rw hmac-sha-1-kdf? empty 130 +--rw direction? enumeration {rfc-7210-direction}? 132 3. YANG Module 134 file "ietf-rfc7210.yang" 136 module ietf-rfc7210 { 137 /* replace with IANA namespace when assigned */ 138 namespace "urn:ietf:params:xml:ns:yang:ietf-rfc7210"; 139 prefix "ietf-rfc7210"; 141 import ietf-routing { 142 prefix "rt"; 143 } 145 import ietf-key-chain { 146 prefix "kc"; 147 } 149 organization 150 "Ericsson"; 152 contact 153 "I. Chen - ing-wher.chen@ericsson.com"; 155 description 156 "This YANG module augments the ietf-key-chain module by " + 157 "adding attributes defined in RFC 7210"; 158 revision 2015-03-09 { 159 description 160 "Initial revision."; 161 reference 162 "RFC XXXX: A YANG Data Model to augment ietf-key-chain " + 163 "to support RFC 7210"; 164 } 166 identity all-routing-protocols { 167 base "rt:routing-protocol"; 168 description 169 "All routing protocols"; 170 } 172 feature rfc7210-admin-key-name { 173 description 174 "Support for RFC 7210 AdminKeyName field"; 175 } 177 feature rfc7210-local-key-name { 178 description 179 "Support for RFC 7210 LocalKeyName field"; 180 } 182 feature rfc7210-peer-key-name { 183 description 184 "Support for RFC 7210 PeerKeyName field"; 185 } 187 feature rfc-7210-peers { 188 description 189 "Support for RFC 7210 Peers field"; 190 } 192 feature rfc-7210-protocol-specific-info { 193 description 194 "Support for RFC 7210 ProtocolSpecificInfo field"; 195 } 197 feature rfc-7210-interfaces { 198 description 199 "Support for RFC 7210 Interfaces field"; 201 } 203 feature rfc-7210-protocol { 204 description 205 "Support for RFC 7210 Protocol field"; 206 } 208 feature rfc-7210-KDF { 209 description 210 "Support for RFC 7210 KDF field"; 211 } 213 feature rfc-7210-direction { 214 description 215 "Support for RFC 7210 Direction field"; 216 } 218 augment "/kc:key-chains/kc:key" { 219 description 220 "Additional attributes of a key required by RFC 7210"; 222 leaf admin-key-name { 223 if-feature rfc7210-admin-key-name; 224 type string; 225 description 226 "RFC 7210 AdminKeyName field."; 227 } 228 leaf local-key-name { 229 if-feature rfc7210-local-key-name; 230 type string; 231 description 232 "RFC 7210 LocalKeyName field."; 233 } 234 leaf peer-key-name { 235 if-feature rfc7210-peer-key-name; 236 type string; 237 description 238 "RFC 7210 PeerKeyName field."; 239 } 240 leaf-list peers { 241 if-feature rfc-7210-peers; 242 type string; 243 description 244 "RFC 7210 Peers field."; 245 } 246 leaf-list interfaces { 247 if-feature rfc-7210-interfaces; 248 type string; 249 description 250 "RFC 7210 Interfaces field."; 251 } 252 leaf protocol { 253 if-feature rfc-7210-protocol; 254 type identityref { 255 base "rt:routing-protocol"; 256 } 257 default "all-routing-protocols"; 258 description 259 "RFC 7210 Protocol field."; 260 } 261 leaf protocol-specific-info { 262 if-feature rfc-7210-protocol-specific-info; 263 type string; 264 description 265 "RFC 7210 ProtocolSpecificInfo field"; 266 } 267 choice kdf { 268 if-feature rfc-7210-KDF; 269 default no-kdf; 270 description 271 "Key derivation functions."; 272 case no-kdf { 273 leaf no-kdf { 274 type empty; 275 description 276 "No KDF used with the key."; 277 } 278 } 279 case aes-128-cmac-kdf { 280 leaf aes-128-cmac-kdf { 281 type empty; 282 description 283 "AES-CMAC using 128-bit keys."; 284 } 285 } 286 case hmac-sha-1-kdf { 287 leaf hmac-sha-1-kdf { 288 type empty; 289 description 290 "HMAC using SHA-1-hash."; 291 } 292 } 293 } 294 leaf direction { 295 if-feature rfc-7210-direction; 296 type enumeration { 297 enum in { 298 description 299 "This key is for authenticating incoming messages."; 300 } 301 enum out { 302 description 303 "This key is for authenticating outgoing messages."; 304 } 305 enum both { 306 description 307 "This key is for authenticating both incoming and " + 308 "outgoing messages."; 309 } 310 } 311 default "both"; 312 description 313 "Indicate whether the key is to authenticate incoming " + 314 "or outgoing messages."; 315 } 316 } 318 } 320 322 4. Security Consideration. 324 TBD. 326 5. IANA Considerations 328 TBD. 330 6. References 332 6.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, March 1997. 337 [RFC7210] Housley, R., Polk, T., Hartman, S., and D. Zhang, 338 "Database of Long-Lived Symmetric Cryptographic Keys", RFC 339 7210, April 2014, . 342 [I-D.acee-rtg-yang-key-chain] Lindem, A., Qu, Y., Yeung, D., Chen, 343 I., Zhang, J., and Y. Yang, "Key Chain YANG Data Model", 344 draft-acee-rtg-yang-key-chain-03 (work in progress), March 345 2015. 347 Author's Address 349 I. Chen 350 Ericsson 351 Email: ing-wher.chen@ericsson.com