idnits 2.17.1
draft-ietf-netconf-tls-client-server-19.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 :
----------------------------------------------------------------------------
** The abstract seems to contain references ([2], [3], [4], [5], [6], [7],
[8], [9], [1]), which it shouldn't. Please replace those with straight
textual mentions of the documents in question.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (May 20, 2020) is 1437 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)
-- Looks like a reference, but probably isn't: '1' on line 2035
-- Looks like a reference, but probably isn't: '2' on line 2037
-- Looks like a reference, but probably isn't: '3' on line 2039
-- Looks like a reference, but probably isn't: '4' on line 2041
-- Looks like a reference, but probably isn't: '5' on line 2043
-- Looks like a reference, but probably isn't: '6' on line 2045
-- Looks like a reference, but probably isn't: '7' on line 2047
-- Looks like a reference, but probably isn't: '8' on line 2049
-- Looks like a reference, but probably isn't: '9' on line 2052
== Outdated reference: A later version (-34) exists of
draft-ietf-netconf-crypto-types-14
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-16
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-09
-- Obsolete informational reference (is this intentional?): RFC 2246
(Obsoleted by RFC 4346)
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 4346
(Obsoleted by RFC 5246)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 14 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Watsen Networks
4 Intended status: Standards Track G. Wu
5 Expires: November 21, 2020 Cisco Systems
6 May 20, 2020
8 YANG Groupings for TLS Clients and TLS Servers
9 draft-ietf-netconf-tls-client-server-19
11 Abstract
13 This document defines three YANG modules: the first defines groupings
14 for a generic TLS client, the second defines groupings for a generic
15 TLS server, and the third defines common identities and groupings
16 used by both the client and the server. It is intended that these
17 groupings will be used by applications using the TLS protocol.
19 Editorial Note (To be removed by RFC Editor)
21 This draft contains placeholder values that need to be replaced with
22 finalized values at the time of publication. This note summarizes
23 all of the substitutions that are needed. No other RFC Editor
24 instructions are specified elsewhere in this document.
26 Artwork in this document contains shorthand references to drafts in
27 progress. Please apply the following replacements:
29 o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto-
30 types
32 o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust-
33 anchors
35 o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore
37 o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp-
38 client-server
40 o "FFFF" --> the assigned RFC value for this draft
42 Artwork in this document contains placeholder values for the date of
43 publication of this draft. Please apply the following replacement:
45 o "2020-05-20" --> the publication date of this draft
47 The following Appendix section is to be removed prior to publication:
49 o Appendix A. Change Log
51 Note to Reviewers (To be removed by RFC Editor)
53 This document presents a YANG module or modules that is/are part of a
54 collection of drafts that work together to produce the ultimate goal
55 of the NETCONF WG: to define configuration modules for NETCONF client
56 and servers, and RESTCONF client and servers.
58 The relationship between the various drafts in the collection is
59 presented in the below diagram.
61 crypto-types
62 ^ ^
63 / \
64 / \
65 trust-anchors keystore
66 ^ ^ ^ ^
67 | +---------+ | |
68 | | | |
69 | +------------+ |
70 tcp-client-server | / | |
71 ^ ^ ssh-client-server | |
72 | | ^ tls-client-server
73 | | | ^ ^ http-client-server
74 | | | | | ^
75 | | | +-----+ +---------+ |
76 | | | | | |
77 | +-----------|--------|--------------+ | |
78 | | | | | |
79 +-----------+ | | | | |
80 | | | | | |
81 | | | | | |
82 netconf-client-server restconf-client-server
84 Full draft names and link to drafts:
86 o draft-ietf-netconf-crypto-types (html [1])
88 o draft-ietf-netconf-trust-anchors (html [2])
90 o draft-ietf-netconf-keystore (html [3])
92 o draft-ietf-netconf-tcp-client-server (html [4])
94 o draft-ietf-netconf-ssh-client-server (html [5])
95 o draft-ietf-netconf-tls-client-server (html [6])
97 o draft-ietf-netconf-http-client-server (html [7])
99 o draft-ietf-netconf-netconf-client-server (html [8])
101 o draft-ietf-netconf-restconf-client-server (html [9])
103 Status of This Memo
105 This Internet-Draft is submitted in full conformance with the
106 provisions of BCP 78 and BCP 79.
108 Internet-Drafts are working documents of the Internet Engineering
109 Task Force (IETF). Note that other groups may also distribute
110 working documents as Internet-Drafts. The list of current Internet-
111 Drafts is at https://datatracker.ietf.org/drafts/current/.
113 Internet-Drafts are draft documents valid for a maximum of six months
114 and may be updated, replaced, or obsoleted by other documents at any
115 time. It is inappropriate to use Internet-Drafts as reference
116 material or to cite them other than as "work in progress."
118 This Internet-Draft will expire on November 21, 2020.
120 Copyright Notice
122 Copyright (c) 2020 IETF Trust and the persons identified as the
123 document authors. All rights reserved.
125 This document is subject to BCP 78 and the IETF Trust's Legal
126 Provisions Relating to IETF Documents
127 (https://trustee.ietf.org/license-info) in effect on the date of
128 publication of this document. Please review these documents
129 carefully, as they describe your rights and restrictions with respect
130 to this document. Code Components extracted from this document must
131 include Simplified BSD License text as described in Section 4.e of
132 the Trust Legal Provisions and are provided without warranty as
133 described in the Simplified BSD License.
135 Table of Contents
137 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
138 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
139 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 5
140 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5
141 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 6
142 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 10
144 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 17
145 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 17
146 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 18
147 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 22
148 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 29
149 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 30
150 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 31
151 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 31
152 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40
153 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
154 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 41
155 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 42
156 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
157 8.1. Normative References . . . . . . . . . . . . . . . . . . 42
158 8.2. Informative References . . . . . . . . . . . . . . . . . 44
159 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
160 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 46
161 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 46
162 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 46
163 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 46
164 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 46
165 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 47
166 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 47
167 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 47
168 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 47
169 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 47
170 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 47
171 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 48
172 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 48
173 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 48
174 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 48
175 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 49
176 A.16. 14 to 15 . . . . . . . . . . . . . . . . . . . . . . . . 49
177 A.17. 15 to 16 . . . . . . . . . . . . . . . . . . . . . . . . 49
178 A.18. 16 to 17 . . . . . . . . . . . . . . . . . . . . . . . . 49
179 A.19. 17 to 18 . . . . . . . . . . . . . . . . . . . . . . . . 49
180 A.20. 18 to 19 . . . . . . . . . . . . . . . . . . . . . . . . 50
181 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50
182 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
184 1. Introduction
186 This document defines three YANG 1.1 [RFC7950] modules: the first
187 defines a grouping for a generic TLS client, the second defines a
188 grouping for a generic TLS server, and the third defines identities
189 and groupings common to both the client and the server (TLS is
190 defined in [RFC5246]). It is intended that these groupings will be
191 used by applications using the TLS protocol. For instance, these
192 groupings could be used to help define the data model for an HTTPS
193 [RFC2818] server or a NETCONF over TLS [RFC7589] based server.
195 The client and server YANG modules in this document each define one
196 grouping, which is focused on just TLS-specific configuration, and
197 specifically avoids any transport-level configuration, such as what
198 ports to listen-on or connect-to. This affords applications the
199 opportunity to define their own strategy for how the underlying TCP
200 connection is established. For instance, applications supporting
201 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping"
202 grouping for the TLS parts it provides, while adding data nodes for
203 the TCP-level call-home configuration.
205 2. Terminology
207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
209 "OPTIONAL" in this document are to be interpreted as described in BCP
210 14 [RFC2119] [RFC8174] when, and only when, they appear in all
211 capitals, as shown here.
213 3. The TLS Client Model
215 3.1. Tree Diagram
217 This section provides a tree diagram [RFC8340] for the "ietf-tls-
218 client" module that does not have groupings expanded.
220 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
222 module: ietf-tls-client
224 grouping tls-client-grouping
225 +-- client-identity
226 | +-- (auth-type)?
227 | +--:(certificate) {x509-certificate-auth}?
228 | | +-- certificate
229 | | +---u ks:local-or-keystore-end-entity-cert-with-key-\
230 grouping
231 | +--:(raw-public-key) {raw-public-key-auth}?
232 | | +-- raw-private-key
233 | | +---u ks:local-or-keystore-asymmetric-key-grouping
234 | +--:(psk) {psk-auth}?
235 | +-- psk
236 | +---u ks:local-or-keystore-symmetric-key-grouping
237 +-- server-authentication
238 | +-- ca-certs! {x509-certificate-auth}?
239 | | +---u ts:local-or-truststore-certs-grouping
240 | +-- ee-certs! {x509-certificate-auth}?
241 | | +---u ts:local-or-truststore-certs-grouping
242 | +-- raw-public-keys! {raw-public-key-auth}?
243 | | +---u ts:local-or-truststore-public-keys-grouping
244 | +-- psks! {psk-auth}?
245 +-- hello-params {tls-client-hello-params-config}?
246 | +---u tlscmn:hello-params-grouping
247 +-- keepalives {tls-client-keepalives}?
248 +-- peer-allowed-to-send? empty
249 +-- test-peer-aliveness!
250 +-- max-wait? uint16
251 +-- max-attempts? uint8
253 3.2. Example Usage
255 This section presents two examples showing the "tls-client-grouping"
256 grouping populated with some data. These examples are effectively
257 the same except the first configures the client identity using a
258 local key while the second uses a key configured in a keystore. Both
259 examples are consistent with the examples presented in Section 2 of
260 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
261 [I-D.ietf-netconf-keystore].
263 The following example configures the client identity using a local
264 key:
266 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
267
271
272
273
274
275 ct:subject-public-key-info-format
277 base64encodedvalue==
278 ct:rsa-private-key-format
280 base64encodedvalue==
281 base64encodedvalue==
282
283
284
302
304
305
306
307
308 base64encodedvalue==
309 base64encodedvalue==
310 base64encodedvalue==
311
312
313
314
315 base64encodedvalue==
316 base64encodedvalue==
317 base64encodedvalue==
318
319
320
321
322
323 corp-fw1
324 ct:subject-public-key-info-format
326 base64encodedvalue==
327
328
329 corp-fw1
330 ct:subject-public-key-info-format
332 base64encodedvalue==
333
334
335
336
337
339
340
341 30
342 3
343
344
346
348 The following example configures the client identity using a key from
349 the keystore:
351 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
353
355
356
357
358
359 rsa-asymmetric-key
360 ex-rsa-cert
361
362
363
372
374
375
376
377 trusted-server-ca-certs
379
380
381 trusted-server-ee-certs
383
384
385 Raw Public Keys for TLS Servers
387
388
389
391
392
393 30
394 3
395
396
398
400 3.3. YANG Module
402 This YANG module has normative references to
403 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
405 file "ietf-tls-client@2020-05-20.yang"
407 module ietf-tls-client {
408 yang-version 1.1;
409 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
410 prefix tlsc;
412 import ietf-netconf-acm {
413 prefix nacm;
414 reference
415 "RFC 8341: Network Configuration Access Control Model";
416 }
418 import ietf-crypto-types {
419 prefix ct;
420 reference
421 "RFC AAAA: Common YANG Data Types for Cryptography";
422 }
424 import ietf-truststore {
425 prefix ts;
426 reference
427 "RFC BBBB: A YANG Data Model for a Truststore";
428 }
430 import ietf-keystore {
431 prefix ks;
432 reference
433 "RFC CCCC: A YANG Data Model for a Keystore";
434 }
436 import ietf-tls-common {
437 prefix tlscmn;
438 revision-date 2020-05-20; // stable grouping definitions
439 reference
440 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
441 }
443 organization
444 "IETF NETCONF (Network Configuration) Working Group";
446 contact
447 "WG Web:
448 WG List:
449 Author: Kent Watsen
450 Author: Gary Wu ";
452 description
453 "This module defines reusable groupings for TLS clients that
454 can be used as a basis for specific TLS client instances.
456 Copyright (c) 2020 IETF Trust and the persons identified
457 as authors of the code. All rights reserved.
459 Redistribution and use in source and binary forms, with
460 or without modification, is permitted pursuant to, and
461 subject to the license terms contained in, the Simplified
462 BSD License set forth in Section 4.c of the IETF Trust's
463 Legal Provisions Relating to IETF Documents
464 (https://trustee.ietf.org/license-info).
466 This version of this YANG module is part of RFC FFFF
467 (https://www.rfc-editor.org/info/rfcFFFF); see the RFC
468 itself for full legal notices.
470 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
471 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
472 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
473 are to be interpreted as described in BCP 14 (RFC 2119)
474 (RFC 8174) when, and only when, they appear in all
475 capitals, as shown here.";
477 revision 2020-05-20 {
478 description
479 "Initial version";
480 reference
481 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
482 }
484 // Features
486 feature tls-client-hello-params-config {
487 description
488 "TLS hello message parameters are configurable on a TLS
489 client.";
490 }
492 feature tls-client-keepalives {
493 description
494 "Per socket TLS keepalive parameters are configurable for
495 TLS clients on the server implementing this feature.";
497 }
499 feature x509-certificate-auth {
500 description
501 "Indicates that the client supports authenticating servers
502 using X.509 certificates.";
503 }
505 feature raw-public-key-auth {
506 description
507 "Indicates that the client supports authenticating servers
508 using ray public keys.";
509 }
511 feature psk-auth {
512 description
513 "Indicates that the client supports authenticating servers
514 using PSKs (pre-shared or pairwise-symmetric keys).";
515 }
517 // Groupings
519 grouping tls-client-grouping {
520 description
521 "A reusable grouping for configuring a TLS client without
522 any consideration for how an underlying TCP session is
523 established.
525 Note that this grouping uses fairly typical descendent
526 node names such that a stack of 'uses' statements will
527 have name conflicts. It is intended that the consuming
528 data model will resolve the issue (e.g., by wrapping
529 the 'uses' statement in a container called
530 'tls-client-parameters'). This model purposely does
531 not do this itself so as to provide maximum flexibility
532 to consuming models.";
534 container client-identity {
535 nacm:default-deny-write;
536 description
537 "Identity credentials the TLS client MAY present when
538 establishing a connection to a TLS server. If not
539 configured, then client authentication is presumed to
540 occur a protocol layer above TLS. When configured,
541 and requested by the TLS server when establishing a
542 TLS session, these credentials are passed in the
543 Certificate message defined in Section 7.4.2 of
544 RFC 5246.";
545 reference
546 "RFC 5246: The Transport Layer Security (TLS) Protocol
547 Version 1.2
548 RFC CCCC: A YANG Data Model for a Keystore";
549 choice auth-type {
550 description
551 "A choice amongst available authentication types.";
552 case certificate {
553 if-feature x509-certificate-auth;
554 container certificate {
555 description
556 "Specifies the client identity using a certificate.";
557 uses
558 ks:local-or-keystore-end-entity-cert-with-key-grouping{
559 refine "local-or-keystore/local/local-definition" {
560 must 'public-key-format'
561 + ' = "ct:subject-public-key-info-format"';
562 }
563 refine "local-or-keystore/keystore/keystore-reference"
564 + "/asymmetric-key" {
565 must 'deref(.)/../ks:public-key-format'
566 + ' = "ct:subject-public-key-info-format"';
567 }
568 }
569 }
570 }
571 case raw-public-key {
572 if-feature raw-public-key-auth;
573 container raw-private-key {
574 description
575 "Specifies the client identity using a raw
576 private key.";
577 uses ks:local-or-keystore-asymmetric-key-grouping {
578 refine "local-or-keystore/local/local-definition" {
579 must 'public-key-format'
580 + ' = "ct:subject-public-key-info-format"';
581 }
582 refine "local-or-keystore/keystore"
583 + "/keystore-reference" {
584 must 'deref(.)/../ks:public-key-format'
585 + ' = "ct:subject-public-key-info-format"';
586 }
587 }
588 }
589 }
590 case psk {
591 if-feature psk-auth;
592 container psk {
593 description
594 "Specifies the client identity using a PSK (pre-shared
595 or pairwise-symmetric key). Note that, when the PSK is
596 configured as a Keystore reference, the key's 'name'
597 node MAY be used as the PSK's ID when used by the TLS
598 protocol.";
599 uses ks:local-or-keystore-symmetric-key-grouping {
600 augment "local-or-keystore/local/local-definition" {
601 if-feature "ks:local-definitions-supported";
602 description
603 "Adds an 'id' value when the PSK is used by TLS.";
604 leaf id {
605 type string; // FIXME: is this the right type?
606 description
607 "The key id used in the TLS protocol for PSKs.";
608 }
609 }
610 }
611 }
612 }
613 }
614 } // container client-identity
616 container server-authentication {
617 nacm:default-deny-write;
618 must 'ca-certs or server-certs';
619 description
620 "Specifies how the TLS client can authenticate TLS servers.
621 Any combination of credentials is additive and unordered.
623 Note that no configuration is required for PSK (pre-shared
624 or pairwise-symmetric key) based authentication as the key
625 is necessarily the same as configured in the '../client-
626 identity' node.";
627 container ca-certs {
628 if-feature "x509-certificate-auth";
629 presence
630 "Indicates that the TLS client can authenticate TLS servers
631 using configured certificate authority certificates.";
632 description
633 "A set of certificate authority (CA) certificates used by
634 the TLS client to authenticate TLS server certificates.
635 A server certificate is authenticated if it has a valid
636 chain of trust to a configured CA certificate.";
637 reference
638 "RFC BBBB: A YANG Data Model for a Truststore";
640 uses ts:local-or-truststore-certs-grouping;
641 }
642 container ee-certs { // FIXME: plural too much?
643 if-feature "x509-certificate-auth";
644 presence
645 "Indicates that the TLS client can authenticate TLS
646 servers using configured server certificates.";
647 description
648 "A set of server certificates (i.e., end entity
649 certificates) used by the TLS client to authenticate
650 certificates presented by TLS servers. A server
651 certificate is authenticated if it is an exact
652 match to a configured server certificate.";
653 reference
654 "RFC BBBB: A YANG Data Model for a Truststore";
655 uses ts:local-or-truststore-certs-grouping;
656 }
657 container raw-public-keys {
658 if-feature "raw-public-key-auth";
659 presence
660 "Indicates that the TLS client can authenticate TLS
661 servers using configured server certificates.";
662 description
663 "A set of raw public keys used by the TLS client to
664 authenticate raw public keys presented by the TLS
665 server. A raw public key is authenticated if it
666 is an exact match to a configured raw public key.";
667 reference
668 "RFC BBBB: A YANG Data Model for a Truststore";
669 uses ts:local-or-truststore-public-keys-grouping {
670 refine "local-or-truststore/local/local-definition"
671 + "/public-key" {
672 must 'public-key-format'
673 + ' = "ct:subject-public-key-info-format"';
674 }
675 refine "local-or-truststore/truststore"
676 + "/truststore-reference" {
677 must 'deref(.)/../*/ts:public-key-format'
678 + ' = "ct:subject-public-key-info-format"';
679 }
680 }
681 }
682 container psks {
683 if-feature "psk-auth";
684 presence
685 "Indicates that the TLS client can authenticate TLS servers
686 using a configure PSK (pre-shared or pairwise-symmetric
687 key).";
689 description
690 "No configuration is required since the PSK value is the
691 same as PSK value configured in the 'client-identity'
692 node.";
693 }
694 } // container server-authentication
696 container hello-params {
697 nacm:default-deny-write;
698 if-feature "tls-client-hello-params-config";
699 uses tlscmn:hello-params-grouping;
700 description
701 "Configurable parameters for the TLS hello message.";
702 } // container hello-params
704 container keepalives {
705 nacm:default-deny-write;
706 if-feature "tls-client-keepalives";
707 description
708 "Configures the keepalive policy for the TLS client.";
709 leaf peer-allowed-to-send {
710 type empty;
711 description
712 "Indicates that the remote TLS server is allowed to send
713 HeartbeatRequest messages, as defined by RFC 6520
714 to this TLS client.";
715 reference
716 "RFC 6520: Transport Layer Security (TLS) and Datagram
717 Transport Layer Security (DTLS) Heartbeat Extension";
718 }
719 container test-peer-aliveness {
720 presence
721 "Indicates that the TLS client proactively tests the
722 aliveness of the remote TLS server.";
723 description
724 "Configures the keep-alive policy to proactively test
725 the aliveness of the TLS server. An unresponsive
726 TLS server is dropped after approximately max-wait
727 * max-attempts seconds. The TLS client MUST send
728 HeartbeatRequest messages, as defined by RFC 6520.";
729 reference
730 "RFC 6520: Transport Layer Security (TLS) and Datagram
731 Transport Layer Security (DTLS) Heartbeat Extension";
732 leaf max-wait {
733 type uint16 {
734 range "1..max";
735 }
736 units "seconds";
737 default "30";
738 description
739 "Sets the amount of time in seconds after which if
740 no data has been received from the TLS server, a
741 TLS-level message will be sent to test the
742 aliveness of the TLS server.";
743 }
744 leaf max-attempts {
745 type uint8;
746 default "3";
747 description
748 "Sets the maximum number of sequential keep-alive
749 messages that can fail to obtain a response from
750 the TLS server before assuming the TLS server is
751 no longer alive.";
752 }
753 }
754 }
755 } // grouping tls-client-grouping
756 } // module ietf-tls-client
758
760 4. The TLS Server Model
762 4.1. Tree Diagram
764 This section provides a tree diagram [RFC8340] for the "ietf-tls-
765 server" module that does not have groupings expanded.
767 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
769 module: ietf-tls-server
771 grouping tls-server-grouping
772 +-- server-identity
773 | +-- (auth-type)
774 | +--:(certificate) {x509-certificate-auth}?
775 | | +-- certificate
776 | | +---u ks:local-or-keystore-end-entity-cert-with-key-\
777 grouping
778 | +--:(raw-private-key) {raw-public-key-auth}?
779 | | +-- raw-private-key
780 | | +---u ks:local-or-keystore-asymmetric-key-grouping
781 | +--:(psk) {psk-auth}?
782 | +-- psk
783 | +---u ks:local-or-keystore-symmetric-key-grouping
784 +-- client-authentication! {client-auth-config-supported}?
785 | +-- ca-certs! {x509-certificate-auth}?
786 | | +---u ts:local-or-truststore-certs-grouping
787 | +-- ee-certs! {x509-certificate-auth}?
788 | | +---u ts:local-or-truststore-certs-grouping
789 | +-- raw-public-keys! {raw-public-key-auth}?
790 | | +---u ts:local-or-truststore-public-keys-grouping
791 | +-- psks! {psk-auth}?
792 +-- hello-params {tls-server-hello-params-config}?
793 | +---u tlscmn:hello-params-grouping
794 +-- keepalives {tls-server-keepalives}?
795 +-- peer-allowed-to-send? empty
796 +-- test-peer-aliveness!
797 +-- max-wait? uint16
798 +-- max-attempts? uint8
800 4.2. Example Usage
802 This section presents two examples showing the "tls-server-grouping"
803 grouping populated with some data. These examples are effectively
804 the same except the first configures the server identity using a
805 local key while the second uses a key configured in a keystore. Both
806 examples are consistent with the examples presented in Section 2 of
807 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
808 [I-D.ietf-netconf-keystore].
810 The following example configures the server identity using a local
811 key:
813 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
814
818
819
820
821
822 ct:subject-public-key-info-format
824 base64encodedvalue==
825 ct:rsa-private-key-format
827 base64encodedvalue==
828 base64encodedvalue==
829
830
831
849
851
852
853
854
855 base64encodedvalue==
856 base64encodedvalue==
857 base64encodedvalue==
858
859
860
861
862 base64encodedvalue==
863 base64encodedvalue==
864 base64encodedvalue==
865
866
867
868
869
870 User A
871 ct:subject-public-key-info-format
873 base64encodedvalue==
874
875
876 User B
877 ct:subject-public-key-info-format
879 base64encodedvalue==
880
881
882
883
884
886
887
888
889
891 The following example configures the server identity using a key from
892 the keystore:
894 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) ===========
896
898
899
900
901
902 rsa-asymmetric-key
903 ex-rsa-cert
904
905
906
915
917
918
919
920 trusted-client-ca-certs
922
923
924 trusted-client-ee-certs
926
927
928 Raw Public Keys for TLS Clients
930
931
932
934
935
936
937
939 4.3. YANG Module
941 This YANG module has a normative references to [RFC5246],
942 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
944 file "ietf-tls-server@2020-05-20.yang"
946 module ietf-tls-server {
947 yang-version 1.1;
948 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
949 prefix tlss;
951 import ietf-netconf-acm {
952 prefix nacm;
953 reference
954 "RFC 8341: Network Configuration Access Control Model";
955 }
957 import ietf-crypto-types {
958 prefix ct;
959 reference
960 "RFC AAAA: Common YANG Data Types for Cryptography";
961 }
963 import ietf-truststore {
964 prefix ts;
965 reference
966 "RFC BBBB: A YANG Data Model for a Truststore";
967 }
969 import ietf-keystore {
970 prefix ks;
971 reference
972 "RFC CCCC: A YANG Data Model for a Keystore";
973 }
975 import ietf-tls-common {
976 prefix tlscmn;
977 revision-date 2020-05-20; // stable grouping definitions
978 reference
979 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
980 }
982 organization
983 "IETF NETCONF (Network Configuration) Working Group";
985 contact
986 "WG Web:
987 WG List:
988 Author: Kent Watsen
989 Author: Gary Wu ";
991 description
992 "This module defines reusable groupings for TLS servers that
993 can be used as a basis for specific TLS server instances.
995 Copyright (c) 2020 IETF Trust and the persons identified
996 as authors of the code. All rights reserved.
998 Redistribution and use in source and binary forms, with
999 or without modification, is permitted pursuant to, and
1000 subject to the license terms contained in, the Simplified
1001 BSD License set forth in Section 4.c of the IETF Trust's
1002 Legal Provisions Relating to IETF Documents
1003 (https://trustee.ietf.org/license-info).
1005 This version of this YANG module is part of RFC FFFF
1006 (https://www.rfc-editor.org/info/rfcFFFF); see the RFC
1007 itself for full legal notices.
1009 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1010 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1011 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1012 are to be interpreted as described in BCP 14 (RFC 2119)
1013 (RFC 8174) when, and only when, they appear in all
1014 capitals, as shown here.";
1016 revision 2020-05-20 {
1017 description
1018 "Initial version";
1019 reference
1020 "RFC FFFF: YANG Groupings for TLS Clients and TLS Servers";
1021 }
1023 // Features
1025 feature tls-server-hello-params-config {
1026 description
1027 "TLS hello message parameters are configurable on a TLS
1028 server.";
1029 }
1031 feature tls-server-keepalives {
1032 description
1033 "Per socket TLS keepalive parameters are configurable for
1034 TLS servers on the server implementing this feature.";
1036 }
1038 feature client-auth-config-supported {
1039 description
1040 "Indicates that the configuration for how to authenticate
1041 clients can be configured herein, as opposed to in an
1042 application specific location. That is, to support the
1043 consuming data models that prefer to place client
1044 authentication with client definitions, rather then
1045 in a data model principally concerned with configuring
1046 the transport.";
1047 }
1049 feature x509-certificate-auth {
1050 description
1051 "Indicates that the server supports authenticating clients
1052 using X.509 certificates.";
1053 }
1055 feature raw-public-key-auth {
1056 description
1057 "Indicates that the server supports authenticating clients
1058 using ray public keys.";
1059 }
1061 feature psk-auth {
1062 description
1063 "Indicates that the server supports authenticating clients
1064 using PSKs (pre-shared or pairwise-symmetric keys).";
1065 }
1067 // Groupings
1069 grouping tls-server-grouping {
1070 description
1071 "A reusable grouping for configuring a TLS server without
1072 any consideration for how underlying TCP sessions are
1073 established.
1075 Note that this grouping uses fairly typical descendent
1076 node names such that a stack of 'uses' statements will
1077 have name conflicts. It is intended that the consuming
1078 data model will resolve the issue (e.g., by wrapping
1079 the 'uses' statement in a container called
1080 'tls-server-parameters'). This model purposely does
1081 not do this itself so as to provide maximum flexibility
1082 to consuming models.";
1084 container server-identity {
1085 nacm:default-deny-write;
1086 description
1087 "A locally-defined or referenced end-entity certificate,
1088 including any configured intermediate certificates, the
1089 TLS server will present when establishing a TLS connection
1090 in its Certificate message, as defined in Section 7.4.2
1091 in RFC 5246.";
1092 reference
1093 "RFC 5246: The Transport Layer Security (TLS) Protocol
1094 Version 1.2
1095 RFC CCCC: A YANG Data Model for a Keystore";
1096 choice auth-type {
1097 mandatory true;
1098 description
1099 "A choice amongst authentication types.";
1100 case certificate {
1101 if-feature x509-certificate-auth;
1102 container certificate {
1103 description
1104 "Specifies the server identity using a certificate.";
1105 uses
1106 ks:local-or-keystore-end-entity-cert-with-key-grouping{
1107 refine "local-or-keystore/local/local-definition" {
1108 must 'public-key-format'
1109 + ' = "ct:subject-public-key-info-format"';
1110 }
1111 refine "local-or-keystore/keystore/keystore-reference"
1112 + "/asymmetric-key" {
1113 must 'deref(.)/../ks:public-key-format'
1114 + ' = "ct:subject-public-key-info-format"';
1115 }
1116 }
1117 }
1118 }
1119 case raw-private-key {
1120 if-feature raw-public-key-auth;
1121 container raw-private-key {
1122 description
1123 "Specifies the server identity using a raw
1124 private key.";
1125 uses ks:local-or-keystore-asymmetric-key-grouping {
1126 refine "local-or-keystore/local/local-definition" {
1127 must 'public-key-format'
1128 + ' = "ct:subject-public-key-info-format"';
1130 }
1131 refine "local-or-keystore/keystore/keystore-reference"{
1132 must 'deref(.)/../ks:public-key-format'
1133 + ' = "ct:subject-public-key-info-format"';
1134 }
1135 }
1136 }
1137 }
1138 case psk {
1139 if-feature psk-auth;
1140 container psk {
1141 description
1142 "Specifies the server identity using a PSK (pre-shared
1143 or pairwise-symmetric key). Note that, when the PSK is
1144 configured as a Keystore reference, the key's 'name'
1145 node MAY be used as the PSK's ID when used by the TLS
1146 protocol.";
1147 uses ks:local-or-keystore-symmetric-key-grouping {
1148 augment "local-or-keystore/local/local-definition" {
1149 if-feature "ks:local-definitions-supported";
1150 description
1151 "An 'id' value for when the PSK is used by TLS.";
1152 leaf id {
1153 type string; // FIXME: is this the right type?
1154 description
1155 "The key id used in the TLS protocol for PSKs.";
1156 }
1157 }
1158 }
1159 }
1160 }
1161 }
1162 } // container server-identity
1164 container client-authentication {
1165 if-feature "client-auth-config-supported";
1166 nacm:default-deny-write;
1167 presence
1168 "Indicates that client authentication is supported (i.e.,
1169 that the server will request clients send certificates).
1170 If not configured, the TLS server SHOULD NOT request the
1171 TLS clients provide authentication credentials.";
1172 description
1173 "Specifies how the TLS server can authenticate TLS clients.
1174 Any combination of credentials is additive and unordered.
1176 Note that no configuration is required for PSK (pre-shared
1177 or pairwise-symmetric key) based authentication as the key
1178 is necessarily the same as configured in the '../server-
1179 identity' node.";
1180 container ca-certs {
1181 if-feature "x509-certificate-auth";
1182 presence
1183 "Indicates that the TLS server can authenticate TLS clients
1184 using configured certificate authority certificates.";
1185 description
1186 "A set of certificate authority (CA) certificates used by
1187 the TLS server to authenticate TLS client certificates. A
1188 client certificate is authenticated if it has a valid
1189 chain of trust to a configured CA certificate.";
1190 reference
1191 "RFC BBBB: A YANG Data Model for a Truststore";
1192 uses ts:local-or-truststore-certs-grouping;
1193 }
1194 container ee-certs { // FIXME: plural too much?
1195 if-feature "x509-certificate-auth";
1196 presence
1197 "Indicates that the TLS server can authenticate TLS
1198 clients using configured client certificates.";
1199 description
1200 "A set of client certificates (i.e., end entity
1201 certificates) used by the TLS server to authenticate
1202 certificates presented by TLS clients. A client
1203 certificate is authenticated if it is an exact
1204 match to a configured client certificate.";
1205 reference
1206 "RFC BBBB: A YANG Data Model for a Truststore";
1207 uses ts:local-or-truststore-certs-grouping;
1208 }
1209 container raw-public-keys {
1210 if-feature "raw-public-key-auth";
1211 presence
1212 "Indicates that the TLS server can authenticate TLS
1213 clients using raw public keys.";
1214 description
1215 "A set of raw public keys used by the TLS server to
1216 authenticate raw public keys presented by the TLS
1217 client. A raw public key is authenticated if it
1218 is an exact match to a configured raw public key.";
1219 reference
1220 "RFC BBBB: A YANG Data Model for a Truststore";
1221 uses ts:local-or-truststore-public-keys-grouping {
1222 refine "local-or-truststore/local/local-definition"
1223 + "/public-key" {
1224 must 'public-key-format'
1225 + ' = "ct:subject-public-key-info-format"';
1227 }
1228 refine "local-or-truststore/truststore"
1229 + "/truststore-reference" {
1230 must 'deref(.)/../*/ts:public-key-format'
1231 + ' = "ct:subject-public-key-info-format"';
1232 }
1233 }
1234 }
1235 container psks {
1236 if-feature "psk-auth";
1237 presence
1238 "Indicates that the TLS server can authenticate the TLS
1239 client using its PSK (pre-shared or pairwise-symmetric
1240 key).";
1241 description
1242 "No configuration is required since the PSK value is the
1243 same as PSK value configured in the 'client-identity'
1244 node.";
1245 }
1246 } // container client-authentication
1248 container hello-params {
1249 nacm:default-deny-write;
1250 if-feature "tls-server-hello-params-config";
1251 uses tlscmn:hello-params-grouping;
1252 description
1253 "Configurable parameters for the TLS hello message.";
1254 } // container hello-params
1256 container keepalives {
1257 nacm:default-deny-write;
1258 if-feature "tls-server-keepalives";
1259 description
1260 "Configures the keepalive policy for the TLS server.";
1261 leaf peer-allowed-to-send {
1262 type empty;
1263 description
1264 "Indicates that the remote TLS client is allowed to send
1265 HeartbeatRequest messages, as defined by RFC 6520
1266 to this TLS server.";
1267 reference
1268 "RFC 6520: Transport Layer Security (TLS) and Datagram
1269 Transport Layer Security (DTLS) Heartbeat Extension";
1270 }
1271 container test-peer-aliveness {
1272 presence
1273 "Indicates that the TLS server proactively tests the
1274 aliveness of the remote TLS client.";
1276 description
1277 "Configures the keep-alive policy to proactively test
1278 the aliveness of the TLS client. An unresponsive
1279 TLS client is dropped after approximately max-wait
1280 * max-attempts seconds.";
1281 leaf max-wait {
1282 type uint16 {
1283 range "1..max";
1284 }
1285 units "seconds";
1286 default "30";
1287 description
1288 "Sets the amount of time in seconds after which if
1289 no data has been received from the TLS client, a
1290 TLS-level message will be sent to test the
1291 aliveness of the TLS client.";
1292 }
1293 leaf max-attempts {
1294 type uint8;
1295 default "3";
1296 description
1297 "Sets the maximum number of sequential keep-alive
1298 messages that can fail to obtain a response from
1299 the TLS client before assuming the TLS client is
1300 no longer alive.";
1301 }
1302 }
1303 } // container keepalives
1304 } // grouping tls-server-grouping
1305 } // module ietf-tls-server
1307
1309 5. The TLS Common Model
1311 The TLS common model presented in this section contains identities
1312 and groupings common to both TLS clients and TLS servers. The
1313 "hello-params-grouping" grouping can be used to configure the list of
1314 TLS algorithms permitted by the TLS client or TLS server. The lists
1315 of algorithms are ordered such that, if multiple algorithms are
1316 permitted by the client, the algorithm that appears first in its list
1317 that is also permitted by the server is used for the TLS transport
1318 layer connection. The ability to restrict the algorithms allowed is
1319 provided in this grouping for TLS clients and TLS servers that are
1320 capable of doing so and may serve to make TLS clients and TLS servers
1321 compliant with local security policies. This model supports both
1322 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446].
1324 TLS 1.2 and TLS 1.3 have different ways defining their own supported
1325 cryptographic algorithms, see TLS and DTLS IANA registries page
1326 (https://www.iana.org/assignments/tls-parameters/tls-
1327 parameters.xhtml):
1329 o TLS 1.2 defines four categories of registries for cryptographic
1330 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS
1331 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the
1332 role of combining all of them into one set, as each value of the
1333 set represents a unique and feasible combination of all the
1334 cryptographic algorithms, and thus the other three registry
1335 categories do not need to be considered here. In this document,
1336 the TLS common model only chooses those TLS1.2 algorithms in TLS
1337 Cipher Suites which are marked as recommended:
1338 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
1339 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
1340 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
1341 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen
1342 algorithms are enumerated in Table 1-1 below;
1344 o TLS 1.3 defines its supported algorithms differently. Firstly, it
1345 defines three categories of registries for cryptographic
1346 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported
1347 Groups. Secondly, all three of these categories are useful, since
1348 they represent different parts of all the supported algorithms
1349 respectively. Thus, all of these registries categories are
1350 considered here. In this draft, the TLS common model chooses only
1351 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of
1352 [RFC8446].
1354 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites
1355 part of the "hello-params-grouping" grouping should include three
1356 parameters for configuring its permitted TLS algorithms, which are:
1357 TLS Cipher Suites, TLS SignatureScheme, TLS Supported Groups. Note
1358 that TLS1.2 only uses TLS Cipher Suites.
1360 Features are defined for algorithms that are OPTIONAL or are not
1361 widely supported by popular implementations. Note that the list of
1362 algorithms is not exhaustive.
1364 5.1. Tree Diagram
1366 The following tree diagram [RFC8340] provides an overview of the data
1367 model for the "ietf-tls-common" module.
1369 module: ietf-tls-common
1371 grouping hello-params-grouping
1372 +-- tls-versions
1373 | +-- tls-version* identityref
1374 +-- cipher-suites
1375 +-- cipher-suite* identityref
1377 5.2. Example Usage
1379 This section shows how it would appear if the "hello-params-grouping"
1380 grouping were populated with some data.
1382
1385
1386 tlscmn:tls-1.1
1387 tlscmn:tls-1.2
1388
1389
1390 tlscmn:dhe-rsa-with-aes-128-cbc-sha
1391 tlscmn:rsa-with-aes-128-cbc-sha
1392 tlscmn:rsa-with-3des-ede-cbc-sha
1393
1394
1396 5.3. YANG Module
1398 This YANG module has a normative references to [RFC4346], [RFC5246],
1399 [RFC5288], [RFC5289], and [RFC8422].
1401 This YANG module has a informative references to [RFC2246],
1402 [RFC4346], [RFC5246], and [RFC8446].
1404 file "ietf-tls-common@2020-05-20.yang"
1406 module ietf-tls-common {
1407 yang-version 1.1;
1408 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
1409 prefix tlscmn;
1411 organization
1412 "IETF NETCONF (Network Configuration) Working Group";
1414 contact
1415 "WG Web:
1416 WG List:
1417 Author: Kent Watsen
1418 Author: Gary Wu ";
1420 description
1421 "This module defines a common features, identities, and
1422 groupings for Transport Layer Security (TLS).
1424 Copyright (c) 2020 IETF Trust and the persons identified
1425 as authors of the code. All rights reserved.
1427 Redistribution and use in source and binary forms, with
1428 or without modification, is permitted pursuant to, and
1429 subject to the license terms contained in, the Simplified
1430 BSD License set forth in Section 4.c of the IETF Trust's
1431 Legal Provisions Relating to IETF Documents
1432 (https://trustee.ietf.org/license-info).
1434 This version of this YANG module is part of RFC XXXX
1435 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
1436 itself for full legal notices.
1438 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1439 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1440 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1441 are to be interpreted as described in BCP 14 (RFC 2119)
1442 (RFC 8174) when, and only when, they appear in all
1443 capitals, as shown here.";
1445 revision 2020-05-20 {
1446 description
1447 "Initial version";
1448 reference
1449 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1450 }
1452 // Features
1454 feature tls-1_0 {
1455 description
1456 "TLS Protocol Version 1.0 is supported.";
1457 reference
1458 "RFC 2246: The TLS Protocol Version 1.0";
1459 }
1461 feature tls-1_1 {
1462 description
1463 "TLS Protocol Version 1.1 is supported.";
1464 reference
1465 "RFC 4346: The Transport Layer Security (TLS) Protocol
1466 Version 1.1";
1467 }
1469 feature tls-1_2 {
1470 description
1471 "TLS Protocol Version 1.2 is supported.";
1472 reference
1473 "RFC 5246: The Transport Layer Security (TLS) Protocol
1474 Version 1.2";
1475 }
1477 feature tls-1_3 {
1478 description
1479 "TLS Protocol Version 1.2 is supported.";
1480 reference
1481 "RFC 8446: The Transport Layer Security (TLS) Protocol
1482 Version 1.3";
1483 }
1485 feature tls-ecc {
1486 description
1487 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
1488 reference
1489 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1490 for Transport Layer Security (TLS)";
1491 }
1493 feature tls-dhe {
1494 description
1495 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
1496 reference
1497 "RFC 5246: The Transport Layer Security (TLS) Protocol
1498 Version 1.2";
1499 }
1501 feature tls-3des {
1502 description
1503 "The Triple-DES block cipher is supported for TLS.";
1504 reference
1505 "RFC 5246: The Transport Layer Security (TLS) Protocol
1506 Version 1.2";
1507 }
1509 feature tls-gcm {
1510 description
1511 "The Galois/Counter Mode authenticated encryption mode is
1512 supported for TLS.";
1514 reference
1515 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
1516 TLS";
1517 }
1519 feature tls-sha2 {
1520 description
1521 "The SHA2 family of cryptographic hash functions is supported
1522 for TLS.";
1523 reference
1524 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
1525 }
1527 // Identities
1529 identity tls-version-base {
1530 description
1531 "Base identity used to identify TLS protocol versions.";
1532 }
1534 identity tls-1.0 {
1535 if-feature "tls-1_0";
1536 base tls-version-base;
1537 description
1538 "TLS Protocol Version 1.0.";
1539 reference
1540 "RFC 2246: The TLS Protocol Version 1.0";
1541 }
1543 identity tls-1.1 {
1544 if-feature "tls-1_1";
1545 base tls-version-base;
1546 description
1547 "TLS Protocol Version 1.1.";
1548 reference
1549 "RFC 4346: The Transport Layer Security (TLS) Protocol
1550 Version 1.1";
1551 }
1553 identity tls-1.2 {
1554 if-feature "tls-1_2";
1555 base tls-version-base;
1556 description
1557 "TLS Protocol Version 1.2.";
1558 reference
1559 "RFC 5246: The Transport Layer Security (TLS) Protocol
1560 Version 1.2";
1561 }
1562 identity cipher-suite-base {
1563 description
1564 "Base identity used to identify TLS cipher suites.";
1565 }
1567 identity rsa-with-aes-128-cbc-sha {
1568 base cipher-suite-base;
1569 description
1570 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
1571 reference
1572 "RFC 5246: The Transport Layer Security (TLS) Protocol
1573 Version 1.2";
1574 }
1576 identity rsa-with-aes-256-cbc-sha {
1577 base cipher-suite-base;
1578 description
1579 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
1580 reference
1581 "RFC 5246: The Transport Layer Security (TLS) Protocol
1582 Version 1.2";
1583 }
1585 identity rsa-with-aes-128-cbc-sha256 {
1586 if-feature "tls-sha2";
1587 base cipher-suite-base;
1588 description
1589 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
1590 reference
1591 "RFC 5246: The Transport Layer Security (TLS) Protocol
1592 Version 1.2";
1593 }
1595 identity rsa-with-aes-256-cbc-sha256 {
1596 if-feature "tls-sha2";
1597 base cipher-suite-base;
1598 description
1599 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
1600 reference
1601 "RFC 5246: The Transport Layer Security (TLS) Protocol
1602 Version 1.2";
1603 }
1605 identity dhe-rsa-with-aes-128-cbc-sha {
1606 if-feature "tls-dhe";
1607 base cipher-suite-base;
1608 description
1609 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
1611 reference
1612 "RFC 5246: The Transport Layer Security (TLS) Protocol
1613 Version 1.2";
1614 }
1616 identity dhe-rsa-with-aes-256-cbc-sha {
1617 if-feature "tls-dhe";
1618 base cipher-suite-base;
1619 description
1620 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
1621 reference
1622 "RFC 5246: The Transport Layer Security (TLS) Protocol
1623 Version 1.2";
1624 }
1626 identity dhe-rsa-with-aes-128-cbc-sha256 {
1627 if-feature "tls-dhe and tls-sha2";
1628 base cipher-suite-base;
1629 description
1630 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
1631 reference
1632 "RFC 5246: The Transport Layer Security (TLS) Protocol
1633 Version 1.2";
1634 }
1636 identity dhe-rsa-with-aes-256-cbc-sha256 {
1637 if-feature "tls-dhe and tls-sha2";
1638 base cipher-suite-base;
1639 description
1640 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
1641 reference
1642 "RFC 5246: The Transport Layer Security (TLS) Protocol
1643 Version 1.2";
1644 }
1646 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
1647 if-feature "tls-ecc and tls-sha2";
1648 base cipher-suite-base;
1649 description
1650 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
1651 reference
1652 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1653 SHA-256/384 and AES Galois Counter Mode (GCM)";
1654 }
1656 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
1657 if-feature "tls-ecc and tls-sha2";
1658 base cipher-suite-base;
1659 description
1660 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
1661 reference
1662 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1663 SHA-256/384 and AES Galois Counter Mode (GCM)";
1664 }
1666 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
1667 if-feature "tls-ecc and tls-sha2";
1668 base cipher-suite-base;
1669 description
1670 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
1671 reference
1672 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1673 SHA-256/384 and AES Galois Counter Mode (GCM)";
1674 }
1676 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
1677 if-feature "tls-ecc and tls-sha2";
1678 base cipher-suite-base;
1679 description
1680 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
1681 reference
1682 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1683 SHA-256/384 and AES Galois Counter Mode (GCM)";
1684 }
1686 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
1687 if-feature "tls-ecc and tls-gcm and tls-sha2";
1688 base cipher-suite-base;
1689 description
1690 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
1691 reference
1692 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1693 SHA-256/384 and AES Galois Counter Mode (GCM)";
1694 }
1696 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
1697 if-feature "tls-ecc and tls-gcm and tls-sha2";
1698 base cipher-suite-base;
1699 description
1700 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
1701 reference
1702 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1703 SHA-256/384 and AES Galois Counter Mode (GCM)";
1704 }
1706 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
1707 if-feature "tls-ecc and tls-gcm and tls-sha2";
1708 base cipher-suite-base;
1709 description
1710 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
1711 reference
1712 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1713 SHA-256/384 and AES Galois Counter Mode (GCM)";
1714 }
1716 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
1717 if-feature "tls-ecc and tls-gcm and tls-sha2";
1718 base cipher-suite-base;
1719 description
1720 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
1721 reference
1722 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1723 SHA-256/384 and AES Galois Counter Mode (GCM)";
1724 }
1726 identity rsa-with-3des-ede-cbc-sha {
1727 if-feature "tls-3des";
1728 base cipher-suite-base;
1729 description
1730 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
1731 reference
1732 "RFC 5246: The Transport Layer Security (TLS) Protocol
1733 Version 1.2";
1734 }
1736 identity ecdhe-rsa-with-3des-ede-cbc-sha {
1737 if-feature "tls-ecc and tls-3des";
1738 base cipher-suite-base;
1739 description
1740 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
1741 reference
1742 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1743 for Transport Layer Security (TLS)";
1744 }
1746 identity ecdhe-rsa-with-aes-128-cbc-sha {
1747 if-feature "tls-ecc";
1748 base cipher-suite-base;
1749 description
1750 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
1751 reference
1752 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1753 for Transport Layer Security (TLS)";
1754 }
1755 identity ecdhe-rsa-with-aes-256-cbc-sha {
1756 if-feature "tls-ecc";
1757 base cipher-suite-base;
1758 description
1759 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1760 reference
1761 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1762 for Transport Layer Security (TLS)";
1763 }
1765 // Groupings
1767 grouping hello-params-grouping {
1768 description
1769 "A reusable grouping for TLS hello message parameters.";
1770 reference
1771 "RFC 5246: The Transport Layer Security (TLS) Protocol
1772 Version 1.2";
1773 container tls-versions {
1774 description
1775 "Parameters regarding TLS versions.";
1776 leaf-list tls-version {
1777 type identityref {
1778 base tls-version-base;
1779 }
1780 description
1781 "Acceptable TLS protocol versions.
1783 If this leaf-list is not configured (has zero elements)
1784 the acceptable TLS protocol versions are implementation-
1785 defined.";
1786 }
1787 }
1788 container cipher-suites {
1789 description
1790 "Parameters regarding cipher suites.";
1791 leaf-list cipher-suite {
1792 type identityref {
1793 base cipher-suite-base;
1794 }
1795 ordered-by user;
1796 description
1797 "Acceptable cipher suites in order of descending
1798 preference. The configured host key algorithms should
1799 be compatible with the algorithm used by the configured
1800 private key. Please see Section 5 of RFC XXXX for
1801 valid combinations.
1803 If this leaf-list is not configured (has zero elements)
1804 the acceptable cipher suites are implementation-
1805 defined.";
1806 reference
1807 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1808 }
1809 }
1810 }
1811 }
1813
1815 6. Security Considerations
1817 The YANG modules defined in this document are designed to be accessed
1818 via YANG based management protocols, such as NETCONF [RFC6241] and
1819 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1820 implement secure transport layers (e.g., SSH, TLS) with mutual
1821 authentication.
1823 The NETCONF access control model (NACM) [RFC8341] provides the means
1824 to restrict access for particular users to a pre-configured subset of
1825 all available protocol operations and content.
1827 Since the modules in this document only define groupings, these
1828 considerations are primarily for the designers of other modules that
1829 use these groupings.
1831 There are a number of data nodes defined in the YANG modules that are
1832 writable/creatable/deletable (i.e., config true, which is the
1833 default). These data nodes may be considered sensitive or vulnerable
1834 in some network environments. Write operations (e.g., edit-config)
1835 to these data nodes without proper protection can have a negative
1836 effect on network operations. These are the subtrees and data nodes
1837 and their sensitivity/vulnerability:
1839 *: The entire subtree defined by the grouping statement in both
1840 the "ietf-ssh-client" and "ietf-ssh-server" modules is
1841 sensitive to write operations. For instance, the addition or
1842 removal of references to keys, certificates, trusted anchors,
1843 etc., or even the modification of transport or keepalive
1844 parameters can dramatically alter the implemented security
1845 policy. For this reason, this node is protected the NACM
1846 extension "default-deny-write".
1848 Some of the readable data nodes in the YANG modules may be considered
1849 sensitive or vulnerable in some network environments. It is thus
1850 important to control read access (e.g., via get, get-config, or
1851 notification) to these data nodes. These are the subtrees and data
1852 nodes and their sensitivity/vulnerability:
1854 /tls-client-parameters/client-identity/: This subtree in the
1855 "ietf-tls-client" module contains nodes that are additionally
1856 sensitive to read operations such that, in normal use cases,
1857 they should never be returned to a client. Some of these nodes
1858 (i.e., public-key/local-definition/private-key and certificate/
1859 local-definition/private-key) are already protected by the NACM
1860 extension "default-deny-all" set in the "grouping" statements
1861 defined in [I-D.ietf-netconf-crypto-types].
1863 /tls-server-parameters/server-identity/: This subtree in the
1864 "ietf-tls-server" module contains nodes that are additionally
1865 sensitive to read operations such that, in normal use cases,
1866 they should never be returned to a client. All of these nodes
1867 (i.e., host-key/public-key/local-definition/private-key and
1868 host-key/certificate/local-definition/private-key) are already
1869 protected by the NACM extension "default-deny-all" set in the
1870 "grouping" statements defined in
1871 [I-D.ietf-netconf-crypto-types].
1873 Some of the operations in this YANG module may be considered
1874 sensitive or vulnerable in some network environments. It is thus
1875 important to control access to these operations. These are the
1876 operations and their sensitivity/vulnerability:
1878 *: The groupings defined in this document include "action"
1879 statements that come from groupings defined in
1880 [I-D.ietf-netconf-crypto-types]. Please consult that document
1881 for the security considerations of the "action" statements
1882 defined by the "grouping" statements defined in this document.
1884 7. IANA Considerations
1886 7.1. The IETF XML Registry
1888 This document registers three URIs in the "ns" subregistry of the
1889 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
1890 following registrations are requested:
1892 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1893 Registrant Contact: The NETCONF WG of the IETF.
1894 XML: N/A, the requested URI is an XML namespace.
1896 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1897 Registrant Contact: The NETCONF WG of the IETF.
1898 XML: N/A, the requested URI is an XML namespace.
1900 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1901 Registrant Contact: The NETCONF WG of the IETF.
1902 XML: N/A, the requested URI is an XML namespace.
1904 7.2. The YANG Module Names Registry
1906 This document registers three YANG modules in the YANG Module Names
1907 registry [RFC6020]. Following the format in [RFC6020], the following
1908 registrations are requested:
1910 name: ietf-tls-client
1911 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1912 prefix: tlsc
1913 reference: RFC FFFF
1915 name: ietf-tls-server
1916 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1917 prefix: tlss
1918 reference: RFC FFFF
1920 name: ietf-tls-common
1921 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1922 prefix: tlscmn
1923 reference: RFC FFFF
1925 8. References
1927 8.1. Normative References
1929 [I-D.ietf-netconf-crypto-types]
1930 Watsen, K. and H. Wang, "Common YANG Data Types for
1931 Cryptography", draft-ietf-netconf-crypto-types-14 (work in
1932 progress), March 2020.
1934 [I-D.ietf-netconf-keystore]
1935 Watsen, K., "A YANG Data Model for a Keystore", draft-
1936 ietf-netconf-keystore-16 (work in progress), March 2020.
1938 [I-D.ietf-netconf-trust-anchors]
1939 Watsen, K., "A YANG Data Model for a Truststore", draft-
1940 ietf-netconf-trust-anchors-09 (work in progress), March
1941 2020.
1943 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1944 Requirement Levels", BCP 14, RFC 2119,
1945 DOI 10.17487/RFC2119, March 1997,
1946 .
1948 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1949 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1950 DOI 10.17487/RFC5288, August 2008,
1951 .
1953 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1954 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1955 DOI 10.17487/RFC5289, August 2008,
1956 .
1958 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1959 the Network Configuration Protocol (NETCONF)", RFC 6020,
1960 DOI 10.17487/RFC6020, October 2010,
1961 .
1963 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1964 NETCONF Protocol over Transport Layer Security (TLS) with
1965 Mutual X.509 Authentication", RFC 7589,
1966 DOI 10.17487/RFC7589, June 2015,
1967 .
1969 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1970 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1971 .
1973 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1974 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1975 May 2017, .
1977 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1978 Access Control Model", STD 91, RFC 8341,
1979 DOI 10.17487/RFC8341, March 2018,
1980 .
1982 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
1983 Curve Cryptography (ECC) Cipher Suites for Transport Layer
1984 Security (TLS) Versions 1.2 and Earlier", RFC 8422,
1985 DOI 10.17487/RFC8422, August 2018,
1986 .
1988 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1989 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1990 .
1992 8.2. Informative References
1994 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1995 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1996 .
1998 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1999 DOI 10.17487/RFC2818, May 2000,
2000 .
2002 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
2003 DOI 10.17487/RFC3688, January 2004,
2004 .
2006 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
2007 (TLS) Protocol Version 1.1", RFC 4346,
2008 DOI 10.17487/RFC4346, April 2006,
2009 .
2011 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
2012 (TLS) Protocol Version 1.2", RFC 5246,
2013 DOI 10.17487/RFC5246, August 2008,
2014 .
2016 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
2017 and A. Bierman, Ed., "Network Configuration Protocol
2018 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
2019 .
2021 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
2022 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
2023 .
2025 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
2026 RFC 8071, DOI 10.17487/RFC8071, February 2017,
2027 .
2029 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
2030 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
2031 .
2033 8.3. URIs
2035 [1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types
2037 [2] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors
2039 [3] https://tools.ietf.org/html/draft-ietf-netconf-keystore
2041 [4] https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server
2043 [5] https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server
2045 [6] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server
2047 [7] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server
2049 [8] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-
2050 server
2052 [9] https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-
2053 server
2055 Appendix A. Change Log
2057 A.1. 00 to 01
2059 o Noted that '0.0.0.0' and '::' might have special meanings.
2061 o Renamed "keychain" to "keystore".
2063 A.2. 01 to 02
2065 o Removed the groupings containing transport-level configuration.
2066 Now modules contain only the transport-independent groupings.
2068 o Filled in previously incomplete 'ietf-tls-client' module.
2070 o Added cipher suites for various algorithms into new 'ietf-tls-
2071 common' module.
2073 A.3. 02 to 03
2075 o Added a 'must' statement to container 'server-auth' asserting that
2076 at least one of the various auth mechanisms must be specified.
2078 o Fixed description statement for leaf 'trusted-ca-certs'.
2080 A.4. 03 to 04
2082 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
2084 o Updated leafref paths to point to new keystore path
2086 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
2087 'tlscmn'.
2089 o Added TLS protocol verions 1.0 and 1.1.
2091 o Made author lists consistent
2093 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
2095 o Updated YANG to use typedefs around leafrefs to common keystore
2096 paths
2098 o Now inlines key and certificates (no longer a leafref to keystore)
2100 A.5. 04 to 05
2102 o Merged changes from co-author.
2104 A.6. 05 to 06
2106 o Updated to use trust anchors from trust-anchors draft (was
2107 keystore draft)
2109 o Now Uses new keystore grouping enabling asymmetric key to be
2110 either locally defined or a reference to the keystore.
2112 A.7. 06 to 07
2114 o factored the tls-[client|server]-groupings into more reusable
2115 groupings.
2117 o added if-feature statements for the new "x509-certificates"
2118 feature defined in draft-ietf-netconf-trust-anchors.
2120 A.8. 07 to 08
2122 o Added a number of compatibility matrices to Section 5 (thanks
2123 Frank!)
2125 o Clarified that any configured "cipher-suite" values need to be
2126 compatible with the configured private key.
2128 A.9. 08 to 09
2130 o Updated examples to reflect update to groupings defined in the
2131 keystore draft.
2133 o Add TLS keepalives features and groupings.
2135 o Prefixed top-level TLS grouping nodes with 'tls-' and support
2136 mashups.
2138 o Updated copyright date, boilerplate template, affiliation, and
2139 folding algorithm.
2141 A.10. 09 to 10
2143 o Reformatted the YANG modules.
2145 A.11. 10 to 11
2147 o Collapsed all the inner groupings into the top-level grouping.
2149 o Added a top-level "demux container" inside the top-level grouping.
2151 o Added NACM statements and updated the Security Considerations
2152 section.
2154 o Added "presence" statements on the "keepalive" containers, as was
2155 needed to address a validation error that appeared after adding
2156 the "must" statements into the NETCONF/RESTCONF client/server
2157 modules.
2159 o Updated the boilerplate text in module-level "description"
2160 statement to match copyeditor convention.
2162 A.12. 11 to 12
2164 o In server model, made 'client-authentication' a 'presence' node
2165 indicating that the server supports client authentication.
2167 o In the server model, added a 'required-or-optional' choice to
2168 'client-authentication' to better support protocols such as
2169 RESTCONF.
2171 o In the server model, added a 'local-or-external' choice to
2172 'client-authentication' to better support consuming data models
2173 that prefer to keep client auth with client definitions than in a
2174 model principally concerned with the "transport".
2176 o In both models, removed the "demux containers", floating the
2177 nacm:default-deny-write to each descendent node, and adding a note
2178 to model designers regarding the potential need to add their own
2179 demux containers.
2181 o Fixed a couple references (section 2 --> section 3)
2183 A.13. 12 to 13
2185 o Updated to reflect changes in trust-anchors drafts (e.g., s/trust-
2186 anchors/truststore/g + s/pinned.//)
2188 A.14. 12 to 13
2190 o Removed 'container' under 'client-identity' to match server model.
2192 o Updated examples to reflect change grouping in keystore module.
2194 A.15. 13 to 14
2196 o Removed the "certificate" container from "client-identity" in the
2197 ietf-tls-client module.
2199 o Updated examples to reflect ietf-crypto-types change (e.g.,
2200 identities --> enumerations)
2202 A.16. 14 to 15
2204 o Updated "server-authentication" and "client-authentication" nodes
2205 from being a leaf of type "ts:certificates-ref" to a container
2206 that uses "ts:local-or-truststore-certs-grouping".
2208 A.17. 15 to 16
2210 o Removed unnecessary if-feature statements in the -client and
2211 -server modules.
2213 o Cleaned up some description statements in the -client and -server
2214 modules.
2216 o Fixed a canonical ordering issue in ietf-tls-common detected by
2217 new pyang.
2219 A.18. 16 to 17
2221 o Removed choice local-or-external by removing the 'external' case
2222 and flattening the 'local' case and adding a "client-auth-config-
2223 supported" feature.
2225 o Removed choice required-or-optional.
2227 o Updated examples to include the "*-key-format" nodes.
2229 o Augmented-in "must" expressions ensuring that locally-defined
2230 public-key-format are "ct:ssh-public-key-format" (must expr for
2231 ref'ed keys are TBD).
2233 A.19. 17 to 18
2235 o Removed the unused "external-client-auth-supported" feature.
2237 o Made client-indentity optional, as there may be over-the-top auth
2238 instead.
2240 o Added augment to uses of local-or-keystore-symmetric-key-grouping
2241 for a psk "id" node.
2243 o Added missing presence container "psks" to ietf-tls-server's
2244 "client-authentication" container.
2246 o Updated examples to reflect new "bag" addition to truststore.
2248 o Removed feature-limited caseless 'case' statements to improve tree
2249 diagram rendering.
2251 o Refined truststore/keystore groupings to ensure the key formats
2252 "must" be particular values.
2254 o Switched to using truststore's new "public-key" bag (instead of
2255 separate "ssh-public-key" and "raw-public-key" bags.
2257 o Updated client/server examples to cover ALL cases (local/ref x
2258 cert/raw-key/psk).
2260 A.20. 18 to 19
2262 o Updated the "keepalives" containers in part to address Michal
2263 Vasko's request to align with RFC 8071, and in part to better
2264 align to RFC 6520.
2266 o Removed algorithm-mapping tables from the "TLS Common Model"
2267 section
2269 o Removed the 'algorithm' node from the examples.
2271 o Renamed both "client-certs" and "server-certs" to "ee-certs"
2273 o Added a "Note to Reviewers" note to first page.
2275 Acknowledgements
2277 The authors would like to thank for following for lively discussions
2278 on list and in the halls (ordered by last name): Andy Bierman, Martin
2279 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, Radek Krejci,
2280 David Lamparter, Ladislav Lhotka, Alan Luchuk, Tom Petch, Juergen
2281 Schoenwaelder, Phil Shafer, Sean Turner, Michal Vasko, Bert Wijnen,
2282 and Liang Xia.
2284 Authors' Addresses
2286 Kent Watsen
2287 Watsen Networks
2289 EMail: kent+ietf@watsen.net
2290 Gary Wu
2291 Cisco Systems
2293 EMail: garywu@cisco.com