idnits 2.17.1
draft-ietf-netconf-tls-client-server-04.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 :
----------------------------------------------------------------------------
** There are 2 instances of too long lines in the document, the longest one
being 6 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 18, 2017) is 2376 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 (-35) exists of
draft-ietf-netconf-keystore-02
** Obsolete normative reference: RFC 2246 (Obsoleted by RFC 4346)
** Obsolete normative reference: RFC 4346 (Obsoleted by RFC 5246)
** Obsolete normative reference: RFC 4492 (Obsoleted by RFC 8422)
** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446)
** Obsolete normative reference: RFC 6536 (Obsoleted by RFC 8341)
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Juniper Networks
4 Intended status: Standards Track G. Wu
5 Expires: April 21, 2018 Cisco Systems
6 October 18, 2017
8 YANG Groupings for TLS Clients and TLS Servers
9 draft-ietf-netconf-tls-client-server-04
11 Abstract
13 This document defines three YANG modules: the first defines groupings
14 for a generic TLS client, the second defines groupings for a generic
15 TLS server, and the third defines common identities and groupings
16 used by both the client and the server. It is intended that these
17 groupings will be used by applications using the TLS protocol.
19 Editorial Note (To be removed by RFC Editor)
21 This draft contains many placeholder values that need to be replaced
22 with finalized values at the time of publication. This note
23 summarizes all of the substitutions that are needed. No other RFC
24 Editor instructions are specified elsewhere in this document.
26 This document contains references to other drafts in progress, both
27 in the Normative References section, as well as in body text
28 throughout. Please update the following references to reflect their
29 final RFC assignments:
31 o I-D.ietf-netconf-keystore
33 Artwork in this document contains shorthand references to drafts in
34 progress. Please apply the following replacements:
36 o "XXXX" --> the assigned RFC value for this draft
38 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-keystore
40 Artwork in this document contains placeholder values for the date of
41 publication of this draft. Please apply the following replacement:
43 o "2017-10-19" --> the publication date of this draft
45 The following Appendix section is to be removed prior to publication:
47 o Appendix A. Change Log
49 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
51 Status of This Memo
53 This Internet-Draft is submitted in full conformance with the
54 provisions of BCP 78 and BCP 79.
56 Internet-Drafts are working documents of the Internet Engineering
57 Task Force (IETF). Note that other groups may also distribute
58 working documents as Internet-Drafts. The list of current Internet-
59 Drafts is at https://datatracker.ietf.org/drafts/current/.
61 Internet-Drafts are draft documents valid for a maximum of six months
62 and may be updated, replaced, or obsoleted by other documents at any
63 time. It is inappropriate to use Internet-Drafts as reference
64 material or to cite them other than as "work in progress."
66 This Internet-Draft will expire on April 21, 2018.
68 Copyright Notice
70 Copyright (c) 2017 IETF Trust and the persons identified as the
71 document authors. All rights reserved.
73 This document is subject to BCP 78 and the IETF Trust's Legal
74 Provisions Relating to IETF Documents
75 (https://trustee.ietf.org/license-info) in effect on the date of
76 publication of this document. Please review these documents
77 carefully, as they describe your rights and restrictions with respect
78 to this document. Code Components extracted from this document must
79 include Simplified BSD License text as described in Section 4.e of
80 the Trust Legal Provisions and are provided without warranty as
81 described in the Simplified BSD License.
83 Table of Contents
85 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
86 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
87 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 4
88 2. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4
89 2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
90 2.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5
91 2.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 5
92 3. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 8
93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 8
94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 9
95 3.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 9
96 4. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 12
97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 13
98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 13
100 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
102 4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13
103 5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
105 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 23
106 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 23
107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
109 8.1. Normative References . . . . . . . . . . . . . . . . . . 24
110 8.2. Informative References . . . . . . . . . . . . . . . . . 25
111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
112 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 27
113 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 27
114 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 27
115 A.4. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 27
116 A.5. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 27
117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
119 1. Introduction
121 This document defines three YANG [RFC7950] modules: the first defines
122 a grouping for a generic TLS client, the second defines a grouping
123 for a generic TLS server, and the third defines identities and
124 groupings common to both the client and the server (TLS is defined in
125 [RFC5246]). It is intended that these groupings will be used by
126 applications using the TLS protocol. For instance, these groupings
127 could be used to help define the data model for an HTTPS [RFC2818]
128 server or a NETCONF over TLS [RFC7589] based server.
130 The client and server YANG modules in this document each define one
131 grouping, which is focused on just TLS-specific configuration, and
132 specifically avoids any transport-level configuration, such as what
133 ports to listen-on or connect-to. This enables applications the
134 opportunity to define their own strategy for how the underlying TCP
135 connection is established. For instance, applications supporting
136 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts
137 it provides, while adding data nodes for the TCP-level call-home
138 configuration.
140 1.1. Terminology
142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
144 "OPTIONAL" in this document are to be interpreted as described in BCP
145 14 [RFC2119] [RFC8174] when, and only when, they appear in all
146 capitals, as shown here.
148 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
150 1.2. Tree Diagrams
152 A simplified graphical representation of the data models is used in
153 this document. The meaning of the symbols in these diagrams is as
154 follows:
156 o Brackets "[" and "]" enclose list keys.
158 o Braces "{" and "}" enclose feature names, and indicate that the
159 named feature must be present for the subtree to be present.
161 o Abbreviations before data node names: "rw" means configuration
162 (read-write) and "ro" state data (read-only).
164 o Symbols after data node names: "?" means an optional node, "!"
165 means a presence container, and "*" denotes a list and leaf-list.
167 o Parentheses enclose choice and case nodes, and case nodes are also
168 marked with a colon (":").
170 o Ellipsis ("...") stands for contents of subtrees that are not
171 shown.
173 2. The TLS Client Model
175 The TLS client model presented in this section contains one YANG
176 grouping, to just configure the TLS client, omitting, for instance,
177 any configuration for which IP address or port the client should
178 connect to.
180 This grouping references data nodes defined by the keystore model
181 [I-D.ietf-netconf-keystore]. For instance, a reference to the
182 keystore model is made to indicate which trusted CA certificate a
183 client should use to authenticate the server's certificate.
185 2.1. Tree Diagram
187 The following tree diagram presents the data model for the grouping
188 defined in the ietf-tls-client module. Please see Section 1.2 for
189 tree diagram notation.
191 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
193 module: ietf-tls-client
195 grouping tls-client-grouping
196 +---- client-auth
197 | +---- (auth-type)?
198 | +--:(certificate)
199 | +---- certificate? leafref
200 +---- server-auth
201 | +---- pinned-ca-certs?
202 | | -> /ks:keystore/pinned-certificates/name
203 | +---- pinned-server-certs?
204 | -> /ks:keystore/pinned-certificates/name
205 +---- hello-params {tls-client-hello-params-config}?
206 +---- tls-versions
207 | +---- tls-version* identityref
208 +---- cipher-suites
209 +---- cipher-suite* identityref
211 2.2. Example Usage
213 This section shows how it would appear if the tls-client-grouping
214 were populated with some data. This example is consistent with the
215 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].
217
218
220
221
222 builtin-idevid-cert
223
225
226
227 deployment-specific-ca-certs
228 explicitly-trusted-client-certs
229
231
233 2.3. YANG Model
235 This YANG module has a normative references to [RFC6991] and
236 [I-D.ietf-netconf-keystore].
238 file "ietf-tls-client@2017-10-19.yang"
239 module ietf-tls-client {
240 yang-version 1.1;
242 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
244 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
245 prefix "tlsc";
247 import ietf-tls-common {
248 prefix tlscmn;
249 revision-date 2017-10-19; // stable grouping definitions
250 reference
251 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
252 }
254 import ietf-keystore {
255 prefix ks;
256 reference
257 "RFC YYYY: Keystore Model";
258 }
260 organization
261 "IETF NETCONF (Network Configuration) Working Group";
263 contact
264 "WG Web:
265 WG List:
267 Author: Kent Watsen
268
270 Author: Gary Wu
271 ";
273 description
274 "This module defines a reusable grouping for a TLS client that
275 can be used as a basis for specific TLS client instances.
277 Copyright (c) 2017 IETF Trust and the persons identified as
278 authors of the code. All rights reserved.
280 Redistribution and use in source and binary forms, with or
281 without modification, is permitted pursuant to, and subject
282 to the license terms contained in, the Simplified BSD
283 License set forth in Section 4.c of the IETF Trust's
284 Legal Provisions Relating to IETF Documents
285 (http://trustee.ietf.org/license-info).
287 This version of this YANG module is part of RFC XXXX; see
288 the RFC itself for full legal notices.";
290 revision "2017-10-19" {
292 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
294 description
295 "Initial version";
296 reference
297 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
298 }
300 feature tls-client-hello-params-config {
301 description
302 "TLS hello message parameters are configurable on a TLS
303 client.";
304 }
306 grouping tls-client-grouping {
307 description
308 "A reusable grouping for configuring a TLS client without
309 any consideration for how an underlying TCP session is
310 established.";
312 container client-auth {
313 description
314 "The credentials used by the client to authenticate to
315 the TLS server.";
317 choice auth-type {
318 description
319 "The authentication type.";
320 leaf certificate {
321 type leafref {
322 path "/ks:keystore/ks:keys/ks:key/ks:certificates"
323 + "/ks:certificate/ks:name";
324 }
325 description
326 "A certificates to be used for user authentication.";
327 }
328 }
329 }
331 container server-auth {
332 must 'pinned-ca-certs or pinned-server-certs';
333 description
334 "Trusted server identities.";
335 leaf pinned-ca-certs {
336 type leafref {
337 path "/ks:keystore/ks:pinned-certificates/ks:name";
338 }
339 description
340 "A reference to a list of certificate authority (CA)
341 certificates used by the TLS client to authenticate
343 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
345 TLS server certificates. A server certificate is
346 authenticated if it has a valid chain of trust to
347 a configured pinned CA certificate.";
348 }
350 leaf pinned-server-certs {
351 type leafref {
352 path "/ks:keystore/ks:pinned-certificates/ks:name";
353 }
354 description
355 "A reference to a list of server certificates used by
356 the TLS client to authenticate TLS server certificates.
357 A server certificate is authenticated if it is an
358 exact match to a configured pinned server certificate.";
359 }
360 }
362 container hello-params {
363 if-feature tls-client-hello-params-config;
364 uses tlscmn:hello-params-grouping;
365 description
366 "Configurable parameters for the TLS hello message.";
367 }
369 } // end tls-client-grouping
371 }
372
374 3. The TLS Server Model
376 The TLS server model presented in this section contains one YANG
377 grouping, for just the TLS-level configuration, omitting, for
378 instance, configuration for which ports to open to listen for
379 connections on.
381 This grouping references data nodes defined by the keystore model
382 [I-D.ietf-netconf-keystore]. For instance, a reference to the
383 keystore model is made to indicate which certificate a server should
384 present.
386 3.1. Tree Diagram
388 The following tree diagram presents the data model for the grouping
389 defined in the ietf-tls-server module. Please see Section 1.2 for
390 tree diagram notation.
392 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
394 module: ietf-tls-server
396 grouping tls-server-grouping
397 +---- certificates
398 | +---- certificate* [name]
399 | +---- name? leafref
400 +---- client-auth
401 | +---- pinned-ca-certs?
402 | | -> /ks:keystore/pinned-certificates/name
403 | +---- pinned-client-certs?
404 | -> /ks:keystore/pinned-certificates/name
405 +---- hello-params {tls-server-hello-params-config}?
406 +---- tls-versions
407 | +---- tls-version* identityref
408 +---- cipher-suites
409 +---- cipher-suite* identityref
411 3.2. Example Usage
413 This section shows how it would appear if the tls-server-grouping
414 were populated with some data. This example is consistent with the
415 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].
417
419
420
421
422 tls-ec-cert
423
424
426
427
428 deployment-specific-ca-certs
429 explicitly-trusted-client-certs
430
432
434 3.3. YANG Model
436 This YANG module has a normative references to [RFC6991], and
437 [I-D.ietf-netconf-keystore].
439 file "ietf-tls-server@2017-10-19.yang"
440 module ietf-tls-server {
441 yang-version 1.1;
443 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
445 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
446 prefix "tlss";
448 import ietf-tls-common {
449 prefix tlscmn;
450 revision-date 2017-10-19; // stable grouping definitions
451 reference
452 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
453 }
455 import ietf-keystore {
456 prefix ks;
457 reference
458 "RFC YYYY: Keystore Model";
459 }
461 organization
462 "IETF NETCONF (Network Configuration) Working Group";
464 contact
465 "WG Web:
466 WG List:
468 Author: Kent Watsen
469
471 Author: Gary Wu
472 ";
474 description
475 "This module defines a reusable grouping for a TLS server that
476 can be used as a basis for specific TLS server instances.
478 Copyright (c) 2017 IETF Trust and the persons identified as
479 authors of the code. All rights reserved.
481 Redistribution and use in source and binary forms, with or
482 without modification, is permitted pursuant to, and subject
483 to the license terms contained in, the Simplified BSD
484 License set forth in Section 4.c of the IETF Trust's
485 Legal Provisions Relating to IETF Documents
486 (http://trustee.ietf.org/license-info).
488 This version of this YANG module is part of RFC XXXX; see
489 the RFC itself for full legal notices.";
491 revision "2017-10-19" {
493 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
495 description
496 "Initial version";
497 reference
498 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
499 }
501 feature tls-server-hello-params-config {
502 description
503 "TLS hello message parameters are configurable on a TLS
504 server.";
505 }
507 // groupings
509 grouping tls-server-grouping {
510 description
511 "A reusable grouping for configuring a TLS server without
512 any consideration for how underlying TCP sessions are
513 established.";
515 container certificates {
516 description
517 "The list of certificates the TLS server will present when
518 establishing a TLS connection in its Certificate message,
519 as defined in Section 7.4.2 in RFC 5246.";
520 reference
521 "RFC 5246:
522 The Transport Layer Security (TLS) Protocol Version 1.2";
523 list certificate {
524 key name;
525 min-elements 1;
526 description
527 "An unordered list of certificates the TLS server can pick
528 from when sending its Server Certificate message.";
529 reference
530 "RFC 5246: The TLS Protocol, Section 7.4.2";
531 leaf name {
532 type leafref {
533 path "/ks:keystore/ks:keys/ks:key/ks:certificates/"
534 + "ks:certificate/ks:name";
535 }
536 description
537 "The name of the certificate in the keystore.";
538 }
539 }
540 }
542 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
544 container client-auth {
545 description
546 "A reference to a list of pinned certificate authority (CA)
547 certificates and a reference to a list of pinned client
548 certificates.";
549 leaf pinned-ca-certs {
550 type leafref {
551 path "/ks:keystore/ks:pinned-certificates/ks:name";
552 }
553 description
554 "A reference to a list of certificate authority (CA)
555 certificates used by the TLS server to authenticate
556 TLS client certificates. A client certificate is
557 authenticated if it has a valid chain of trust to
558 a configured pinned CA certificate.";
559 }
560 leaf pinned-client-certs {
561 type leafref {
562 path "/ks:keystore/ks:pinned-certificates/ks:name";
563 }
564 description
565 "A reference to a list of client certificates used by
566 the TLS server to authenticate TLS client certificates.
567 A clients certificate is authenticated if it is an
568 exact match to a configured pinned client certificate.";
569 }
570 }
572 container hello-params {
573 if-feature tls-server-hello-params-config;
574 uses tlscmn:hello-params-grouping;
575 description
576 "Configurable parameters for the TLS hello message.";
577 }
579 } // end tls-server-grouping
581 }
582
584 4. The TLS Common Model
586 The TLS common model presented in this section contains identities
587 and groupings common to both TLS clients and TLS servers. The hello-
588 params-grouping can be used to configure the list of TLS algorithms
589 permitted by the TLS client or TLS server. The lists of algorithms
590 are ordered such that, if multiple algorithms are permitted by the
591 client, the algorithm that appears first in its list that is also
593 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
595 permitted by the server is used for the TLS transport layer
596 connection. The ability to restrict the the algorithms allowed is
597 provided in this grouping for TLS clients and TLS servers that are
598 capable of doing so and may serve to make TLS clients and TLS servers
599 compliant with security policies.
601 Features are defined for algorithms that are OPTIONAL or are not
602 widely supported by popular implementations. Note that the list of
603 algorithms is not exhaustive.
605 4.1. Tree Diagram
607 The following tree diagram presents the data model for the grouping
608 defined in the ietf-tls-common module. Please see Section 1.2 for
609 tree diagram notation.
611 module: ietf-tls-common
613 grouping hello-params-grouping
614 +---- tls-versions
615 | +---- tls-version* identityref
616 +---- cipher-suites
617 +---- cipher-suite* identityref
619 4.2. Example Usage
621 This section shows how it would appear if the transport-params-
622 grouping were populated with some data.
624
625
627
628 tlscmn:tls-1.1
629 tlscmn:tls-1.2
630
631
632 tlscmn:dhe-rsa-with-aes-128-cbc-sha
633 tlscmn:rsa-with-aes-128-cbc-sha
634 tlscmn:rsa-with-3des-ede-cbc-sha
635
636
638 4.3. YANG Model
640 This YANG module has a normative references to [RFC2246], [RFC4346],
641 [RFC4492], [RFC5246], [RFC5288], and [RFC5289].
643 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
645 file "ietf-tls-common@2017-10-19.yang"
646 module ietf-tls-common {
647 yang-version 1.1;
649 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
650 prefix "tlscmn";
652 organization
653 "IETF NETCONF (Network Configuration) Working Group";
655 contact
656 "WG Web:
657 WG List:
659 Author: Kent Watsen
660
662 Author: Gary Wu
663 ";
665 description
666 "This module defines a common features, identities, and groupings
667 for Transport Layer Security (TLS).
669 Copyright (c) 2017 IETF Trust and the persons identified as
670 authors of the code. All rights reserved.
672 Redistribution and use in source and binary forms, with or
673 without modification, is permitted pursuant to, and subject
674 to the license terms contained in, the Simplified BSD
675 License set forth in Section 4.c of the IETF Trust's
676 Legal Provisions Relating to IETF Documents
677 (http://trustee.ietf.org/license-info).
679 This version of this YANG module is part of RFC XXXX; see
680 the RFC itself for full legal notices.";
682 revision "2017-10-19" {
683 description
684 "Initial version";
685 reference
686 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
687 }
689 // features
690 feature tls-1_0 {
691 description
693 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
695 "TLS Protocol Version 1.0 is supported.";
696 reference
697 "RFC 2246: The TLS Protocol Version 1.0";
698 }
700 feature tls-1_1 {
701 description
702 "TLS Protocol Version 1.1 is supported.";
703 reference
704 "RFC 4346: The Transport Layer Security (TLS) Protocol
705 Version 1.1";
706 }
708 feature tls-1_2 {
709 description
710 "TLS Protocol Version 1.2 is supported.";
711 reference
712 "RFC 5246: The Transport Layer Security (TLS) Protocol
713 Version 1.2";
714 }
716 feature tls-ecc {
717 description
718 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
719 reference
720 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
721 for Transport Layer Security (TLS)";
722 }
724 feature tls-dhe {
725 description
726 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
727 reference
728 "RFC 5246: The Transport Layer Security (TLS) Protocol
729 Version 1.2";
730 }
732 feature tls-3des {
733 description
734 "The Triple-DES block cipher is supported for TLS.";
735 reference
736 "RFC 5246: The Transport Layer Security (TLS) Protocol
737 Version 1.2";
738 }
740 feature tls-gcm {
741 description
742 "The Galois/Counter Mode authenticated encryption mode is
744 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
746 supported for TLS.";
747 reference
748 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
749 TLS";
750 }
752 feature tls-sha2 {
753 description
754 "The SHA2 family of cryptographic hash functions is supported
755 for TLS.";
756 reference
757 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
758 }
760 // identities
761 identity tls-version-base {
762 description
763 "Base identity used to identify TLS protocol versions.";
764 }
766 identity tls-1.0 {
767 base tls-version-base;
768 if-feature tls-1_0;
769 description
770 "TLS Protocol Version 1.0.";
771 reference
772 "RFC 2246: The TLS Protocol Version 1.0";
773 }
775 identity tls-1.1 {
776 base tls-version-base;
777 if-feature tls-1_1;
778 description
779 "TLS Protocol Version 1.1.";
780 reference
781 "RFC 4346: The Transport Layer Security (TLS) Protocol
782 Version 1.1";
783 }
785 identity tls-1.2 {
786 base tls-version-base;
787 if-feature tls-1_2;
788 description
789 "TLS Protocol Version 1.2.";
790 reference
791 "RFC 5246: The Transport Layer Security (TLS) Protocol
792 Version 1.2";
793 }
795 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
797 identity cipher-suite-base {
798 description
799 "Base identity used to identify TLS cipher suites.";
800 }
802 identity rsa-with-aes-128-cbc-sha {
803 base cipher-suite-base;
804 description
805 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
806 reference
807 "RFC 5246: The Transport Layer Security (TLS) Protocol
808 Version 1.2";
809 }
811 identity rsa-with-aes-256-cbc-sha {
812 base cipher-suite-base;
813 description
814 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
815 reference
816 "RFC 5246: The Transport Layer Security (TLS) Protocol
817 Version 1.2";
818 }
820 identity rsa-with-aes-128-cbc-sha256 {
821 base cipher-suite-base;
822 if-feature tls-sha2;
823 description
824 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
825 reference
826 "RFC 5246: The Transport Layer Security (TLS) Protocol
827 Version 1.2";
828 }
830 identity rsa-with-aes-256-cbc-sha256 {
831 base cipher-suite-base;
832 if-feature tls-sha2;
833 description
834 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
835 reference
836 "RFC 5246: The Transport Layer Security (TLS) Protocol
837 Version 1.2";
838 }
840 identity dhe-rsa-with-aes-128-cbc-sha {
841 base cipher-suite-base;
842 if-feature tls-dhe;
843 description
844 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
846 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
848 reference
849 "RFC 5246: The Transport Layer Security (TLS) Protocol
850 Version 1.2";
851 }
853 identity dhe-rsa-with-aes-256-cbc-sha {
854 base cipher-suite-base;
855 if-feature tls-dhe;
856 description
857 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
858 reference
859 "RFC 5246: The Transport Layer Security (TLS) Protocol
860 Version 1.2";
861 }
863 identity dhe-rsa-with-aes-128-cbc-sha256 {
864 base cipher-suite-base;
865 if-feature "tls-dhe and tls-sha2";
866 description
867 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
868 reference
869 "RFC 5246: The Transport Layer Security (TLS) Protocol
870 Version 1.2";
871 }
873 identity dhe-rsa-with-aes-256-cbc-sha256 {
874 base cipher-suite-base;
875 if-feature "tls-dhe and tls-sha2";
876 description
877 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
878 reference
879 "RFC 5246: The Transport Layer Security (TLS) Protocol
880 Version 1.2";
881 }
883 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
884 base cipher-suite-base;
885 if-feature "tls-ecc and tls-sha2";
886 description
887 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
888 reference
889 "RFC 5289: TLS Elliptic Curve Cipher Suites with
890 SHA-256/384 and AES Galois Counter Mode (GCM)";
891 }
893 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
894 base cipher-suite-base;
895 if-feature "tls-ecc and tls-sha2";
897 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
899 description
900 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
901 reference
902 "RFC 5289: TLS Elliptic Curve Cipher Suites with
903 SHA-256/384 and AES Galois Counter Mode (GCM)";
904 }
906 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
907 base cipher-suite-base;
908 if-feature "tls-ecc and tls-sha2";
909 description
910 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
911 reference
912 "RFC 5289: TLS Elliptic Curve Cipher Suites with
913 SHA-256/384 and AES Galois Counter Mode (GCM)";
914 }
916 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
917 base cipher-suite-base;
918 if-feature "tls-ecc and tls-sha2";
919 description
920 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
921 reference
922 "RFC 5289: TLS Elliptic Curve Cipher Suites with
923 SHA-256/384 and AES Galois Counter Mode (GCM)";
924 }
926 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
927 base cipher-suite-base;
928 if-feature "tls-ecc and tls-gcm and tls-sha2";
929 description
930 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
931 reference
932 "RFC 5289: TLS Elliptic Curve Cipher Suites with
933 SHA-256/384 and AES Galois Counter Mode (GCM)";
934 }
936 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
937 base cipher-suite-base;
938 if-feature "tls-ecc and tls-gcm and tls-sha2";
939 description
940 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
941 reference
942 "RFC 5289: TLS Elliptic Curve Cipher Suites with
943 SHA-256/384 and AES Galois Counter Mode (GCM)";
944 }
946 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
948 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
950 base cipher-suite-base;
951 if-feature "tls-ecc and tls-gcm and tls-sha2";
952 description
953 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
954 reference
955 "RFC 5289: TLS Elliptic Curve Cipher Suites with
956 SHA-256/384 and AES Galois Counter Mode (GCM)";
957 }
959 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
960 base cipher-suite-base;
961 if-feature "tls-ecc and tls-gcm and tls-sha2";
962 description
963 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
964 reference
965 "RFC 5289: TLS Elliptic Curve Cipher Suites with
966 SHA-256/384 and AES Galois Counter Mode (GCM)";
967 }
969 identity rsa-with-3des-ede-cbc-sha {
970 base cipher-suite-base;
971 if-feature tls-3des;
972 description
973 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
974 reference
975 "RFC 5246: The Transport Layer Security (TLS) Protocol
976 Version 1.2";
977 }
979 identity ecdhe-rsa-with-3des-ede-cbc-sha {
980 base cipher-suite-base;
981 if-feature "tls-ecc and tls-3des";
982 description
983 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
984 reference
985 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
986 for Transport Layer Security (TLS)";
987 }
989 identity ecdhe-rsa-with-aes-128-cbc-sha {
990 base cipher-suite-base;
991 if-feature "tls-ecc";
992 description
993 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
994 reference
995 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
996 for Transport Layer Security (TLS)";
997 }
999 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1001 identity ecdhe-rsa-with-aes-256-cbc-sha {
1002 base cipher-suite-base;
1003 if-feature "tls-ecc";
1004 description
1005 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1006 reference
1007 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
1008 for Transport Layer Security (TLS)";
1009 }
1011 // groupings
1013 grouping hello-params-grouping {
1014 description
1015 "A reusable grouping for TLS hello message parameters.";
1016 reference
1017 "RFC 5246: The Transport Layer Security (TLS) Protocol
1018 Version 1.2";
1020 container tls-versions {
1021 description
1022 "Parameters regarding TLS versions.";
1023 leaf-list tls-version {
1024 type identityref {
1025 base tls-version-base;
1026 }
1027 description
1028 "Acceptable TLS protocol versions.
1030 If this leaf-list is not configured (has zero elements)
1031 the acceptable TLS protocol versions are implementation-
1032 defined.";
1033 }
1034 }
1035 container cipher-suites {
1036 description
1037 "Parameters regarding cipher suites.";
1038 leaf-list cipher-suite {
1039 type identityref {
1040 base cipher-suite-base;
1041 }
1042 ordered-by user;
1043 description
1044 "Acceptable cipher suites in order of descending
1045 preference.
1047 If this leaf-list is not configured (has zero elements)
1048 the acceptable cipher suites are implementation-
1050 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1052 defined.";
1053 }
1054 }
1056 } // end hello-params-grouping
1058 }
1059
1061 5. Security Considerations
1063 The YANG modules defined in this document are designed to be accessed
1064 via YANG based management protocols, such as NETCONF [RFC6241] and
1065 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1066 implement secure transport layers (e.g., SSH, TLS) with mutual
1067 authentication.
1069 The NETCONF access control model (NACM) [RFC6536] provides the means
1070 to restrict access for particular users to a pre-configured subset of
1071 all available protocol operations and content.
1073 Since the modules defined in this document only define groupings,
1074 these considerations are primarily for the designers of other modules
1075 that use these groupings.
1077 There are a number of data nodes defined in the YANG modules that are
1078 writable/creatable/deletable (i.e., config true, which is the
1079 default). These data nodes may be considered sensitive or vulnerable
1080 in some network environments. Write operations (e.g., edit-config)
1081 to these data nodes without proper protection can have a negative
1082 effect on network operations. These are the subtrees and data nodes
1083 and their sensitivity/vulnerability:
1085 /: The entire data tree of all the groupings defined in this draft
1086 is sensitive to write operations. For instance, the addition
1087 or removal of references to keys, certificates, trusted
1088 anchors, etc., can dramatically alter the implemented security
1089 policy. However, no NACM annotations are applied as the data
1090 SHOULD be editable by users other than a designated 'recovery
1091 session'.
1093 Some of the readable data nodes in the YANG modules may be considered
1094 sensitive or vulnerable in some network environments. It is thus
1095 important to control read access (e.g., via get, get-config, or
1096 notification) to these data nodes. These are the subtrees and data
1097 nodes and their sensitivity/vulnerability:
1099 NONE
1101 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1103 Some of the RPC operations in this YANG module may be considered
1104 sensitive or vulnerable in some network environments. It is thus
1105 important to control access to these operations. These are the
1106 operations and their sensitivity/vulnerability:
1108 NONE
1110 6. IANA Considerations
1112 6.1. The IETF XML Registry
1114 This document registers three URIs in the IETF XML registry
1115 [RFC3688]. Following the format in [RFC3688], the following
1116 registrations are requested:
1118 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1119 Registrant Contact: The NETCONF WG of the IETF.
1120 XML: N/A, the requested URI is an XML namespace.
1122 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1123 Registrant Contact: The NETCONF WG of the IETF.
1124 XML: N/A, the requested URI is an XML namespace.
1126 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1127 Registrant Contact: The NETCONF WG of the IETF.
1128 XML: N/A, the requested URI is an XML namespace.
1130 6.2. The YANG Module Names Registry
1132 This document registers three YANG modules in the YANG Module Names
1133 registry [RFC7950]. Following the format in [RFC7950], the the
1134 following registrations are requested:
1136 name: ietf-tls-client
1137 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1138 prefix: tlsc
1139 reference: RFC XXXX
1141 name: ietf-tls-server
1142 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1143 prefix: tlss
1144 reference: RFC XXXX
1146 name: ietf-tls-common
1147 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1148 prefix: tlscmn
1149 reference: RFC XXXX
1151 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1153 7. Acknowledgements
1155 The authors would like to thank for following for lively discussions
1156 on list and in the halls (ordered by last name): Andy Bierman, Martin
1157 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
1158 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
1159 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
1161 8. References
1163 8.1. Normative References
1165 [I-D.ietf-netconf-keystore]
1166 Watsen, K., "Keystore Model", draft-ietf-netconf-
1167 keystore-02 (work in progress), June 2017.
1169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1170 Requirement Levels", BCP 14, RFC 2119,
1171 DOI 10.17487/RFC2119, March 1997,
1172 .
1174 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1175 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1176 .
1178 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1179 (TLS) Protocol Version 1.1", RFC 4346,
1180 DOI 10.17487/RFC4346, April 2006,
1181 .
1183 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
1184 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
1185 for Transport Layer Security (TLS)", RFC 4492,
1186 DOI 10.17487/RFC4492, May 2006,
1187 .
1189 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1190 (TLS) Protocol Version 1.2", RFC 5246,
1191 DOI 10.17487/RFC5246, August 2008,
1192 .
1194 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1195 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1196 DOI 10.17487/RFC5288, August 2008,
1197 .
1199 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1201 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1202 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1203 DOI 10.17487/RFC5289, August 2008,
1204 .
1206 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
1207 Protocol (NETCONF) Access Control Model", RFC 6536,
1208 DOI 10.17487/RFC6536, March 2012,
1209 .
1211 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1212 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1213 .
1215 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1216 NETCONF Protocol over Transport Layer Security (TLS) with
1217 Mutual X.509 Authentication", RFC 7589,
1218 DOI 10.17487/RFC7589, June 2015,
1219 .
1221 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1222 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1223 .
1225 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1226 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1227 May 2017, .
1229 8.2. Informative References
1231 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1232 DOI 10.17487/RFC2818, May 2000,
1233 .
1235 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1236 DOI 10.17487/RFC3688, January 2004,
1237 .
1239 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1240 and A. Bierman, Ed., "Network Configuration Protocol
1241 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1242 .
1244 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1245 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1246 .
1248 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1250 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1251 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1252 .
1254 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1256 Appendix A. Change Log
1258 A.1. server-model-09 to 00
1260 o This draft was split out from draft-ietf-netconf-server-model-09.
1262 o Noted that '0.0.0.0' and '::' might have special meanings.
1264 A.2. 00 to 01
1266 o Renamed "keychain" to "keystore".
1268 A.3. 01 to 02
1270 o Removed the groupings containing transport-level configuration.
1271 Now modules contain only the transport-independent groupings.
1273 o Filled in previously incomplete 'ietf-tls-client' module.
1275 o Added cipher suites for various algorithms into new 'ietf-tls-
1276 common' module.
1278 A.4. 02 to 03
1280 o Added a 'must' statement to container 'server-auth' asserting that
1281 at least one of the various auth mechanisms must be specified.
1283 o Fixed description statement for leaf 'trusted-ca-certs'.
1285 A.5. 03 to 04
1287 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
1289 o Updated leafref paths to point to new keystore path
1291 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
1292 'tlscmn'.
1294 o Added TLS protocol verions 1.0 and 1.1.
1296 o Made author lists consistent
1298 Authors' Addresses
1300 Kent Watsen
1301 Juniper Networks
1303 EMail: kwatsen@juniper.net
1305 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1307 Gary Wu
1308 Cisco Systems
1310 EMail: garywu@cisco.com