idnits 2.17.1
draft-ietf-netconf-tls-client-server-12.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 (April 29, 2019) is 1795 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-05
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-08
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-03
-- 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: October 31, 2019 Cisco Systems
6 L. Xia
7 Huawei
8 April 29, 2019
10 YANG Groupings for TLS Clients and TLS Servers
11 draft-ietf-netconf-tls-client-server-12
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-04-29" --> 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 October 31, 2019.
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 . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . 13
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 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 44
125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
127 1. Introduction
129 This document defines three YANG 1.1 [RFC7950] modules: the first
130 defines a grouping for a generic TLS client, the second defines a
131 grouping for a generic TLS server, and the third defines identities
132 and groupings common to both the client and the server (TLS is
133 defined in [RFC5246]). It is intended that these groupings will be
134 used by applications using the TLS protocol. For instance, these
135 groupings could be used to help define the data model for an HTTPS
136 [RFC2818] server or a NETCONF over TLS [RFC7589] based server.
138 The client and server YANG modules in this document each define one
139 grouping, which is focused on just TLS-specific configuration, and
140 specifically avoids any transport-level configuration, such as what
141 ports to listen-on or connect-to. This affords applications the
142 opportunity to define their own strategy for how the underlying TCP
143 connection is established. For instance, applications supporting
144 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping"
145 grouping for the TLS parts it provides, while adding data nodes for
146 the TCP-level call-home configuration.
148 The modules defined in this document use groupings defined in
149 [I-D.ietf-netconf-keystore] enabling keys to be either locally
150 defined or a reference to globally configured values.
152 2. Terminology
154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
156 "OPTIONAL" in this document are to be interpreted as described in BCP
157 14 [RFC2119] [RFC8174] when, and only when, they appear in all
158 capitals, as shown here.
160 3. The TLS Client Model
162 3.1. Tree Diagram
164 This section provides a tree diagram [RFC8340] for the "ietf-tls-
165 client" module that does not have groupings expanded.
167 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
169 module: ietf-tls-client
171 grouping tls-client-grouping
172 +-- client-identity
173 | +-- (auth-type)?
174 | +--:(certificate)
175 | +-- certificate
176 | +---u ks:local-or-keystore-end-entity-cert-with-key-\
177 grouping
178 +-- server-authentication
179 | +-- pinned-ca-certs? ta:pinned-certificates-ref
180 | | {ta:x509-certificates}?
181 | +-- pinned-server-certs? ta:pinned-certificates-ref
182 | {ta:x509-certificates}?
183 +-- hello-params {tls-client-hello-params-config}?
184 | +---u tlscmn:hello-params-grouping
185 +-- keepalives! {tls-client-keepalives}?
186 +-- max-wait? uint16
187 +-- max-attempts? uint8
189 3.2. Example Usage
191 This section presents two examples showing the tls-client-grouping
192 populated with some data. These examples are effectively the same
193 except the first configures the client identity using a local key
194 while the second uses a key configured in a keystore. Both examples
195 are consistent with the examples presented in Section 2 of
196 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
197 [I-D.ietf-netconf-keystore].
199 The following example configures the client identity using a local
200 key:
202 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
204
206
207
208
209
210 ct:rsa2048
212 base64encodedvalue==
213 base64encodedvalue==
214 base64encodedvalue==
215
216
217
219
220
221 explicitly-trusted-server-ca-certs
223 explicitly-trusted-server-certs
225
227
228 30
229 3
230
232
234 The following example configures the client identity using a key from
235 the keystore:
237 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
239
241
242
243
244 ex-rsa-cert
245
246
248
249
250 explicitly-trusted-server-ca-certs
252 explicitly-trusted-server-certs
254
256
257 30
258 3
259
261
263 3.3. YANG Module
265 This YANG module has normative references to
266 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
268 file "ietf-tls-client@2019-04-29.yang"
269 module ietf-tls-client {
270 yang-version 1.1;
271 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
272 prefix tlsc;
274 import ietf-tls-common {
275 prefix tlscmn;
276 revision-date 2019-04-29; // stable grouping definitions
277 reference
278 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
279 }
281 import ietf-trust-anchors {
282 prefix ta;
283 reference
284 "RFC YYYY: YANG Data Model for Global Trust Anchors";
286 }
288 import ietf-keystore {
289 prefix ks;
290 reference
291 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
292 }
294 import ietf-netconf-acm {
295 prefix nacm;
296 reference
297 "RFC 8341: Network Configuration Access Control Model";
298 }
300 organization
301 "IETF NETCONF (Network Configuration) Working Group";
303 contact
304 "WG Web:
305 WG List:
306 Author: Kent Watsen
307 Author: Gary Wu ";
309 description
310 "This module defines reusable groupings for TLS clients that
311 can be used as a basis for specific TLS client instances.
313 Copyright (c) 2019 IETF Trust and the persons identified
314 as authors of the code. All rights reserved.
316 Redistribution and use in source and binary forms, with
317 or without modification, is permitted pursuant to, and
318 subject to the license terms contained in, the Simplified
319 BSD License set forth in Section 4.c of the IETF Trust's
320 Legal Provisions Relating to IETF Documents
321 (https://trustee.ietf.org/license-info).
323 This version of this YANG module is part of RFC XXXX
324 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
325 itself for full legal notices.;
327 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
328 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
329 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
330 are to be interpreted as described in BCP 14 (RFC 2119)
331 (RFC 8174) when, and only when, they appear in all
332 capitals, as shown here.";
334 revision 2019-04-29 {
335 description
336 "Initial version";
337 reference
338 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
339 }
341 // Features
343 feature tls-client-hello-params-config {
344 description
345 "TLS hello message parameters are configurable on a TLS
346 client.";
347 }
349 feature tls-client-keepalives {
350 description
351 "Per socket TLS keepalive parameters are configurable for
352 TLS clients on the server implementing this feature.";
353 }
355 // Groupings
357 grouping tls-client-grouping {
358 description
359 "A reusable grouping for configuring a TLS client without
360 any consideration for how an underlying TCP session is
361 established.
363 Note that this grouping uses fairly typical descendent
364 node names such that a stack of 'uses' statements will
365 have name conflicts. It is intended that the consuming
366 data model will resolve the issue (e.g., by wrapping
367 the 'uses' statement in a container called
368 'tls-client-parameters'). This model purposely does
369 not do this itself so as to provide maximum flexibility
370 to consuming models.";
372 container client-identity {
373 nacm:default-deny-write;
374 description
375 "The credentials used by the client to authenticate to
376 the TLS server.";
377 choice auth-type {
378 description
379 "The authentication type.";
380 container certificate {
381 uses
382 ks:local-or-keystore-end-entity-cert-with-key-grouping;
383 description
384 "A locally-defined or referenced certificate
385 to be used for client authentication.";
386 reference
387 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
388 }
389 }
390 } // container client-identity
392 container server-authentication {
393 nacm:default-deny-write;
394 must 'pinned-ca-certs or pinned-server-certs';
395 description
396 "Trusted server identities.";
397 leaf pinned-ca-certs {
398 if-feature "ta:x509-certificates";
399 type ta:pinned-certificates-ref;
400 description
401 "A reference to a list of certificate authority (CA)
402 certificates used by the TLS client to authenticate
403 TLS server certificates. A server certificate is
404 authenticated if it has a valid chain of trust to
405 a configured pinned CA certificate.";
406 }
407 leaf pinned-server-certs {
408 if-feature "ta:x509-certificates";
409 type ta:pinned-certificates-ref;
410 description
411 "A reference to a list of server certificates used by
412 the TLS client to authenticate TLS server certificates.
413 A server certificate is authenticated if it is an
414 exact match to a configured pinned server certificate.";
415 }
416 } // container server-authentication
418 container hello-params {
419 nacm:default-deny-write;
420 if-feature "tls-client-hello-params-config";
421 uses tlscmn:hello-params-grouping;
422 description
423 "Configurable parameters for the TLS hello message.";
424 } // container hello-params
426 container keepalives {
427 nacm:default-deny-write;
428 if-feature "tls-client-keepalives";
429 presence "Indicates that keepalives are enabled.";
430 description
431 "Configures the keep-alive policy, to proactively test
432 the aliveness of the TLS server. An unresponsive
433 TLS server is dropped after approximately max-wait
434 * max-attempts seconds.";
435 leaf max-wait {
436 type uint16 {
437 range "1..max";
438 }
439 units "seconds";
440 default "30";
441 description
442 "Sets the amount of time in seconds after which if
443 no data has been received from the TLS server, a
444 TLS-level message will be sent to test the
445 aliveness of the TLS server.";
446 }
447 leaf max-attempts {
448 type uint8;
449 default "3";
450 description
451 "Sets the maximum number of sequential keep-alive
452 messages that can fail to obtain a response from
453 the TLS server before assuming the TLS server is
454 no longer alive.";
455 }
456 } // container keepalives
457 } // grouping tls-client-grouping
458 }
459
461 4. The TLS Server Model
463 4.1. Tree Diagram
465 This section provides a tree diagram [RFC8340] for the "ietf-tls-
466 server" module that does not have groupings expanded.
468 module: ietf-tls-server
470 grouping tls-server-grouping
471 +-- server-identity
472 | +---u ks:local-or-keystore-end-entity-cert-with-key-grouping
473 +-- client-authentication!
474 | +-- (required-or-optional)
475 | | +--:(required)
476 | | | +-- required? empty
477 | | +--:(optional)
478 | | +-- optional? empty
479 | +-- (local-or-external)
480 | +--:(local) {local-client-auth-supported}?
481 | | +-- pinned-ca-certs?
482 | | | ta:pinned-certificates-ref
483 | | | {ta:x509-certificates}?
484 | | +-- pinned-client-certs?
485 | | ta:pinned-certificates-ref
486 | | {ta:x509-certificates}?
487 | +--:(external) {external-client-auth-supported}?
488 | +-- client-auth-defined-elsewhere? empty
489 +-- hello-params {tls-server-hello-params-config}?
490 | +---u tlscmn:hello-params-grouping
491 +-- keepalives! {tls-server-keepalives}?
492 +-- max-wait? uint16
493 +-- max-attempts? uint8
495 4.2. Example Usage
497 This section presents two examples showing the tls-server-grouping
498 populated with some data. These examples are effectively the same
499 except the first configures the server identity using a local key
500 while the second uses a key configured in a keystore. Both examples
501 are consistent with the examples presented in Section 2 of
502 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
503 [I-D.ietf-netconf-keystore].
505 The following example configures the server identity using a local
506 key:
508 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
510
512
513
514
515 ct:rsa2048
517 base64encodedvalue==
518 base64encodedvalue==
519 base64encodedvalue==
520
521
523
524
525
526 explicitly-trusted-client-ca-certs
528 explicitly-trusted-client-certs
530
532
534 The following example configures the server identity using a key from
535 the keystore:
537 =========== NOTE: '\' line wrapping per BCP XX (RFC XXXX) ===========
539
541
542
543 ex-rsa-cert
544
546
547
548
549 explicitly-trusted-client-ca-certs
551 explicitly-trusted-client-certs
553
555
557 4.3. YANG Module
559 This YANG module has a normative references to [RFC5246],
560 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
562 file "ietf-tls-server@2019-04-29.yang"
563 module ietf-tls-server {
564 yang-version 1.1;
565 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
566 prefix tlss;
568 import ietf-tls-common {
569 prefix tlscmn;
570 revision-date 2019-04-29; // stable grouping definitions
571 reference
572 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
573 }
575 import ietf-trust-anchors {
576 prefix ta;
577 reference
578 "RFC YYYY: YANG Data Model for Global Trust Anchors";
579 }
581 import ietf-keystore {
582 prefix ks;
583 reference
584 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
585 }
587 import ietf-netconf-acm {
588 prefix nacm;
589 reference
590 "RFC 8341: Network Configuration Access Control Model";
591 }
593 organization
594 "IETF NETCONF (Network Configuration) Working Group";
596 contact
597 "WG Web:
598 WG List:
599 Author: Kent Watsen
600 Author: Gary Wu ";
602 description
603 "This module defines reusable groupings for TLS servers that
604 can be used as a basis for specific TLS server instances.
606 Copyright (c) 2019 IETF Trust and the persons identified
607 as authors of the code. All rights reserved.
609 Redistribution and use in source and binary forms, with
610 or without modification, is permitted pursuant to, and
611 subject to the license terms contained in, the Simplified
612 BSD License set forth in Section 4.c of the IETF Trust's
613 Legal Provisions Relating to IETF Documents
614 (https://trustee.ietf.org/license-info).
616 This version of this YANG module is part of RFC XXXX
617 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
618 itself for full legal notices.;
620 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
621 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
622 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
623 are to be interpreted as described in BCP 14 (RFC 2119)
624 (RFC 8174) when, and only when, they appear in all
625 capitals, as shown here.";
627 revision 2019-04-29 {
628 description
629 "Initial version";
630 reference
631 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
632 }
634 // Features
636 feature tls-server-hello-params-config {
637 description
638 "TLS hello message parameters are configurable on a TLS
639 server.";
640 }
642 feature tls-server-keepalives {
643 description
644 "Per socket TLS keepalive parameters are configurable for
645 TLS servers on the server implementing this feature.";
646 }
648 feature local-client-auth-supported {
649 description
650 "Indicates that the TLS server supports local
651 configuration of client credentials.";
652 }
653 feature external-client-auth-supported {
654 description
655 "Indicates that the TLS server supports external
656 configuration of client credentials.";
657 }
659 // Groupings
661 grouping tls-server-grouping {
662 description
663 "A reusable grouping for configuring a TLS server without
664 any consideration for how underlying TCP sessions are
665 established.
667 Note that this grouping uses fairly typical descendent
668 node names such that a stack of 'uses' statements will
669 have name conflicts. It is intended that the consuming
670 data model will resolve the issue (e.g., by wrapping
671 the 'uses' statement in a container called
672 'tls-server-parameters'). This model purposely does
673 not do this itself so as to provide maximum flexibility
674 to consuming models.";
676 container server-identity { // FIXME: what about PSKs?
677 nacm:default-deny-write;
678 description
679 "A locally-defined or referenced end-entity certificate,
680 including any configured intermediate certificates, the
681 TLS server will present when establishing a TLS connection
682 in its Certificate message, as defined in Section 7.4.2
683 in RFC 5246.";
684 reference
685 "RFC 5246:
686 The Transport Layer Security (TLS) Protocol Version 1.2
687 RFC ZZZZ:
688 YANG Data Model for a 'Keystore' Mechanism";
689 uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
690 } // container server-identity
692 container client-authentication { // FIXME: what about PSKs?
693 nacm:default-deny-write;
694 presence
695 "Indicates that certificate based client authentication
696 is supported (i.e., the server will request that the
697 client send a certificate).";
699 description
700 "Specifies if TLS client authentication is required or
701 optional, and specifies if the certificates needed to
702 authenticate the TLS client are configured locally or
703 externally. If configured locally, the data model
704 enables both trust anchors and end-entity certificate
705 to be set.";
706 choice required-or-optional {
707 mandatory true; // or default to 'required' ?
708 description
709 "Indicates if TLS-level client authentication is required
710 or optional. This is necessary for some protocols (e.g.,
711 RESTCONF) the may optionally authenticate a client via
712 TLS-level authentication, HTTP-level authentication, or
713 both simultaneously).";
714 leaf required {
715 type empty;
716 description
717 "Indicates that TLS-level client authentication is
718 required.";
719 }
720 leaf optional {
721 type empty;
722 description
723 "Indicates that TLS-level client authentication is
724 optional.";
725 }
726 }
727 choice local-or-external {
728 mandatory true;
729 description
730 "Indicates if the certificates needed to authenticate
731 the client are configured locally or externally. The
732 need to support external configuration for client
733 authentication stems from the desire to support
734 consuming data models that prefer to place client
735 authentication with client definitions, rather then
736 in a data model principally concerned with configuring
737 the transport.";
738 case local {
739 if-feature "local-client-auth-supported";
740 description
741 "The certificates needed to authenticate the clients
742 are configured locally.";
743 leaf pinned-ca-certs {
744 if-feature "ta:x509-certificates";
745 type ta:pinned-certificates-ref;//FIXME: local-or-remote?
746 description
747 "A reference to a list of certificate authority (CA)
748 certificates used by the TLS server to authenticate
749 TLS client certificates. A client certificate is
750 authenticated if it has a valid chain of trust to
751 a configured pinned CA certificate.";
752 reference
753 "RFC YYYY: YANG Data Model for Global Trust Anchors";
754 }
755 leaf pinned-client-certs {
756 if-feature "ta:x509-certificates";
757 type ta:pinned-certificates-ref;//FIXME: local-or-remote?
758 description
759 "A reference to a list of client certificates
760 used by the TLS server to authenticate TLS
761 client certificates. A clients certificate
762 is authenticated if it is an exact match to
763 a configured pinned client certificate.";
764 reference
765 "RFC YYYY: YANG Data Model for Global Trust Anchors";
766 }
767 }
768 case external {
769 if-feature "external-client-auth-supported";
770 description
771 "The certificates needed to authenticate the clients
772 are configured externally.";
773 leaf client-auth-defined-elsewhere {
774 type empty;
775 description
776 "Indicates that certificates needed to authenticate
777 clients are configured elsewhere.";
778 }
779 }
780 } // choice local-or-external
781 } // container client-authentication
783 container hello-params {
784 nacm:default-deny-write;
785 if-feature "tls-server-hello-params-config";
786 uses tlscmn:hello-params-grouping;
787 description
788 "Configurable parameters for the TLS hello message.";
789 } // container hello-params
791 container keepalives {
792 nacm:default-deny-write;
793 if-feature "tls-server-keepalives";
794 presence "Indicates that keepalives are enabled.";
795 description
796 "Configures the keep-alive policy, to proactively test
797 the aliveness of the TLS client. An unresponsive
798 TLS client is dropped after approximately max-wait
799 * max-attempts seconds.";
800 leaf max-wait {
801 type uint16 {
802 range "1..max";
803 }
804 units "seconds";
805 default "30";
806 description
807 "Sets the amount of time in seconds after which if
808 no data has been received from the TLS client, a
809 TLS-level message will be sent to test the
810 aliveness of the TLS client.";
811 }
812 leaf max-attempts {
813 type uint8;
814 default "3";
815 description
816 "Sets the maximum number of sequential keep-alive
817 messages that can fail to obtain a response from
818 the TLS client before assuming the TLS client is
819 no longer alive.";
820 }
821 } // container keepalives
822 } // grouping tls-server-grouping
823 }
824
826 5. The TLS Common Model
828 The TLS common model presented in this section contains identities
829 and groupings common to both TLS clients and TLS servers. The hello-
830 params-grouping can be used to configure the list of TLS algorithms
831 permitted by the TLS client or TLS server. The lists of algorithms
832 are ordered such that, if multiple algorithms are permitted by the
833 client, the algorithm that appears first in its list that is also
834 permitted by the server is used for the TLS transport layer
835 connection. The ability to restrict the algorithms allowed is
836 provided in this grouping for TLS clients and TLS servers that are
837 capable of doing so and may serve to make TLS clients and TLS servers
838 compliant with local security policies. This model supports both
839 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446].
841 TLS 1.2 and TLS 1.3 have different ways defining their own supported
842 cryptographic algorithms, see TLS and DTLS IANA registries page
843 (https://www.iana.org/assignments/tls-parameters/tls-
844 parameters.xhtml):
846 o TLS 1.2 defines four categories of registries for cryptographic
847 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS
848 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the
849 role of combining all of them into one set, as each value of the
850 set represents a unique and feasible combination of all the
851 cryptographic algorithms, and thus the other three registry
852 categories do not need to be considered here. In this document,
853 the TLS common model only chooses those TLS1.2 algorithms in TLS
854 Cipher Suites which are marked as recommended:
855 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
856 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
857 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
858 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen
859 algorithms are enumerated in Table 1-1 below;
861 o TLS 1.3 defines its supported algorithms differently. Firstly, it
862 defines three categories of registries for cryptographic
863 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported
864 Groups. Secondly, all three of these categories are useful, since
865 they represent different parts of all the supported algorithms
866 respectively. Thus, all of these registries categories are
867 considered here. In this draft, the TLS common model chooses only
868 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of
869 [RFC8446].
871 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites
872 part of the hello-params-grouping should include three parameters for
873 configuring its permitted TLS algorithms, which are: TLS Cipher
874 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2
875 only uses TLS Cipher Suites.
877 [I-D.ietf-netconf-crypto-types] defines six categories of
878 cryptographic algorithms (hash-algorithm, symmetric-key-encryption-
879 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm,
880 signature-algorithm, key-negotiation-algorithm) and lists several
881 widely accepted algorithms for each of them. The TLS client and
882 server models use one or more of these algorithms. The following
883 tables are provided, in part to define the subset of algorithms
884 defined in the crypto-types model used by TLS, and in part to ensure
885 compatibility of configured TLS cryptographic parameters for
886 configuring its permitted TLS algorithms:
888 +-----------------------------------------------+---------+
889 | ciper-suites in hello-params-grouping | HASH |
890 +-----------------------------------------------+---------+
891 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
892 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
893 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
894 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
895 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 |
896 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 |
897 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
898 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
899 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 |
900 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 |
901 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 |
902 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 |
903 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
904 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
905 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
906 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
907 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
908 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
909 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
910 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 |
911 +-----------------------------------------------+---------+
913 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping
914 to hash-algorithm
916 +--------------------------------------------- +---------------------+
917 | ciper-suites in hello-params-grouping | symmetric |
918 | | |
919 +--------------------------------------------- +---------------------+
920 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
921 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
922 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
923 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
924 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
925 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
926 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
927 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
928 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm |
929 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm |
930 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm |
931 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm |
932 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
933 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305|
934 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
935 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
936 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
937 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
938 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
939 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm |
940 +--------------------------------------------- +---------------------+
942 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping
943 to symmetric-key-encryption-algorithm
945 +--------------------------------------------- +---------------------+
946 | ciper-suites in hello-params-grouping | MAC |
947 | | |
948 +--------------------------------------------- +---------------------+
949 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
950 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
951 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
952 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
953 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
954 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
955 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
956 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
957 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm |
958 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm |
959 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm |
960 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm |
961 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
962 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305|
963 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
964 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
965 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
966 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
967 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
968 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm |
969 +--------------------------------------------- +---------------------+
971 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping
972 to MAC-algorithm
974 +----------------------------------------------+----------------------+
975 |ciper-suites in hello-params-grouping | signature |
976 +--------------------------------------------- +----------------------+
977 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
978 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
979 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
980 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
981 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256|
982 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384|
983 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
984 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
985 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 |
986 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 |
987 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A |
988 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A |
989 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
990 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256|
991 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
992 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
993 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
994 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
995 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
996 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A |
997 +----------------------------------------------+----------------------+
999 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping
1000 to signature-algorithm
1002 +----------------------------------------------+-----------------------+
1003 |ciper-suites in hello-params-grouping | key-negotiation |
1004 +----------------------------------------------+-----------------------+
1005 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... |
1006 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... |
1007 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...|
1008 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...|
1009 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
1010 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
1011 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
1012 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
1013 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... |
1014 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... |
1015 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...|
1016 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...|
1017 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... |
1018 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... |
1019 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... |
1020 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...|
1021 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...|
1022 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...|
1023 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...|
1024 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...|
1025 +----------------------------------------------+-----------------------+
1027 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping
1028 to key-negotiation-algorithm
1030 +------------------------------+---------+
1031 | ciper-suites in hello | HASH |
1032 | -params-grouping | |
1033 +------------------------------+---------+
1034 | TLS_AES_128_GCM_SHA256 | sha-256 |
1035 | TLS_AES_256_GCM_SHA384 | sha-384 |
1036 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 |
1037 | TLS_AES_128_CCM_SHA256 | sha-256 |
1038 +------------------------------+---------+
1040 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping
1041 to hash-algorithm
1043 +------------------------------+-----------------------+
1044 | ciper-suites in hello | symmetric |
1045 | -params-grouping | |
1046 +------------------------------+-----------------------+
1047 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm |
1048 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm |
1049 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 |
1050 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm |
1051 +------------------------------+-----------------------+
1053 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping
1054 to symmetric-key--encryption-algorithm
1056 +------------------------------+-----------------------+
1057 | ciper-suites in hello | symmetric |
1058 | -params-grouping | |
1059 +------------------------------+-----------------------+
1060 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm |
1061 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm |
1062 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 |
1063 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm |
1064 +------------------------------+-----------------------+
1066 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping
1067 to MAC-algorithm
1069 +----------------------------+-------------------------+
1070 |signatureScheme in hello | signature |
1071 | -params-grouping | |
1072 +----------------------------+-------------------------+
1073 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 |
1074 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 |
1075 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 |
1076 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 |
1077 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 |
1078 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 |
1079 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 |
1080 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 |
1081 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 |
1082 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 |
1083 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 |
1084 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 |
1085 | ed25519 | ed25519 |
1086 | ed448 | ed448 |
1087 +----------------------------+-------------------------+
1089 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme
1090 mapping to signature-algorithm
1092 +----------------------------+-------------------------+
1093 |supported Groups in hello | key-negotiation |
1094 | -params-grouping | |
1095 +----------------------------+-------------------------+
1096 | dhe-ffdhe2048 | dhe-ffdhe2048 |
1097 | dhe-ffdhe3072 | dhe-ffdhe3072 |
1098 | dhe-ffdhe4096 | dhe-ffdhe4096 |
1099 | dhe-ffdhe6144 | dhe-ffdhe6144 |
1100 | dhe-ffdhe8192 | dhe-ffdhe8192 |
1101 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 |
1102 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 |
1103 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 |
1104 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 |
1105 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 |
1106 | ecdhe-secp256r1 | ecdhe-secp256r1 |
1107 | ecdhe-secp384r1 | ecdhe-secp384r1 |
1108 | ecdhe-secp521r1 | ecdhe-secp521r1 |
1109 | ecdhe-x25519 | ecdhe-x25519 |
1110 | ecdhe-x448 | ecdhe-x448 |
1111 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 |
1112 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 |
1113 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 |
1114 | psk-ecdhe-x25519 | psk-ecdhe-x25519 |
1115 | psk-ecdhe-x448 | psk-ecdhe-x448 |
1116 +----------------------------+-------------------------+
1118 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups
1119 mapping to key-negotiation-algorithm
1121 Note that in Table 1-5:
1123 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe-
1124 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192;
1126 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048,
1127 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe-
1128 ffdhe8192;
1130 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1,
1131 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448;
1133 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe-
1134 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe-
1135 x25519, psk-ecdhe-x448.
1137 Features are defined for algorithms that are OPTIONAL or are not
1138 widely supported by popular implementations. Note that the list of
1139 algorithms is not exhaustive.
1141 5.1. Tree Diagram
1143 The following tree diagram [RFC8340] provides an overview of the data
1144 model for the "ietf-tls-common" module.
1146 module: ietf-tls-common
1148 grouping hello-params-grouping
1149 +-- tls-versions
1150 | +-- tls-version* identityref
1151 +-- cipher-suites
1152 +-- cipher-suite* identityref
1154 5.2. Example Usage
1156 This section shows how it would appear if the transport-params-
1157 grouping were populated with some data.
1159
1162
1163 tlscmn:tls-1.1
1164 tlscmn:tls-1.2
1165
1166
1167 tlscmn:dhe-rsa-with-aes-128-cbc-sha
1168 tlscmn:rsa-with-aes-128-cbc-sha
1169 tlscmn:rsa-with-3des-ede-cbc-sha
1170
1171
1173 5.3. YANG Module
1175 This YANG module has a normative references to [RFC4346], [RFC5246],
1176 [RFC5288], [RFC5289], and [RFC8422].
1178 This YANG module has a informative references to [RFC2246],
1179 [RFC4346], [RFC5246], and [RFC8446].
1181 file "ietf-tls-common@2019-04-29.yang"
1182 module ietf-tls-common {
1183 yang-version 1.1;
1184 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
1185 prefix tlscmn;
1187 organization
1188 "IETF NETCONF (Network Configuration) Working Group";
1190 contact
1191 "WG Web:
1192 WG List:
1193 Author: Kent Watsen
1194 Author: Gary Wu ";
1196 description
1197 "This module defines a common features, identities, and
1198 groupings for Transport Layer Security (TLS).
1200 Copyright (c) 2019 IETF Trust and the persons identified
1201 as authors of the code. All rights reserved.
1203 Redistribution and use in source and binary forms, with
1204 or without modification, is permitted pursuant to, and
1205 subject to the license terms contained in, the Simplified
1206 BSD License set forth in Section 4.c of the IETF Trust's
1207 Legal Provisions Relating to IETF Documents
1208 (https://trustee.ietf.org/license-info).
1210 This version of this YANG module is part of RFC XXXX
1211 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC
1212 itself for full legal notices.;
1214 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1215 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1216 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1217 are to be interpreted as described in BCP 14 (RFC 2119)
1218 (RFC 8174) when, and only when, they appear in all
1219 capitals, as shown here.";
1221 revision 2019-04-29 {
1222 description
1223 "Initial version";
1224 reference
1225 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1226 }
1228 // Features
1230 feature tls-1_0 {
1231 description
1232 "TLS Protocol Version 1.0 is supported.";
1233 reference
1234 "RFC 2246: The TLS Protocol Version 1.0";
1235 }
1237 feature tls-1_1 {
1238 description
1239 "TLS Protocol Version 1.1 is supported.";
1240 reference
1241 "RFC 4346: The Transport Layer Security (TLS) Protocol
1242 Version 1.1";
1243 }
1245 feature tls-1_2 {
1246 description
1247 "TLS Protocol Version 1.2 is supported.";
1248 reference
1249 "RFC 5246: The Transport Layer Security (TLS) Protocol
1250 Version 1.2";
1251 }
1253 feature tls-1_3 {
1254 description
1255 "TLS Protocol Version 1.2 is supported.";
1256 reference
1257 "RFC 8446: The Transport Layer Security (TLS) Protocol
1258 Version 1.3";
1259 }
1261 feature tls-ecc {
1262 description
1263 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
1264 reference
1265 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1266 for Transport Layer Security (TLS)";
1267 }
1269 feature tls-dhe {
1270 description
1271 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
1272 reference
1273 "RFC 5246: The Transport Layer Security (TLS) Protocol
1274 Version 1.2";
1275 }
1277 feature tls-3des {
1278 description
1279 "The Triple-DES block cipher is supported for TLS.";
1280 reference
1281 "RFC 5246: The Transport Layer Security (TLS) Protocol
1282 Version 1.2";
1283 }
1285 feature tls-gcm {
1286 description
1287 "The Galois/Counter Mode authenticated encryption mode is
1288 supported for TLS.";
1289 reference
1290 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
1291 TLS";
1292 }
1294 feature tls-sha2 {
1295 description
1296 "The SHA2 family of cryptographic hash functions is supported
1297 for TLS.";
1298 reference
1299 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
1300 }
1302 // Identities
1304 identity tls-version-base {
1305 description
1306 "Base identity used to identify TLS protocol versions.";
1307 }
1309 identity tls-1.0 {
1310 base tls-version-base;
1311 if-feature "tls-1_0";
1312 description
1313 "TLS Protocol Version 1.0.";
1314 reference
1315 "RFC 2246: The TLS Protocol Version 1.0";
1316 }
1318 identity tls-1.1 {
1319 base tls-version-base;
1320 if-feature "tls-1_1";
1321 description
1322 "TLS Protocol Version 1.1.";
1323 reference
1324 "RFC 4346: The Transport Layer Security (TLS) Protocol
1325 Version 1.1";
1326 }
1328 identity tls-1.2 {
1329 base tls-version-base;
1330 if-feature "tls-1_2";
1331 description
1332 "TLS Protocol Version 1.2.";
1333 reference
1334 "RFC 5246: The Transport Layer Security (TLS) Protocol
1335 Version 1.2";
1336 }
1338 identity cipher-suite-base {
1339 description
1340 "Base identity used to identify TLS cipher suites.";
1341 }
1343 identity rsa-with-aes-128-cbc-sha {
1344 base cipher-suite-base;
1345 description
1346 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
1347 reference
1348 "RFC 5246: The Transport Layer Security (TLS) Protocol
1349 Version 1.2";
1350 }
1352 identity rsa-with-aes-256-cbc-sha {
1353 base cipher-suite-base;
1354 description
1355 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
1356 reference
1357 "RFC 5246: The Transport Layer Security (TLS) Protocol
1358 Version 1.2";
1359 }
1361 identity rsa-with-aes-128-cbc-sha256 {
1362 base cipher-suite-base;
1363 if-feature "tls-sha2";
1364 description
1365 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
1366 reference
1367 "RFC 5246: The Transport Layer Security (TLS) Protocol
1368 Version 1.2";
1369 }
1371 identity rsa-with-aes-256-cbc-sha256 {
1372 base cipher-suite-base;
1373 if-feature "tls-sha2";
1374 description
1375 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
1376 reference
1377 "RFC 5246: The Transport Layer Security (TLS) Protocol
1378 Version 1.2";
1379 }
1381 identity dhe-rsa-with-aes-128-cbc-sha {
1382 base cipher-suite-base;
1383 if-feature "tls-dhe";
1384 description
1385 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
1386 reference
1387 "RFC 5246: The Transport Layer Security (TLS) Protocol
1388 Version 1.2";
1389 }
1391 identity dhe-rsa-with-aes-256-cbc-sha {
1392 base cipher-suite-base;
1393 if-feature "tls-dhe";
1394 description
1395 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
1396 reference
1397 "RFC 5246: The Transport Layer Security (TLS) Protocol
1398 Version 1.2";
1399 }
1401 identity dhe-rsa-with-aes-128-cbc-sha256 {
1402 base cipher-suite-base;
1403 if-feature "tls-dhe and tls-sha2";
1404 description
1405 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
1406 reference
1407 "RFC 5246: The Transport Layer Security (TLS) Protocol
1408 Version 1.2";
1409 }
1411 identity dhe-rsa-with-aes-256-cbc-sha256 {
1412 base cipher-suite-base;
1413 if-feature "tls-dhe and tls-sha2";
1414 description
1415 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
1416 reference
1417 "RFC 5246: The Transport Layer Security (TLS) Protocol
1418 Version 1.2";
1419 }
1421 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
1422 base cipher-suite-base;
1423 if-feature "tls-ecc and tls-sha2";
1424 description
1425 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
1426 reference
1427 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1428 SHA-256/384 and AES Galois Counter Mode (GCM)";
1429 }
1430 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
1431 base cipher-suite-base;
1432 if-feature "tls-ecc and tls-sha2";
1433 description
1434 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
1435 reference
1436 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1437 SHA-256/384 and AES Galois Counter Mode (GCM)";
1438 }
1440 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
1441 base cipher-suite-base;
1442 if-feature "tls-ecc and tls-sha2";
1443 description
1444 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
1445 reference
1446 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1447 SHA-256/384 and AES Galois Counter Mode (GCM)";
1448 }
1450 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
1451 base cipher-suite-base;
1452 if-feature "tls-ecc and tls-sha2";
1453 description
1454 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
1455 reference
1456 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1457 SHA-256/384 and AES Galois Counter Mode (GCM)";
1458 }
1460 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
1461 base cipher-suite-base;
1462 if-feature "tls-ecc and tls-gcm and tls-sha2";
1463 description
1464 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
1465 reference
1466 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1467 SHA-256/384 and AES Galois Counter Mode (GCM)";
1468 }
1470 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
1471 base cipher-suite-base;
1472 if-feature "tls-ecc and tls-gcm and tls-sha2";
1473 description
1474 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
1475 reference
1476 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1477 SHA-256/384 and AES Galois Counter Mode (GCM)";
1479 }
1481 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
1482 base cipher-suite-base;
1483 if-feature "tls-ecc and tls-gcm and tls-sha2";
1484 description
1485 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
1486 reference
1487 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1488 SHA-256/384 and AES Galois Counter Mode (GCM)";
1489 }
1491 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
1492 base cipher-suite-base;
1493 if-feature "tls-ecc and tls-gcm and tls-sha2";
1494 description
1495 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
1496 reference
1497 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1498 SHA-256/384 and AES Galois Counter Mode (GCM)";
1499 }
1501 identity rsa-with-3des-ede-cbc-sha {
1502 base cipher-suite-base;
1503 if-feature "tls-3des";
1504 description
1505 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
1506 reference
1507 "RFC 5246: The Transport Layer Security (TLS) Protocol
1508 Version 1.2";
1509 }
1511 identity ecdhe-rsa-with-3des-ede-cbc-sha {
1512 base cipher-suite-base;
1513 if-feature "tls-ecc and tls-3des";
1514 description
1515 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
1516 reference
1517 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1518 for Transport Layer Security (TLS)";
1519 }
1521 identity ecdhe-rsa-with-aes-128-cbc-sha {
1522 base cipher-suite-base;
1523 if-feature "tls-ecc";
1524 description
1525 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
1526 reference
1527 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1528 for Transport Layer Security (TLS)";
1529 }
1531 identity ecdhe-rsa-with-aes-256-cbc-sha {
1532 base cipher-suite-base;
1533 if-feature "tls-ecc";
1534 description
1535 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1536 reference
1537 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1538 for Transport Layer Security (TLS)";
1539 }
1541 // Groupings
1543 grouping hello-params-grouping {
1544 description
1545 "A reusable grouping for TLS hello message parameters.";
1546 reference
1547 "RFC 5246: The Transport Layer Security (TLS) Protocol
1548 Version 1.2";
1549 container tls-versions {
1550 description
1551 "Parameters regarding TLS versions.";
1552 leaf-list tls-version {
1553 type identityref {
1554 base tls-version-base;
1555 }
1556 description
1557 "Acceptable TLS protocol versions.
1559 If this leaf-list is not configured (has zero elements)
1560 the acceptable TLS protocol versions are implementation-
1561 defined.";
1562 }
1563 }
1564 container cipher-suites {
1565 description
1566 "Parameters regarding cipher suites.";
1567 leaf-list cipher-suite {
1568 type identityref {
1569 base cipher-suite-base;
1570 }
1571 ordered-by user;
1572 description
1573 "Acceptable cipher suites in order of descending
1574 preference. The configured host key algorithms should
1575 be compatible with the algorithm used by the configured
1576 private key. Please see Section 5 of RFC XXXX for
1577 valid combinations.
1579 If this leaf-list is not configured (has zero elements)
1580 the acceptable cipher suites are implementation-
1581 defined.";
1582 reference
1583 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1584 }
1585 }
1586 }
1587 }
1588
1590 6. Security Considerations
1592 The YANG modules defined in this document are designed to be accessed
1593 via YANG based management protocols, such as NETCONF [RFC6241] and
1594 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1595 implement secure transport layers (e.g., SSH, TLS) with mutual
1596 authentication.
1598 The NETCONF access control model (NACM) [RFC8341] provides the means
1599 to restrict access for particular users to a pre-configured subset of
1600 all available protocol operations and content.
1602 Since the modules in this document only define groupings, these
1603 considerations are primarily for the designers of other modules that
1604 use these groupings.
1606 There are a number of data nodes defined in the YANG modules that are
1607 writable/creatable/deletable (i.e., config true, which is the
1608 default). These data nodes may be considered sensitive or vulnerable
1609 in some network environments. Write operations (e.g., edit-config)
1610 to these data nodes without proper protection can have a negative
1611 effect on network operations. These are the subtrees and data nodes
1612 and their sensitivity/vulnerability:
1614 *: The entire subtree defined by the grouping statement in both
1615 the "ietf-ssh-client" and "ietf-ssh-server" modules is
1616 sensitive to write operations. For instance, the addition or
1617 removal of references to keys, certificates, trusted anchors,
1618 etc., or even the modification of transport or keepalive
1619 parameters can dramatically alter the implemented security
1620 policy. For this reason, this node is protected the NACM
1621 extension "default-deny-write".
1623 Some of the readable data nodes in the YANG modules may be considered
1624 sensitive or vulnerable in some network environments. It is thus
1625 important to control read access (e.g., via get, get-config, or
1626 notification) to these data nodes. These are the subtrees and data
1627 nodes and their sensitivity/vulnerability:
1629 /tls-client-parameters/client-identity/: This subtree in the
1630 "ietf-tls-client" module contains nodes that are additionally
1631 sensitive to read operations such that, in normal use cases,
1632 they should never be returned to a client. Some of these nodes
1633 (i.e., public-key/local-definition/private-key and certificate/
1634 local-definition/private-key) are already protected by the NACM
1635 extension "default-deny-all" set in the "grouping" statements
1636 defined in [I-D.ietf-netconf-crypto-types].
1638 /tls-server-parameters/server-identity/: This subtree in the
1639 "ietf-tls-server" module contains nodes that are additionally
1640 sensitive to read operations such that, in normal use cases,
1641 they should never be returned to a client. All of these nodes
1642 (i.e., host-key/public-key/local-definition/private-key and
1643 host-key/certificate/local-definition/private-key) are already
1644 protected by the NACM extension "default-deny-all" set in the
1645 "grouping" statements defined in
1646 [I-D.ietf-netconf-crypto-types].
1648 Some of the operations in this YANG module may be considered
1649 sensitive or vulnerable in some network environments. It is thus
1650 important to control access to these operations. These are the
1651 operations and their sensitivity/vulnerability:
1653 *: The groupings defined in this document include "action"
1654 statements that come from groupings defined in
1655 [I-D.ietf-netconf-crypto-types]. Please consult that document
1656 for the security considerations of the "action" statements
1657 defined by the "grouping" statements defined in this document.
1659 7. IANA Considerations
1661 7.1. The IETF XML Registry
1663 This document registers three URIs in the "ns" subregistry of the
1664 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
1665 following registrations are requested:
1667 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1668 Registrant Contact: The NETCONF WG of the IETF.
1669 XML: N/A, the requested URI is an XML namespace.
1671 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1672 Registrant Contact: The NETCONF WG of the IETF.
1673 XML: N/A, the requested URI is an XML namespace.
1675 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1676 Registrant Contact: The NETCONF WG of the IETF.
1677 XML: N/A, the requested URI is an XML namespace.
1679 7.2. The YANG Module Names Registry
1681 This document registers three YANG modules in the YANG Module Names
1682 registry [RFC6020]. Following the format in [RFC6020], the following
1683 registrations are requested:
1685 name: ietf-tls-client
1686 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1687 prefix: tlsc
1688 reference: RFC XXXX
1690 name: ietf-tls-server
1691 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1692 prefix: tlss
1693 reference: RFC XXXX
1695 name: ietf-tls-common
1696 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1697 prefix: tlscmn
1698 reference: RFC XXXX
1700 8. References
1702 8.1. Normative References
1704 [I-D.ietf-netconf-crypto-types]
1705 Watsen, K. and H. Wang, "Common YANG Data Types for
1706 Cryptography", draft-ietf-netconf-crypto-types-05 (work in
1707 progress), March 2019.
1709 [I-D.ietf-netconf-keystore]
1710 Watsen, K., "YANG Data Model for a Centralized Keystore
1711 Mechanism", draft-ietf-netconf-keystore-08 (work in
1712 progress), March 2019.
1714 [I-D.ietf-netconf-trust-anchors]
1715 Watsen, K., "YANG Data Model for Global Trust Anchors",
1716 draft-ietf-netconf-trust-anchors-03 (work in progress),
1717 March 2019.
1719 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1720 Requirement Levels", BCP 14, RFC 2119,
1721 DOI 10.17487/RFC2119, March 1997,
1722 .
1724 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1725 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1726 DOI 10.17487/RFC5288, August 2008,
1727 .
1729 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1730 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1731 DOI 10.17487/RFC5289, August 2008,
1732 .
1734 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1735 the Network Configuration Protocol (NETCONF)", RFC 6020,
1736 DOI 10.17487/RFC6020, October 2010,
1737 .
1739 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1740 NETCONF Protocol over Transport Layer Security (TLS) with
1741 Mutual X.509 Authentication", RFC 7589,
1742 DOI 10.17487/RFC7589, June 2015,
1743 .
1745 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1746 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1747 .
1749 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1750 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1751 May 2017, .
1753 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1754 Access Control Model", STD 91, RFC 8341,
1755 DOI 10.17487/RFC8341, March 2018,
1756 .
1758 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
1759 Curve Cryptography (ECC) Cipher Suites for Transport Layer
1760 Security (TLS) Versions 1.2 and Earlier", RFC 8422,
1761 DOI 10.17487/RFC8422, August 2018,
1762 .
1764 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1765 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1766 .
1768 8.2. Informative References
1770 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1771 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1772 .
1774 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1775 DOI 10.17487/RFC2818, May 2000,
1776 .
1778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1779 DOI 10.17487/RFC3688, January 2004,
1780 .
1782 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1783 (TLS) Protocol Version 1.1", RFC 4346,
1784 DOI 10.17487/RFC4346, April 2006,
1785 .
1787 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1788 (TLS) Protocol Version 1.2", RFC 5246,
1789 DOI 10.17487/RFC5246, August 2008,
1790 .
1792 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1793 and A. Bierman, Ed., "Network Configuration Protocol
1794 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1795 .
1797 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1798 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1799 .
1801 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1802 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1803 .
1805 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1806 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1807 .
1809 Appendix A. Change Log
1811 A.1. 00 to 01
1813 o Noted that '0.0.0.0' and '::' might have special meanings.
1815 o Renamed "keychain" to "keystore".
1817 A.2. 01 to 02
1819 o Removed the groupings containing transport-level configuration.
1820 Now modules contain only the transport-independent groupings.
1822 o Filled in previously incomplete 'ietf-tls-client' module.
1824 o Added cipher suites for various algorithms into new 'ietf-tls-
1825 common' module.
1827 A.3. 02 to 03
1829 o Added a 'must' statement to container 'server-auth' asserting that
1830 at least one of the various auth mechanisms must be specified.
1832 o Fixed description statement for leaf 'trusted-ca-certs'.
1834 A.4. 03 to 04
1836 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
1838 o Updated leafref paths to point to new keystore path
1840 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
1841 'tlscmn'.
1843 o Added TLS protocol verions 1.0 and 1.1.
1845 o Made author lists consistent
1847 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
1849 o Updated YANG to use typedefs around leafrefs to common keystore
1850 paths
1852 o Now inlines key and certificates (no longer a leafref to keystore)
1854 A.5. 04 to 05
1856 o Merged changes from co-author.
1858 A.6. 05 to 06
1860 o Updated to use trust anchors from trust-anchors draft (was
1861 keystore draft)
1863 o Now Uses new keystore grouping enabling asymmetric key to be
1864 either locally defined or a reference to the keystore.
1866 A.7. 06 to 07
1868 o factored the tls-[client|server]-groupings into more reusable
1869 groupings.
1871 o added if-feature statements for the new "x509-certificates"
1872 feature defined in draft-ietf-netconf-trust-anchors.
1874 A.8. 07 to 08
1876 o Added a number of compatibility matrices to Section 5 (thanks
1877 Frank!)
1879 o Clarified that any configured "cipher-suite" values need to be
1880 compatible with the configured private key.
1882 A.9. 08 to 09
1884 o Updated examples to reflect update to groupings defined in the
1885 keystore draft.
1887 o Add TLS keepalives features and groupings.
1889 o Prefixed top-level TLS grouping nodes with 'tls-' and support
1890 mashups.
1892 o Updated copyright date, boilerplate template, affiliation, and
1893 folding algorithm.
1895 A.10. 09 to 10
1897 o Reformatted the YANG modules.
1899 A.11. 10 to 11
1901 o Collapsed all the inner groupings into the top-level grouping.
1903 o Added a top-level "demux container" inside the top-level grouping.
1905 o Added NACM statements and updated the Security Considerations
1906 section.
1908 o Added "presence" statements on the "keepalive" containers, as was
1909 needed to address a validation error that appeared after adding
1910 the "must" statements into the NETCONF/RESTCONF client/server
1911 modules.
1913 o Updated the boilerplate text in module-level "description"
1914 statement to match copyeditor convention.
1916 A.12. 11 to 12
1918 o In server model, made 'client-authentication' a 'presence' node
1919 indicating that the server supports client authentication.
1921 o In the server model, added a 'required-or-optional' choice to
1922 'client-authentication' to better support protocols such as
1923 RESTCONF.
1925 o In the server model, added a 'local-or-external' choice to
1926 'client-authentication' to better support consuming data models
1927 that prefer to keep client auth with client definitions than in a
1928 model principally concerned with the "transport".
1930 o In both models, removed the "demux containers", floating the
1931 nacm:default-deny-write to each descendent node, and adding a note
1932 to model designers regarding the potential need to add their own
1933 demux containers.
1935 o Fixed a couple references (section 2 --> section 3)
1937 Acknowledgements
1939 The authors would like to thank for following for lively discussions
1940 on list and in the halls (ordered by last name): Andy Bierman, Martin
1941 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
1942 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
1943 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
1945 Authors' Addresses
1947 Kent Watsen
1948 Watsen Networks
1950 EMail: kent+ietf@watsen.net
1952 Gary Wu
1953 Cisco Systems
1955 EMail: garywu@cisco.com
1957 Liang Xia
1958 Huawei
1960 EMail: frank.xialiang@huawei.com