idnits 2.17.1
draft-ietf-netconf-tls-client-server-14.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 (July 2, 2019) is 1760 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)
== Outdated reference: A later version (-34) exists of
draft-ietf-netconf-crypto-types-09
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-11
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-05
-- 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: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 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: January 3, 2020 Cisco Systems
6 L. Xia
7 Huawei
8 July 2, 2019
10 YANG Groupings for TLS Clients and TLS Servers
11 draft-ietf-netconf-tls-client-server-14
13 Abstract
15 This document defines three YANG modules: the first defines groupings
16 for a generic TLS client, the second defines groupings for a generic
17 TLS server, and the third defines common identities and groupings
18 used by both the client and the server. It is intended that these
19 groupings will be used by applications using the TLS protocol.
21 Editorial Note (To be removed by RFC Editor)
23 This draft contains many placeholder values that need to be replaced
24 with finalized values at the time of publication. This note
25 summarizes all of the substitutions that are needed. No other RFC
26 Editor instructions are specified elsewhere in this document.
28 This document contains references to other drafts in progress, both
29 in the Normative References section, as well as in body text
30 throughout. Please update the following references to reflect their
31 final RFC assignments:
33 o I-D.ietf-netconf-trust-anchors
35 o I-D.ietf-netconf-keystore
37 Artwork in this document contains shorthand references to drafts in
38 progress. Please apply the following replacements:
40 o "XXXX" --> the assigned RFC value for this draft
42 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust-
43 anchors
45 o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore
47 Artwork in this document contains placeholder values for the date of
48 publication of this draft. Please apply the following replacement:
50 o "2019-07-02" --> the publication date of this draft
52 The following Appendix section is to be removed prior to publication:
54 o Appendix A. Change Log
56 Status of This Memo
58 This Internet-Draft is submitted in full conformance with the
59 provisions of BCP 78 and BCP 79.
61 Internet-Drafts are working documents of the Internet Engineering
62 Task Force (IETF). Note that other groups may also distribute
63 working documents as Internet-Drafts. The list of current Internet-
64 Drafts is at https://datatracker.ietf.org/drafts/current/.
66 Internet-Drafts are draft documents valid for a maximum of six months
67 and may be updated, replaced, or obsoleted by other documents at any
68 time. It is inappropriate to use Internet-Drafts as reference
69 material or to cite them other than as "work in progress."
71 This Internet-Draft will expire on January 3, 2020.
73 Copyright Notice
75 Copyright (c) 2019 IETF Trust and the persons identified as the
76 document authors. All rights reserved.
78 This document is subject to BCP 78 and the IETF Trust's Legal
79 Provisions Relating to IETF Documents
80 (https://trustee.ietf.org/license-info) in effect on the date of
81 publication of this document. Please review these documents
82 carefully, as they describe your rights and restrictions with respect
83 to this document. Code Components extracted from this document must
84 include Simplified BSD License text as described in Section 4.e of
85 the Trust Legal Provisions and are provided without warranty as
86 described in the Simplified BSD License.
88 Table of Contents
90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
92 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4
93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 4
95 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
96 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10
97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
99 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 12
100 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 18
101 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 27
102 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 27
103 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 27
104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 36
105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
106 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 37
107 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 38
108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
109 8.1. Normative References . . . . . . . . . . . . . . . . . . 38
110 8.2. Informative References . . . . . . . . . . . . . . . . . 40
111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 42
112 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 42
113 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 42
114 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 42
115 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 42
116 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 43
117 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 43
118 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 43
119 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 43
120 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 43
121 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 43
122 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 44
123 A.12. 11 to 12 . . . . . . . . . . . . . . . . . . . . . . . . 44
124 A.13. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44
125 A.14. 12 to 13 . . . . . . . . . . . . . . . . . . . . . . . . 44
126 A.15. 13 to 14 . . . . . . . . . . . . . . . . . . . . . . . . 45
127 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 45
128 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
130 1. Introduction
132 This document defines three YANG 1.1 [RFC7950] modules: the first
133 defines a grouping for a generic TLS client, the second defines a
134 grouping for a generic TLS server, and the third defines identities
135 and groupings common to both the client and the server (TLS is
136 defined in [RFC5246]). It is intended that these groupings will be
137 used by applications using the TLS protocol. For instance, these
138 groupings could be used to help define the data model for an HTTPS
139 [RFC2818] server or a NETCONF over TLS [RFC7589] based server.
141 The client and server YANG modules in this document each define one
142 grouping, which is focused on just TLS-specific configuration, and
143 specifically avoids any transport-level configuration, such as what
144 ports to listen-on or connect-to. This affords applications the
145 opportunity to define their own strategy for how the underlying TCP
146 connection is established. For instance, applications supporting
147 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping"
148 grouping for the TLS parts it provides, while adding data nodes for
149 the TCP-level call-home configuration.
151 2. Terminology
153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
155 "OPTIONAL" in this document are to be interpreted as described in BCP
156 14 [RFC2119] [RFC8174] when, and only when, they appear in all
157 capitals, as shown here.
159 3. The TLS Client Model
161 3.1. Tree Diagram
163 This section provides a tree diagram [RFC8340] for the "ietf-tls-
164 client" module that does not have groupings expanded.
166 module: ietf-tls-client
168 grouping tls-client-grouping
169 +-- client-identity
170 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping
171 +-- server-authentication
172 | +-- ca-certs? ts:certificates-ref
173 | | {ts:x509-certificates}?
174 | +-- server-certs? ts:certificates-ref
175 | {ts:x509-certificates}?
176 +-- hello-params {tls-client-hello-params-config}?
177 | +---u tlscmn:hello-params-grouping
178 +-- keepalives! {tls-client-keepalives}?
179 +-- max-wait? uint16
180 +-- max-attempts? uint8
182 3.2. Example Usage
184 This section presents two examples showing the tls-client-grouping
185 populated with some data. These examples are effectively the same
186 except the first configures the client identity using a local key
187 while the second uses a key configured in a keystore. Both examples
188 are consistent with the examples presented in Section 2 of
189 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
190 [I-D.ietf-netconf-keystore].
192 The following example configures the client identity using a local
193 key:
195
197
198
199
200 rsa2048
201 base64encodedvalue==
202 base64encodedvalue==
203 base64encodedvalue==
204
205
207
208
209 explicitly-trusted-server-ca-certs
210 explicitly-trusted-server-certs
211
213
214 30
215 3
216
218
220 The following example configures the client identity using a key from
221 the keystore:
223
225
226
227
228 ex-rsa-key
229 ex-rsa-cert
230
231
233
234
235 explicitly-trusted-server-ca-certs
236 explicitly-trusted-server-certs
237
239
240 30
241 3
242
244
246 3.3. YANG Module
248 This YANG module has normative references to
249 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
251 file "ietf-tls-client@2019-07-02.yang"
252 module ietf-tls-client {
253 yang-version 1.1;
254 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
255 prefix tlsc;
257 import ietf-tls-common {
258 prefix tlscmn;
259 revision-date 2019-07-02; // stable grouping definitions
260 reference
261 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
262 }
264 import ietf-truststore {
265 prefix ts;
266 reference
267 "RFC YYYY: A YANG Data Model for a Truststore";
268 }
270 import ietf-keystore {
271 prefix ks;
272 reference
273 "RFC ZZZZ: A YANG Data Model for a Keystore";
274 }
276 import ietf-netconf-acm {
277 prefix nacm;
278 reference
279 "RFC 8341: Network Configuration Access Control Model";
280 }
282 organization
283 "IETF NETCONF (Network Configuration) Working Group";
285 contact
286 "WG Web:
287 WG List:
288 Author: Kent Watsen
289 Author: Gary Wu ";
291 description
292 "This module defines reusable groupings for TLS clients that
293 can be used as a basis for specific TLS client instances.
295 Copyright (c) 2019 IETF Trust and the persons identified
296 as authors of the code. All rights reserved.
298 Redistribution and use in source and binary forms, with
299 or without modification, is permitted pursuant to, and
300 subject to the license terms contained in, the Simplified
301 BSD License set forth in Section 4.c of the IETF Trust's
302 Legal Provisions Relating to IETF Documents
303 (https://trustee.ietf.org/license-info).
305 This version of this YANG module is part of RFC XXXX
306 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
307 itself for full legal notices.;
309 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
310 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
311 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
312 are to be interpreted as described in BCP 14 (RFC 2119)
313 (RFC 8174) when, and only when, they appear in all
314 capitals, as shown here.";
316 revision 2019-07-02 {
317 description
318 "Initial version";
320 reference
321 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
322 }
324 // Features
326 feature tls-client-hello-params-config {
327 description
328 "TLS hello message parameters are configurable on a TLS
329 client.";
330 }
332 feature tls-client-keepalives {
333 description
334 "Per socket TLS keepalive parameters are configurable for
335 TLS clients on the server implementing this feature.";
336 }
338 // Groupings
340 grouping tls-client-grouping {
341 description
342 "A reusable grouping for configuring a TLS client without
343 any consideration for how an underlying TCP session is
344 established.
346 Note that this grouping uses fairly typical descendent
347 node names such that a stack of 'uses' statements will
348 have name conflicts. It is intended that the consuming
349 data model will resolve the issue (e.g., by wrapping
350 the 'uses' statement in a container called
351 'tls-client-parameters'). This model purposely does
352 not do this itself so as to provide maximum flexibility
353 to consuming models.";
355 container client-identity { // FIXME: what about PSKs?
356 nacm:default-deny-write;
357 description
358 "A locally-defined or referenced end-entity certificate,
359 including any configured intermediate certificates, the
360 TLS client will present when establishing a TLS connection
361 in its Certificate message, as defined in Section 7.4.2
362 in RFC 5246.";
363 reference
364 "RFC 5246:
365 The Transport Layer Security (TLS) Protocol Version 1.2
366 RFC ZZZZ:
367 YANG Data Model for a 'Keystore' Mechanism";
369 uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
370 } // container client-identity
372 container server-authentication { // FIXME: what about PSKs?
373 nacm:default-deny-write;
374 must 'ca-certs or server-certs';
375 description
376 "Trusted server identities.";
377 leaf ca-certs {
378 if-feature "ts:x509-certificates";
379 type ts:certificates-ref;
380 description
381 "A reference to a list of certificate authority (CA)
382 certificates used by the TLS client to authenticate
383 TLS server certificates. A server certificate is
384 authenticated if it has a valid chain of trust to
385 a configured CA certificate.";
386 }
387 leaf server-certs {
388 if-feature "ts:x509-certificates";
389 type ts:certificates-ref;
390 description
391 "A reference to a list of server certificates used by
392 the TLS client to authenticate TLS server certificates.
393 A server certificate is authenticated if it is an
394 exact match to a configured server certificate.";
395 }
396 } // container server-authentication
398 container hello-params {
399 nacm:default-deny-write;
400 if-feature "tls-client-hello-params-config";
401 uses tlscmn:hello-params-grouping;
402 description
403 "Configurable parameters for the TLS hello message.";
404 } // container hello-params
406 container keepalives {
407 nacm:default-deny-write;
408 if-feature "tls-client-keepalives";
409 presence "Indicates that keepalives are enabled.";
410 description
411 "Configures the keep-alive policy, to proactively test
412 the aliveness of the TLS server. An unresponsive
413 TLS server is dropped after approximately max-wait
414 * max-attempts seconds.";
415 leaf max-wait {
416 type uint16 {
417 range "1..max";
418 }
419 units "seconds";
420 default "30";
421 description
422 "Sets the amount of time in seconds after which if
423 no data has been received from the TLS server, a
424 TLS-level message will be sent to test the
425 aliveness of the TLS server.";
426 }
427 leaf max-attempts {
428 type uint8;
429 default "3";
430 description
431 "Sets the maximum number of sequential keep-alive
432 messages that can fail to obtain a response from
433 the TLS server before assuming the TLS server is
434 no longer alive.";
435 }
436 } // container keepalives
437 } // grouping tls-client-grouping
438 }
439
441 4. The TLS Server Model
443 4.1. Tree Diagram
445 This section provides a tree diagram [RFC8340] for the "ietf-tls-
446 server" module that does not have groupings expanded.
448 module: ietf-tls-server
450 grouping tls-server-grouping
451 +-- server-identity
452 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping
453 +-- client-authentication!
454 | +-- (required-or-optional)
455 | | +--:(required)
456 | | | +-- required? empty
457 | | +--:(optional)
458 | | +-- optional? empty
459 | +-- (local-or-external)
460 | +--:(local) {local-client-auth-supported}?
461 | | +-- ca-certs? ts:certificates-ref
462 | | | {ts:x509-certificates}?
463 | | +-- client-certs? ts:certificates-ref
464 | | {ts:x509-certificates}?
465 | +--:(external) {external-client-auth-supported}?
466 | +-- client-auth-defined-elsewhere? empty
467 +-- hello-params {tls-server-hello-params-config}?
468 | +---u tlscmn:hello-params-grouping
469 +-- keepalives! {tls-server-keepalives}?
470 +-- max-wait? uint16
471 +-- max-attempts? uint8
473 4.2. Example Usage
475 This section presents two examples showing the tls-server-grouping
476 populated with some data. These examples are effectively the same
477 except the first configures the server identity using a local key
478 while the second uses a key configured in a keystore. Both examples
479 are consistent with the examples presented in Section 2 of
480 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
481 [I-D.ietf-netconf-keystore].
483 The following example configures the server identity using a local
484 key:
486
488
489
490
491 rsa2048
492 base64encodedvalue==
493 base64encodedvalue==
494 base64encodedvalue==
495
496
498
499
500
501 explicitly-trusted-client-ca-certs
502 explicitly-trusted-client-certs
503
505
507 The following example configures the server identity using a key from
508 the keystore:
510
512
513
514
515 ex-rsa-key
516 ex-rsa-cert
517
518
520
521
522
523 explicitly-trusted-client-ca-certs
524 explicitly-trusted-client-certs
525
527
529 4.3. YANG Module
531 This YANG module has a normative references to [RFC5246],
532 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
534 file "ietf-tls-server@2019-07-02.yang"
535 module ietf-tls-server {
536 yang-version 1.1;
537 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
538 prefix tlss;
540 import ietf-tls-common {
541 prefix tlscmn;
542 revision-date 2019-07-02; // stable grouping definitions
543 reference
544 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
545 }
547 import ietf-truststore {
548 prefix ts;
549 reference
550 "RFC YYYY: A YANG Data Model for a Truststore";
551 }
553 import ietf-keystore {
554 prefix ks;
555 reference
556 "RFC ZZZZ: A YANG Data Model for a Keystore";
557 }
559 import ietf-netconf-acm {
560 prefix nacm;
561 reference
562 "RFC 8341: Network Configuration Access Control Model";
563 }
565 organization
566 "IETF NETCONF (Network Configuration) Working Group";
568 contact
569 "WG Web:
570 WG List:
571 Author: Kent Watsen
572 Author: Gary Wu ";
574 description
575 "This module defines reusable groupings for TLS servers that
576 can be used as a basis for specific TLS server instances.
578 Copyright (c) 2019 IETF Trust and the persons identified
579 as authors of the code. All rights reserved.
581 Redistribution and use in source and binary forms, with
582 or without modification, is permitted pursuant to, and
583 subject to the license terms contained in, the Simplified
584 BSD License set forth in Section 4.c of the IETF Trust's
585 Legal Provisions Relating to IETF Documents
586 (https://trustee.ietf.org/license-info).
588 This version of this YANG module is part of RFC XXXX
589 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
590 itself for full legal notices.;
592 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
593 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
594 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
595 are to be interpreted as described in BCP 14 (RFC 2119)
596 (RFC 8174) when, and only when, they appear in all
597 capitals, as shown here.";
599 revision 2019-07-02 {
600 description
601 "Initial version";
602 reference
603 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
604 }
606 // Features
608 feature tls-server-hello-params-config {
609 description
610 "TLS hello message parameters are configurable on a TLS
611 server.";
612 }
614 feature tls-server-keepalives {
615 description
616 "Per socket TLS keepalive parameters are configurable for
617 TLS servers on the server implementing this feature.";
618 }
620 feature local-client-auth-supported {
621 description
622 "Indicates that the TLS server supports local
623 configuration of client credentials.";
624 }
626 feature external-client-auth-supported {
627 description
628 "Indicates that the TLS server supports external
629 configuration of client credentials.";
630 }
632 // Groupings
634 grouping tls-server-grouping {
635 description
636 "A reusable grouping for configuring a TLS server without
637 any consideration for how underlying TCP sessions are
638 established.
640 Note that this grouping uses fairly typical descendent
641 node names such that a stack of 'uses' statements will
642 have name conflicts. It is intended that the consuming
643 data model will resolve the issue (e.g., by wrapping
644 the 'uses' statement in a container called
645 'tls-server-parameters'). This model purposely does
646 not do this itself so as to provide maximum flexibility
647 to consuming models.";
649 container server-identity { // FIXME: what about PSKs?
650 nacm:default-deny-write;
651 description
652 "A locally-defined or referenced end-entity certificate,
653 including any configured intermediate certificates, the
654 TLS server will present when establishing a TLS connection
655 in its Certificate message, as defined in Section 7.4.2
656 in RFC 5246.";
657 reference
658 "RFC 5246:
659 The Transport Layer Security (TLS) Protocol Version 1.2
660 RFC ZZZZ:
661 YANG Data Model for a 'Keystore' Mechanism";
662 uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
663 } // container server-identity
665 container client-authentication { // FIXME: what about PSKs?
666 nacm:default-deny-write;
667 presence
668 "Indicates that certificate based client authentication
669 is supported (i.e., the server will request that the
670 client send a certificate).";
671 description
672 "Specifies if TLS client authentication is required or
673 optional, and specifies if the certificates needed to
674 authenticate the TLS client are configured locally or
675 externally. If configured locally, the data model
676 enables both trust anchors and end-entity certificate
677 to be set.";
678 choice required-or-optional {
679 mandatory true; // or default to 'required' ?
680 description
681 "Indicates if TLS-level client authentication is required
682 or optional. This is necessary for some protocols (e.g.,
683 RESTCONF) the may optionally authenticate a client via
684 TLS-level authentication, HTTP-level authentication, or
685 both simultaneously).";
686 leaf required {
687 type empty;
688 description
689 "Indicates that TLS-level client authentication is
690 required.";
691 }
692 leaf optional {
693 type empty;
694 description
695 "Indicates that TLS-level client authentication is
696 optional.";
697 }
698 }
699 choice local-or-external {
700 mandatory true;
701 description
702 "Indicates if the certificates needed to authenticate
703 the client are configured locally or externally. The
704 need to support external configuration for client
705 authentication stems from the desire to support
706 consuming data models that prefer to place client
707 authentication with client definitions, rather then
708 in a data model principally concerned with configuring
709 the transport.";
710 case local {
711 if-feature "local-client-auth-supported";
712 description
713 "The certificates needed to authenticate the clients
714 are configured locally.";
715 leaf ca-certs {
716 if-feature "ts:x509-certificates";
717 type ts:certificates-ref;//FIXME: local-or-remote?
718 description
719 "A reference to a list of certificate authority (CA)
720 certificates used by the TLS server to authenticate
721 TLS client certificates. A client certificate is
722 authenticated if it has a valid chain of trust to
723 a configured CA certificate.";
724 reference
725 "RFC YYYY: YANG Data Model for Global Trust Anchors";
726 }
727 leaf client-certs {
728 if-feature "ts:x509-certificates";
729 type ts:certificates-ref;//FIXME: local-or-remote?
730 description
731 "A reference to a list of client certificates
732 used by the TLS server to authenticate TLS
733 client certificates. A clients certificate
734 is authenticated if it is an exact match to
735 a configured client certificate.";
736 reference
737 "RFC YYYY: YANG Data Model for Global Trust Anchors";
738 }
739 }
740 case external {
741 if-feature "external-client-auth-supported";
742 description
743 "The certificates needed to authenticate the clients
744 are configured externally.";
745 leaf client-auth-defined-elsewhere {
746 type empty;
747 description
748 "Indicates that certificates needed to authenticate
749 clients are configured elsewhere.";
750 }
751 }
752 } // choice local-or-external
753 } // container client-authentication
755 container hello-params {
756 nacm:default-deny-write;
757 if-feature "tls-server-hello-params-config";
758 uses tlscmn:hello-params-grouping;
759 description
760 "Configurable parameters for the TLS hello message.";
761 } // container hello-params
763 container keepalives {
764 nacm:default-deny-write;
765 if-feature "tls-server-keepalives";
766 presence "Indicates that keepalives are enabled.";
767 description
768 "Configures the keep-alive policy, to proactively test
769 the aliveness of the TLS client. An unresponsive
770 TLS client is dropped after approximately max-wait
771 * max-attempts seconds.";
772 leaf max-wait {
773 type uint16 {
774 range "1..max";
775 }
776 units "seconds";
777 default "30";
778 description
779 "Sets the amount of time in seconds after which if
780 no data has been received from the TLS client, a
781 TLS-level message will be sent to test the
782 aliveness of the TLS client.";
783 }
784 leaf max-attempts {
785 type uint8;
786 default "3";
787 description
788 "Sets the maximum number of sequential keep-alive
789 messages that can fail to obtain a response from
790 the TLS client before assuming the TLS client is
791 no longer alive.";
792 }
793 } // container keepalives
794 } // grouping tls-server-grouping
795 }
796
798 5. The TLS Common Model
800 The TLS common model presented in this section contains identities
801 and groupings common to both TLS clients and TLS servers. The hello-
802 params-grouping can be used to configure the list of TLS algorithms
803 permitted by the TLS client or TLS server. The lists of algorithms
804 are ordered such that, if multiple algorithms are permitted by the
805 client, the algorithm that appears first in its list that is also
806 permitted by the server is used for the TLS transport layer
807 connection. The ability to restrict the algorithms allowed is
808 provided in this grouping for TLS clients and TLS servers that are
809 capable of doing so and may serve to make TLS clients and TLS servers
810 compliant with local security policies. This model supports both
811 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446].
813 TLS 1.2 and TLS 1.3 have different ways defining their own supported
814 cryptographic algorithms, see TLS and DTLS IANA registries page
815 (https://www.iana.org/assignments/tls-parameters/tls-
816 parameters.xhtml):
818 o TLS 1.2 defines four categories of registries for cryptographic
819 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS
820 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the
821 role of combining all of them into one set, as each value of the
822 set represents a unique and feasible combination of all the
823 cryptographic algorithms, and thus the other three registry
824 categories do not need to be considered here. In this document,
825 the TLS common model only chooses those TLS1.2 algorithms in TLS
826 Cipher Suites which are marked as recommended:
827 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
828 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
829 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
830 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen
831 algorithms are enumerated in Table 1-1 below;
833 o TLS 1.3 defines its supported algorithms differently. Firstly, it
834 defines three categories of registries for cryptographic
835 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported
836 Groups. Secondly, all three of these categories are useful, since
837 they represent different parts of all the supported algorithms
838 respectively. Thus, all of these registries categories are
839 considered here. In this draft, the TLS common model chooses only
840 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of
841 [RFC8446].
843 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites
844 part of the hello-params-grouping should include three parameters for
845 configuring its permitted TLS algorithms, which are: TLS Cipher
846 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2
847 only uses TLS Cipher Suites.
849 [I-D.ietf-netconf-crypto-types] defines six categories of
850 cryptographic algorithms (hash-algorithm, symmetric-key-encryption-
851 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm,
852 signature-algorithm, key-negotiation-algorithm) and lists several
853 widely accepted algorithms for each of them. The TLS client and
854 server models use one or more of these algorithms. The following
855 tables are provided, in part to define the subset of algorithms
856 defined in the crypto-types model used by TLS, and in part to ensure
857 compatibility of configured TLS cryptographic parameters for
858 configuring its permitted TLS algorithms:
860 +-----------------------------------------------+---------+
861 | ciper-suites in hello-params-grouping | HASH |
862 +-----------------------------------------------+---------+
863 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
864 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
865 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
866 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
867 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 |
868 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 |
869 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
870 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
871 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 |
872 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 |
873 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 |
874 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 |
875 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
876 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
877 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
878 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
879 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
880 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
881 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
882 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 |
883 +-----------------------------------------------+---------+
885 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping
886 to hash-algorithm
888 +--------------------------------------------- +---------------------+
889 | ciper-suites in hello-params-grouping | symmetric |
890 | | |
891 +--------------------------------------------- +---------------------+
892 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
893 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
894 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
895 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
896 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
897 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
898 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
899 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
900 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm |
901 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm |
902 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm |
903 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm |
904 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
905 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305|
906 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
907 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
908 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
909 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
910 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
911 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm |
912 +--------------------------------------------- +---------------------+
914 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping
915 to symmetric-key-encryption-algorithm
917 +--------------------------------------------- +---------------------+
918 | ciper-suites in hello-params-grouping | MAC |
919 | | |
920 +--------------------------------------------- +---------------------+
921 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
922 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
923 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
924 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
925 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
926 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
927 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
928 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
929 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm |
930 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm |
931 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm |
932 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm |
933 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
934 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305|
935 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
936 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
937 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
938 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
939 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
940 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm |
941 +--------------------------------------------- +---------------------+
943 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping
944 to MAC-algorithm
946 +----------------------------------------------+----------------------+
947 |ciper-suites in hello-params-grouping | signature |
948 +--------------------------------------------- +----------------------+
949 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
950 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
951 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
952 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
953 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256|
954 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384|
955 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
956 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
957 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 |
958 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 |
959 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A |
960 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A |
961 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
962 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256|
963 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
964 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
965 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
966 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
967 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
968 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A |
969 +----------------------------------------------+----------------------+
971 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping
972 to signature-algorithm
974 +----------------------------------------------+-----------------------+
975 |ciper-suites in hello-params-grouping | key-negotiation |
976 +----------------------------------------------+-----------------------+
977 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... |
978 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... |
979 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...|
980 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...|
981 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
982 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
983 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
984 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
985 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... |
986 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... |
987 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...|
988 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...|
989 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... |
990 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... |
991 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... |
992 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...|
993 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...|
994 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...|
995 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...|
996 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...|
997 +----------------------------------------------+-----------------------+
999 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping
1000 to key-negotiation-algorithm
1002 +------------------------------+---------+
1003 | ciper-suites in hello | HASH |
1004 | -params-grouping | |
1005 +------------------------------+---------+
1006 | TLS_AES_128_GCM_SHA256 | sha-256 |
1007 | TLS_AES_256_GCM_SHA384 | sha-384 |
1008 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 |
1009 | TLS_AES_128_CCM_SHA256 | sha-256 |
1010 +------------------------------+---------+
1012 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping
1013 to hash-algorithm
1015 +------------------------------+-----------------------+
1016 | ciper-suites in hello | symmetric |
1017 | -params-grouping | |
1018 +------------------------------+-----------------------+
1019 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm |
1020 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm |
1021 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 |
1022 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm |
1023 +------------------------------+-----------------------+
1025 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping
1026 to symmetric-key--encryption-algorithm
1028 +------------------------------+-----------------------+
1029 | ciper-suites in hello | symmetric |
1030 | -params-grouping | |
1031 +------------------------------+-----------------------+
1032 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm |
1033 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm |
1034 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 |
1035 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm |
1036 +------------------------------+-----------------------+
1038 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping
1039 to MAC-algorithm
1041 +----------------------------+-------------------------+
1042 |signatureScheme in hello | signature |
1043 | -params-grouping | |
1044 +----------------------------+-------------------------+
1045 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 |
1046 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 |
1047 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 |
1048 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 |
1049 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 |
1050 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 |
1051 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 |
1052 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 |
1053 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 |
1054 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 |
1055 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 |
1056 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 |
1057 | ed25519 | ed25519 |
1058 | ed448 | ed448 |
1059 +----------------------------+-------------------------+
1061 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme
1062 mapping to signature-algorithm
1064 +----------------------------+-------------------------+
1065 |supported Groups in hello | key-negotiation |
1066 | -params-grouping | |
1067 +----------------------------+-------------------------+
1068 | dhe-ffdhe2048 | dhe-ffdhe2048 |
1069 | dhe-ffdhe3072 | dhe-ffdhe3072 |
1070 | dhe-ffdhe4096 | dhe-ffdhe4096 |
1071 | dhe-ffdhe6144 | dhe-ffdhe6144 |
1072 | dhe-ffdhe8192 | dhe-ffdhe8192 |
1073 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 |
1074 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 |
1075 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 |
1076 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 |
1077 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 |
1078 | ecdhe-secp256r1 | ecdhe-secp256r1 |
1079 | ecdhe-secp384r1 | ecdhe-secp384r1 |
1080 | ecdhe-secp521r1 | ecdhe-secp521r1 |
1081 | ecdhe-x25519 | ecdhe-x25519 |
1082 | ecdhe-x448 | ecdhe-x448 |
1083 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 |
1084 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 |
1085 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 |
1086 | psk-ecdhe-x25519 | psk-ecdhe-x25519 |
1087 | psk-ecdhe-x448 | psk-ecdhe-x448 |
1088 +----------------------------+-------------------------+
1090 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups
1091 mapping to key-negotiation-algorithm
1093 Note that in Table 1-5:
1095 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe-
1096 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192;
1098 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048,
1099 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe-
1100 ffdhe8192;
1102 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1,
1103 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448;
1105 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe-
1106 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe-
1107 x25519, psk-ecdhe-x448.
1109 Features are defined for algorithms that are OPTIONAL or are not
1110 widely supported by popular implementations. Note that the list of
1111 algorithms is not exhaustive.
1113 5.1. Tree Diagram
1115 The following tree diagram [RFC8340] provides an overview of the data
1116 model for the "ietf-tls-common" module.
1118 module: ietf-tls-common
1120 grouping hello-params-grouping
1121 +-- tls-versions
1122 | +-- tls-version* identityref
1123 +-- cipher-suites
1124 +-- cipher-suite* identityref
1126 5.2. Example Usage
1128 This section shows how it would appear if the transport-params-
1129 grouping were populated with some data.
1131
1134
1135 tlscmn:tls-1.1
1136 tlscmn:tls-1.2
1137
1138
1139 tlscmn:dhe-rsa-with-aes-128-cbc-sha
1140 tlscmn:rsa-with-aes-128-cbc-sha
1141 tlscmn:rsa-with-3des-ede-cbc-sha
1142
1143
1145 5.3. YANG Module
1147 This YANG module has a normative references to [RFC4346], [RFC5246],
1148 [RFC5288], [RFC5289], and [RFC8422].
1150 This YANG module has a informative references to [RFC2246],
1151 [RFC4346], [RFC5246], and [RFC8446].
1153 file "ietf-tls-common@2019-07-02.yang"
1154 module ietf-tls-common {
1155 yang-version 1.1;
1156 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
1157 prefix tlscmn;
1159 organization
1160 "IETF NETCONF (Network Configuration) Working Group";
1162 contact
1163 "WG Web:
1164 WG List:
1165 Author: Kent Watsen
1166 Author: Gary Wu ";
1168 description
1169 "This module defines a common features, identities, and
1170 groupings for Transport Layer Security (TLS).
1172 Copyright (c) 2019 IETF Trust and the persons identified
1173 as authors of the code. All rights reserved.
1175 Redistribution and use in source and binary forms, with
1176 or without modification, is permitted pursuant to, and
1177 subject to the license terms contained in, the Simplified
1178 BSD License set forth in Section 4.c of the IETF Trust's
1179 Legal Provisions Relating to IETF Documents
1180 (https://trustee.ietf.org/license-info).
1182 This version of this YANG module is part of RFC XXXX
1183 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
1184 itself for full legal notices.;
1186 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1187 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1188 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1189 are to be interpreted as described in BCP 14 (RFC 2119)
1190 (RFC 8174) when, and only when, they appear in all
1191 capitals, as shown here.";
1193 revision 2019-07-02 {
1194 description
1195 "Initial version";
1196 reference
1197 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1198 }
1200 // Features
1202 feature tls-1_0 {
1203 description
1204 "TLS Protocol Version 1.0 is supported.";
1205 reference
1206 "RFC 2246: The TLS Protocol Version 1.0";
1207 }
1209 feature tls-1_1 {
1210 description
1211 "TLS Protocol Version 1.1 is supported.";
1212 reference
1213 "RFC 4346: The Transport Layer Security (TLS) Protocol
1214 Version 1.1";
1215 }
1217 feature tls-1_2 {
1218 description
1219 "TLS Protocol Version 1.2 is supported.";
1220 reference
1221 "RFC 5246: The Transport Layer Security (TLS) Protocol
1222 Version 1.2";
1223 }
1225 feature tls-1_3 {
1226 description
1227 "TLS Protocol Version 1.2 is supported.";
1228 reference
1229 "RFC 8446: The Transport Layer Security (TLS) Protocol
1230 Version 1.3";
1231 }
1233 feature tls-ecc {
1234 description
1235 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
1236 reference
1237 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1238 for Transport Layer Security (TLS)";
1239 }
1241 feature tls-dhe {
1242 description
1243 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
1244 reference
1245 "RFC 5246: The Transport Layer Security (TLS) Protocol
1246 Version 1.2";
1247 }
1249 feature tls-3des {
1250 description
1251 "The Triple-DES block cipher is supported for TLS.";
1252 reference
1253 "RFC 5246: The Transport Layer Security (TLS) Protocol
1254 Version 1.2";
1255 }
1257 feature tls-gcm {
1258 description
1259 "The Galois/Counter Mode authenticated encryption mode is
1260 supported for TLS.";
1261 reference
1262 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
1263 TLS";
1264 }
1266 feature tls-sha2 {
1267 description
1268 "The SHA2 family of cryptographic hash functions is supported
1269 for TLS.";
1270 reference
1271 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
1272 }
1274 // Identities
1276 identity tls-version-base {
1277 description
1278 "Base identity used to identify TLS protocol versions.";
1279 }
1281 identity tls-1.0 {
1282 base tls-version-base;
1283 if-feature "tls-1_0";
1284 description
1285 "TLS Protocol Version 1.0.";
1286 reference
1287 "RFC 2246: The TLS Protocol Version 1.0";
1288 }
1290 identity tls-1.1 {
1291 base tls-version-base;
1292 if-feature "tls-1_1";
1293 description
1294 "TLS Protocol Version 1.1.";
1295 reference
1296 "RFC 4346: The Transport Layer Security (TLS) Protocol
1297 Version 1.1";
1298 }
1300 identity tls-1.2 {
1301 base tls-version-base;
1302 if-feature "tls-1_2";
1303 description
1304 "TLS Protocol Version 1.2.";
1305 reference
1306 "RFC 5246: The Transport Layer Security (TLS) Protocol
1307 Version 1.2";
1308 }
1310 identity cipher-suite-base {
1311 description
1312 "Base identity used to identify TLS cipher suites.";
1313 }
1315 identity rsa-with-aes-128-cbc-sha {
1316 base cipher-suite-base;
1317 description
1318 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
1319 reference
1320 "RFC 5246: The Transport Layer Security (TLS) Protocol
1321 Version 1.2";
1322 }
1324 identity rsa-with-aes-256-cbc-sha {
1325 base cipher-suite-base;
1326 description
1327 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
1328 reference
1329 "RFC 5246: The Transport Layer Security (TLS) Protocol
1330 Version 1.2";
1331 }
1333 identity rsa-with-aes-128-cbc-sha256 {
1334 base cipher-suite-base;
1335 if-feature "tls-sha2";
1336 description
1337 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
1338 reference
1339 "RFC 5246: The Transport Layer Security (TLS) Protocol
1340 Version 1.2";
1341 }
1343 identity rsa-with-aes-256-cbc-sha256 {
1344 base cipher-suite-base;
1345 if-feature "tls-sha2";
1346 description
1347 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
1348 reference
1349 "RFC 5246: The Transport Layer Security (TLS) Protocol
1350 Version 1.2";
1351 }
1353 identity dhe-rsa-with-aes-128-cbc-sha {
1354 base cipher-suite-base;
1355 if-feature "tls-dhe";
1356 description
1357 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
1358 reference
1359 "RFC 5246: The Transport Layer Security (TLS) Protocol
1360 Version 1.2";
1361 }
1363 identity dhe-rsa-with-aes-256-cbc-sha {
1364 base cipher-suite-base;
1365 if-feature "tls-dhe";
1366 description
1367 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
1368 reference
1369 "RFC 5246: The Transport Layer Security (TLS) Protocol
1370 Version 1.2";
1371 }
1373 identity dhe-rsa-with-aes-128-cbc-sha256 {
1374 base cipher-suite-base;
1375 if-feature "tls-dhe and tls-sha2";
1376 description
1377 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
1378 reference
1379 "RFC 5246: The Transport Layer Security (TLS) Protocol
1380 Version 1.2";
1381 }
1383 identity dhe-rsa-with-aes-256-cbc-sha256 {
1384 base cipher-suite-base;
1385 if-feature "tls-dhe and tls-sha2";
1386 description
1387 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
1388 reference
1389 "RFC 5246: The Transport Layer Security (TLS) Protocol
1390 Version 1.2";
1391 }
1393 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
1394 base cipher-suite-base;
1395 if-feature "tls-ecc and tls-sha2";
1396 description
1397 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
1398 reference
1399 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1400 SHA-256/384 and AES Galois Counter Mode (GCM)";
1401 }
1402 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
1403 base cipher-suite-base;
1404 if-feature "tls-ecc and tls-sha2";
1405 description
1406 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
1407 reference
1408 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1409 SHA-256/384 and AES Galois Counter Mode (GCM)";
1410 }
1412 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
1413 base cipher-suite-base;
1414 if-feature "tls-ecc and tls-sha2";
1415 description
1416 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
1417 reference
1418 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1419 SHA-256/384 and AES Galois Counter Mode (GCM)";
1420 }
1422 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
1423 base cipher-suite-base;
1424 if-feature "tls-ecc and tls-sha2";
1425 description
1426 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
1427 reference
1428 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1429 SHA-256/384 and AES Galois Counter Mode (GCM)";
1430 }
1432 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
1433 base cipher-suite-base;
1434 if-feature "tls-ecc and tls-gcm and tls-sha2";
1435 description
1436 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
1437 reference
1438 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1439 SHA-256/384 and AES Galois Counter Mode (GCM)";
1440 }
1442 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
1443 base cipher-suite-base;
1444 if-feature "tls-ecc and tls-gcm and tls-sha2";
1445 description
1446 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
1447 reference
1448 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1449 SHA-256/384 and AES Galois Counter Mode (GCM)";
1451 }
1453 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
1454 base cipher-suite-base;
1455 if-feature "tls-ecc and tls-gcm and tls-sha2";
1456 description
1457 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
1458 reference
1459 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1460 SHA-256/384 and AES Galois Counter Mode (GCM)";
1461 }
1463 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
1464 base cipher-suite-base;
1465 if-feature "tls-ecc and tls-gcm and tls-sha2";
1466 description
1467 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
1468 reference
1469 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1470 SHA-256/384 and AES Galois Counter Mode (GCM)";
1471 }
1473 identity rsa-with-3des-ede-cbc-sha {
1474 base cipher-suite-base;
1475 if-feature "tls-3des";
1476 description
1477 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
1478 reference
1479 "RFC 5246: The Transport Layer Security (TLS) Protocol
1480 Version 1.2";
1481 }
1483 identity ecdhe-rsa-with-3des-ede-cbc-sha {
1484 base cipher-suite-base;
1485 if-feature "tls-ecc and tls-3des";
1486 description
1487 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
1488 reference
1489 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1490 for Transport Layer Security (TLS)";
1491 }
1493 identity ecdhe-rsa-with-aes-128-cbc-sha {
1494 base cipher-suite-base;
1495 if-feature "tls-ecc";
1496 description
1497 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
1498 reference
1499 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1500 for Transport Layer Security (TLS)";
1501 }
1503 identity ecdhe-rsa-with-aes-256-cbc-sha {
1504 base cipher-suite-base;
1505 if-feature "tls-ecc";
1506 description
1507 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1508 reference
1509 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1510 for Transport Layer Security (TLS)";
1511 }
1513 // Groupings
1515 grouping hello-params-grouping {
1516 description
1517 "A reusable grouping for TLS hello message parameters.";
1518 reference
1519 "RFC 5246: The Transport Layer Security (TLS) Protocol
1520 Version 1.2";
1521 container tls-versions {
1522 description
1523 "Parameters regarding TLS versions.";
1524 leaf-list tls-version {
1525 type identityref {
1526 base tls-version-base;
1527 }
1528 description
1529 "Acceptable TLS protocol versions.
1531 If this leaf-list is not configured (has zero elements)
1532 the acceptable TLS protocol versions are implementation-
1533 defined.";
1534 }
1535 }
1536 container cipher-suites {
1537 description
1538 "Parameters regarding cipher suites.";
1539 leaf-list cipher-suite {
1540 type identityref {
1541 base cipher-suite-base;
1542 }
1543 ordered-by user;
1544 description
1545 "Acceptable cipher suites in order of descending
1546 preference. The configured host key algorithms should
1547 be compatible with the algorithm used by the configured
1548 private key. Please see Section 5 of RFC XXXX for
1549 valid combinations.
1551 If this leaf-list is not configured (has zero elements)
1552 the acceptable cipher suites are implementation-
1553 defined.";
1554 reference
1555 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1556 }
1557 }
1558 }
1559 }
1560
1562 6. Security Considerations
1564 The YANG modules defined in this document are designed to be accessed
1565 via YANG based management protocols, such as NETCONF [RFC6241] and
1566 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1567 implement secure transport layers (e.g., SSH, TLS) with mutual
1568 authentication.
1570 The NETCONF access control model (NACM) [RFC8341] provides the means
1571 to restrict access for particular users to a pre-configured subset of
1572 all available protocol operations and content.
1574 Since the modules in this document only define groupings, these
1575 considerations are primarily for the designers of other modules that
1576 use these groupings.
1578 There are a number of data nodes defined in the YANG modules that are
1579 writable/creatable/deletable (i.e., config true, which is the
1580 default). These data nodes may be considered sensitive or vulnerable
1581 in some network environments. Write operations (e.g., edit-config)
1582 to these data nodes without proper protection can have a negative
1583 effect on network operations. These are the subtrees and data nodes
1584 and their sensitivity/vulnerability:
1586 *: The entire subtree defined by the grouping statement in both
1587 the "ietf-ssh-client" and "ietf-ssh-server" modules is
1588 sensitive to write operations. For instance, the addition or
1589 removal of references to keys, certificates, trusted anchors,
1590 etc., or even the modification of transport or keepalive
1591 parameters can dramatically alter the implemented security
1592 policy. For this reason, this node is protected the NACM
1593 extension "default-deny-write".
1595 Some of the readable data nodes in the YANG modules may be considered
1596 sensitive or vulnerable in some network environments. It is thus
1597 important to control read access (e.g., via get, get-config, or
1598 notification) to these data nodes. These are the subtrees and data
1599 nodes and their sensitivity/vulnerability:
1601 /tls-client-parameters/client-identity/: This subtree in the
1602 "ietf-tls-client" module contains nodes that are additionally
1603 sensitive to read operations such that, in normal use cases,
1604 they should never be returned to a client. Some of these nodes
1605 (i.e., public-key/local-definition/private-key and certificate/
1606 local-definition/private-key) are already protected by the NACM
1607 extension "default-deny-all" set in the "grouping" statements
1608 defined in [I-D.ietf-netconf-crypto-types].
1610 /tls-server-parameters/server-identity/: This subtree in the
1611 "ietf-tls-server" module contains nodes that are additionally
1612 sensitive to read operations such that, in normal use cases,
1613 they should never be returned to a client. All of these nodes
1614 (i.e., host-key/public-key/local-definition/private-key and
1615 host-key/certificate/local-definition/private-key) are already
1616 protected by the NACM extension "default-deny-all" set in the
1617 "grouping" statements defined in
1618 [I-D.ietf-netconf-crypto-types].
1620 Some of the operations in this YANG module may be considered
1621 sensitive or vulnerable in some network environments. It is thus
1622 important to control access to these operations. These are the
1623 operations and their sensitivity/vulnerability:
1625 *: The groupings defined in this document include "action"
1626 statements that come from groupings defined in
1627 [I-D.ietf-netconf-crypto-types]. Please consult that document
1628 for the security considerations of the "action" statements
1629 defined by the "grouping" statements defined in this document.
1631 7. IANA Considerations
1633 7.1. The IETF XML Registry
1635 This document registers three URIs in the "ns" subregistry of the
1636 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
1637 following registrations are requested:
1639 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1640 Registrant Contact: The NETCONF WG of the IETF.
1641 XML: N/A, the requested URI is an XML namespace.
1643 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1644 Registrant Contact: The NETCONF WG of the IETF.
1645 XML: N/A, the requested URI is an XML namespace.
1647 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1648 Registrant Contact: The NETCONF WG of the IETF.
1649 XML: N/A, the requested URI is an XML namespace.
1651 7.2. The YANG Module Names Registry
1653 This document registers three YANG modules in the YANG Module Names
1654 registry [RFC6020]. Following the format in [RFC6020], the following
1655 registrations are requested:
1657 name: ietf-tls-client
1658 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1659 prefix: tlsc
1660 reference: RFC XXXX
1662 name: ietf-tls-server
1663 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1664 prefix: tlss
1665 reference: RFC XXXX
1667 name: ietf-tls-common
1668 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1669 prefix: tlscmn
1670 reference: RFC XXXX
1672 8. References
1674 8.1. Normative References
1676 [I-D.ietf-netconf-crypto-types]
1677 Watsen, K. and H. Wang, "Common YANG Data Types for
1678 Cryptography", draft-ietf-netconf-crypto-types-09 (work in
1679 progress), June 2019.
1681 [I-D.ietf-netconf-keystore]
1682 Watsen, K., "A YANG Data Model for a Keystore", draft-
1683 ietf-netconf-keystore-11 (work in progress), June 2019.
1685 [I-D.ietf-netconf-trust-anchors]
1686 Watsen, K., "A YANG Data Model for a Truststore", draft-
1687 ietf-netconf-trust-anchors-05 (work in progress), June
1688 2019.
1690 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1691 Requirement Levels", BCP 14, RFC 2119,
1692 DOI 10.17487/RFC2119, March 1997,
1693 .
1695 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1696 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1697 DOI 10.17487/RFC5288, August 2008,
1698 .
1700 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1701 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1702 DOI 10.17487/RFC5289, August 2008,
1703 .
1705 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1706 the Network Configuration Protocol (NETCONF)", RFC 6020,
1707 DOI 10.17487/RFC6020, October 2010,
1708 .
1710 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1711 NETCONF Protocol over Transport Layer Security (TLS) with
1712 Mutual X.509 Authentication", RFC 7589,
1713 DOI 10.17487/RFC7589, June 2015,
1714 .
1716 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1717 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1718 .
1720 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1721 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1722 May 2017, .
1724 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1725 Access Control Model", STD 91, RFC 8341,
1726 DOI 10.17487/RFC8341, March 2018,
1727 .
1729 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
1730 Curve Cryptography (ECC) Cipher Suites for Transport Layer
1731 Security (TLS) Versions 1.2 and Earlier", RFC 8422,
1732 DOI 10.17487/RFC8422, August 2018,
1733 .
1735 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1736 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1737 .
1739 8.2. Informative References
1741 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1742 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1743 .
1745 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1746 DOI 10.17487/RFC2818, May 2000,
1747 .
1749 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1750 DOI 10.17487/RFC3688, January 2004,
1751 .
1753 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1754 (TLS) Protocol Version 1.1", RFC 4346,
1755 DOI 10.17487/RFC4346, April 2006,
1756 .
1758 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1759 (TLS) Protocol Version 1.2", RFC 5246,
1760 DOI 10.17487/RFC5246, August 2008,
1761 .
1763 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1764 and A. Bierman, Ed., "Network Configuration Protocol
1765 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1766 .
1768 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1769 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1770 .
1772 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1773 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1774 .
1776 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1777 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1778 .
1780 Appendix A. Change Log
1782 A.1. 00 to 01
1784 o Noted that '0.0.0.0' and '::' might have special meanings.
1786 o Renamed "keychain" to "keystore".
1788 A.2. 01 to 02
1790 o Removed the groupings containing transport-level configuration.
1791 Now modules contain only the transport-independent groupings.
1793 o Filled in previously incomplete 'ietf-tls-client' module.
1795 o Added cipher suites for various algorithms into new 'ietf-tls-
1796 common' module.
1798 A.3. 02 to 03
1800 o Added a 'must' statement to container 'server-auth' asserting that
1801 at least one of the various auth mechanisms must be specified.
1803 o Fixed description statement for leaf 'trusted-ca-certs'.
1805 A.4. 03 to 04
1807 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
1809 o Updated leafref paths to point to new keystore path
1811 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
1812 'tlscmn'.
1814 o Added TLS protocol verions 1.0 and 1.1.
1816 o Made author lists consistent
1818 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
1820 o Updated YANG to use typedefs around leafrefs to common keystore
1821 paths
1823 o Now inlines key and certificates (no longer a leafref to keystore)
1825 A.5. 04 to 05
1827 o Merged changes from co-author.
1829 A.6. 05 to 06
1831 o Updated to use trust anchors from trust-anchors draft (was
1832 keystore draft)
1834 o Now Uses new keystore grouping enabling asymmetric key to be
1835 either locally defined or a reference to the keystore.
1837 A.7. 06 to 07
1839 o factored the tls-[client|server]-groupings into more reusable
1840 groupings.
1842 o added if-feature statements for the new "x509-certificates"
1843 feature defined in draft-ietf-netconf-trust-anchors.
1845 A.8. 07 to 08
1847 o Added a number of compatibility matrices to Section 5 (thanks
1848 Frank!)
1850 o Clarified that any configured "cipher-suite" values need to be
1851 compatible with the configured private key.
1853 A.9. 08 to 09
1855 o Updated examples to reflect update to groupings defined in the
1856 keystore draft.
1858 o Add TLS keepalives features and groupings.
1860 o Prefixed top-level TLS grouping nodes with 'tls-' and support
1861 mashups.
1863 o Updated copyright date, boilerplate template, affiliation, and
1864 folding algorithm.
1866 A.10. 09 to 10
1868 o Reformatted the YANG modules.
1870 A.11. 10 to 11
1872 o Collapsed all the inner groupings into the top-level grouping.
1874 o Added a top-level "demux container" inside the top-level grouping.
1876 o Added NACM statements and updated the Security Considerations
1877 section.
1879 o Added "presence" statements on the "keepalive" containers, as was
1880 needed to address a validation error that appeared after adding
1881 the "must" statements into the NETCONF/RESTCONF client/server
1882 modules.
1884 o Updated the boilerplate text in module-level "description"
1885 statement to match copyeditor convention.
1887 A.12. 11 to 12
1889 o In server model, made 'client-authentication' a 'presence' node
1890 indicating that the server supports client authentication.
1892 o In the server model, added a 'required-or-optional' choice to
1893 'client-authentication' to better support protocols such as
1894 RESTCONF.
1896 o In the server model, added a 'local-or-external' choice to
1897 'client-authentication' to better support consuming data models
1898 that prefer to keep client auth with client definitions than in a
1899 model principally concerned with the "transport".
1901 o In both models, removed the "demux containers", floating the
1902 nacm:default-deny-write to each descendent node, and adding a note
1903 to model designers regarding the potential need to add their own
1904 demux containers.
1906 o Fixed a couple references (section 2 --> section 3)
1908 A.13. 12 to 13
1910 o Updated to reflect changes in trust-anchors drafts (e.g., s/trust-
1911 anchors/truststore/g + s/pinned.//)
1913 A.14. 12 to 13
1915 o Removed 'container' under 'client-identity' to match server model.
1917 o Updated examples to reflect change grouping in keystore module.
1919 A.15. 13 to 14
1921 o Removed the "certificate" container from "client-identity" in the
1922 ietf-tls-client module.
1924 o Updated examples to reflect ietf-crypto-types change (e.g.,
1925 identities --> enumerations)
1927 Acknowledgements
1929 The authors would like to thank for following for lively discussions
1930 on list and in the halls (ordered by last name): Andy Bierman, Martin
1931 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
1932 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
1933 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
1935 Authors' Addresses
1937 Kent Watsen
1938 Watsen Networks
1940 EMail: kent+ietf@watsen.net
1942 Gary Wu
1943 Cisco Systems
1945 EMail: garywu@cisco.com
1947 Liang Xia
1948 Huawei
1950 EMail: frank.xialiang@huawei.com