idnits 2.17.1
draft-ietf-netconf-tls-client-server-05.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
== Line 181 has weird spacing: '...gorithm ide...'
== Line 191 has weird spacing: '...request bin...'
== Line 407 has weird spacing: '...gorithm ide...'
== Line 417 has weird spacing: '...request bin...'
-- The document date (October 30, 2017) is 2363 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)
== Outdated reference: A later version (-06) exists of
draft-ietf-netmod-yang-tree-diagrams-02
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
Summary: 5 errors (**), 0 flaws (~~), 7 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: May 3, 2018 Cisco Systems
6 October 30, 2017
8 YANG Groupings for TLS Clients and TLS Servers
9 draft-ietf-netconf-tls-client-server-05
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-30" --> 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 May 3, 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
87 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4
88 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
89 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5
90 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
91 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 9
92 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 9
93 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 10
94 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11
95 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 14
96 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 14
97 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 14
98 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 15
100 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
104 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 24
105 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 25
106 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
107 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
108 9.1. Normative References . . . . . . . . . . . . . . . . . . 25
109 9.2. Informative References . . . . . . . . . . . . . . . . . 27
110 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
111 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 28
112 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 28
113 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 28
114 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 28
115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
117 1. Introduction
119 This document defines three YANG [RFC7950] modules: the first defines
120 a grouping for a generic TLS client, the second defines a grouping
121 for a generic TLS server, and the third defines identities and
122 groupings common to both the client and the server (TLS is defined in
123 [RFC5246]). It is intended that these groupings will be used by
124 applications using the TLS protocol. For instance, these groupings
125 could be used to help define the data model for an HTTPS [RFC2818]
126 server or a NETCONF over TLS [RFC7589] based server.
128 The client and server YANG modules in this document each define one
129 grouping, which is focused on just TLS-specific configuration, and
130 specifically avoids any transport-level configuration, such as what
131 ports to listen-on or connect-to. This enables applications the
132 opportunity to define their own strategy for how the underlying TCP
133 connection is established. For instance, applications supporting
134 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts
135 it provides, while adding data nodes for the TCP-level call-home
136 configuration.
138 2. Terminology
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
142 "OPTIONAL" in this document are to be interpreted as described in BCP
143 14 [RFC2119] [RFC8174] when, and only when, they appear in all
144 capitals, as shown here.
146 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
148 3. The TLS Client Model
150 The TLS client model presented in this section contains one YANG
151 grouping, to just configure the TLS client, omitting, for instance,
152 any configuration for which IP address or port the client should
153 connect to.
155 This grouping references data nodes defined by the keystore model
156 [I-D.ietf-netconf-keystore]. For instance, a reference to the
157 keystore model is made to indicate which trusted CA certificate a
158 client should use to authenticate the server's certificate.
160 3.1. Tree Diagram
162 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams]
163 provides an overview of the data model for the "ietf-tls-client"
164 module.
166 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
168 module: ietf-tls-client
170 grouping tls-client-grouping
171 +---- client-identity
172 | +---- (auth-type)?
173 | +--:(certificate)
174 | +---- certificate
175 | +---- algorithm?
176 | | identityref
177 | +---- private-key? union
178 | +---- public-key? binary
179 | +---x generate-private-key
180 | | +---w input
181 | | +---w algorithm identityref
182 | +---- certificates
183 | | +---- certificate* [name]
184 | | +---- name? string
185 | | +---- value? binary
186 | +---x generate-certificate-signing-request
187 | +---w input
188 | | +---w subject binary
189 | | +---w attributes? binary
190 | +--ro output
191 | +--ro certificate-signing-request binary
192 +---- server-auth
193 | +---- pinned-ca-certs? ks:pinned-certificates
194 | +---- pinned-server-certs? ks:pinned-certificates
195 +---- hello-params {tls-client-hello-params-config}?
196 +---- tls-versions
197 | +---- tls-version* identityref
198 +---- cipher-suites
199 +---- cipher-suite* identityref
201 3.2. Example Usage
203 This section shows how it would appear if the tls-client-grouping
204 were populated with some data. This example is consistent with the
205 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].
207 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
209 [ note: '\' line wrapping for formatting only]
211
212
214
215
216
217 ks:secp521r1
219 base64encodedvalue==
220 base64encodedvalue==
221
222
223 domain certificate
224 base64encodedvalue==
225
226
227
228
230
231
232 deployment-specific-ca-certs
233 explicitly-trusted-client-certs
235
237
239 3.3. YANG Module
241 This YANG module has a normative references to [RFC6991] and
242 [I-D.ietf-netconf-keystore].
244 file "ietf-tls-client@2017-10-30.yang"
245 module ietf-tls-client {
246 yang-version 1.1;
248 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
249 prefix "tlsc";
251 import ietf-tls-common {
252 prefix tlscmn;
253 revision-date 2017-10-30; // stable grouping definitions
254 reference
255 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
256 }
258 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
260 import ietf-keystore {
261 prefix ks;
262 reference
263 "RFC YYYY: Keystore Model";
264 }
266 organization
267 "IETF NETCONF (Network Configuration) Working Group";
269 contact
270 "WG Web:
271 WG List:
273 Author: Kent Watsen
274
276 Author: Gary Wu
277 ";
279 description
280 "This module defines a reusable grouping for a TLS client that
281 can be used as a basis for specific TLS client instances.
283 Copyright (c) 2017 IETF Trust and the persons identified as
284 authors of the code. All rights reserved.
286 Redistribution and use in source and binary forms, with or
287 without modification, is permitted pursuant to, and subject
288 to the license terms contained in, the Simplified BSD
289 License set forth in Section 4.c of the IETF Trust's
290 Legal Provisions Relating to IETF Documents
291 (http://trustee.ietf.org/license-info).
293 This version of this YANG module is part of RFC XXXX; see
294 the RFC itself for full legal notices.";
296 revision "2017-10-30" {
297 description
298 "Initial version";
299 reference
300 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
301 }
303 // features
305 feature tls-client-hello-params-config {
306 description
308 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
310 "TLS hello message parameters are configurable on a TLS
311 client.";
312 }
314 // groupings
316 grouping tls-client-grouping {
317 description
318 "A reusable grouping for configuring a TLS client without
319 any consideration for how an underlying TCP session is
320 established.";
322 container client-identity {
323 description
324 "The credentials used by the client to authenticate to
325 the TLS server.";
327 choice auth-type {
328 description
329 "The authentication type.";
330 container certificate {
331 uses ks:private-key-grouping;
332 uses ks:certificate-grouping;
333 description
334 "Choice statement for future augmentations.";
335 }
336 }
337 }
339 container server-auth {
340 must 'pinned-ca-certs or pinned-server-certs';
341 description
342 "Trusted server identities.";
343 leaf pinned-ca-certs {
344 type ks:pinned-certificates;
345 description
346 "A reference to a list of certificate authority (CA)
347 certificates used by the TLS client to authenticate
348 TLS server certificates. A server certificate is
349 authenticated if it has a valid chain of trust to
350 a configured pinned CA certificate.";
351 }
353 leaf pinned-server-certs {
354 type ks:pinned-certificates;
355 description
356 "A reference to a list of server certificates used by
357 the TLS client to authenticate TLS server certificates.
359 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
361 A server certificate is authenticated if it is an
362 exact match to a configured pinned server certificate.";
363 }
364 }
366 container hello-params {
367 if-feature tls-client-hello-params-config;
368 uses tlscmn:hello-params-grouping;
369 description
370 "Configurable parameters for the TLS hello message.";
371 }
373 } // end tls-client-grouping
375 }
376
378 4. The TLS Server Model
380 The TLS server model presented in this section contains one YANG
381 grouping, for just the TLS-level configuration, omitting, for
382 instance, configuration for which ports to open to listen for
383 connections on.
385 This grouping references data nodes defined by the keystore model
386 [I-D.ietf-netconf-keystore]. For instance, a reference to the
387 keystore model is made to indicate which certificate a server should
388 present.
390 4.1. Tree Diagram
392 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams]
393 provides an overview of the data model for the "ietf-tls-server"
394 module.
396 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
398 module: ietf-tls-server
400 grouping tls-server-grouping
401 +---- server-identity
402 | +---- algorithm? identityref
403 | +---- private-key? union
404 | +---- public-key? binary
405 | +---x generate-private-key
406 | | +---w input
407 | | +---w algorithm identityref
408 | +---- certificates
409 | | +---- certificate* [name]
410 | | +---- name? string
411 | | +---- value? binary
412 | +---x generate-certificate-signing-request
413 | +---w input
414 | | +---w subject binary
415 | | +---w attributes? binary
416 | +--ro output
417 | +--ro certificate-signing-request binary
418 +---- client-auth
419 | +---- pinned-ca-certs? ks:pinned-certificates
420 | +---- pinned-client-certs? ks:pinned-certificates
421 +---- hello-params {tls-server-hello-params-config}?
422 +---- tls-versions
423 | +---- tls-version* identityref
424 +---- cipher-suites
425 +---- cipher-suite* identityref
427 4.2. Example Usage
429 This section shows how it would appear if the tls-server-grouping
430 were populated with some data. This example is consistent with the
431 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].
433 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
435 [ note: '\' line wrapping for formatting only]
437
439
440
441 k\
442 s:secp521r1
443 base64encodedvalue==
444 base64encodedvalue==
445
446
447 domain certificate
448 base64encodedvalue==
449
450
451
453
454
455 deployment-specific-ca-certs
456 explicitly-trusted-client-certs
458
460
462 4.3. YANG Module
464 This YANG module has a normative references to [RFC6991], and
465 [I-D.ietf-netconf-keystore].
467 file "ietf-tls-server@2017-10-30.yang"
468 module ietf-tls-server {
469 yang-version 1.1;
471 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
472 prefix "tlss";
474 import ietf-tls-common {
475 prefix tlscmn;
476 revision-date 2017-10-30; // stable grouping definitions
477 reference
478 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
479 }
481 import ietf-keystore {
482 prefix ks;
484 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
486 reference
487 "RFC YYYY: Keystore Model";
488 }
490 organization
491 "IETF NETCONF (Network Configuration) Working Group";
493 contact
494 "WG Web:
495 WG List:
497 Author: Kent Watsen
498
500 Author: Gary Wu
501 ";
503 description
504 "This module defines a reusable grouping for a TLS server that
505 can be used as a basis for specific TLS server instances.
507 Copyright (c) 2017 IETF Trust and the persons identified as
508 authors of the code. All rights reserved.
510 Redistribution and use in source and binary forms, with or
511 without modification, is permitted pursuant to, and subject
512 to the license terms contained in, the Simplified BSD
513 License set forth in Section 4.c of the IETF Trust's
514 Legal Provisions Relating to IETF Documents
515 (http://trustee.ietf.org/license-info).
517 This version of this YANG module is part of RFC XXXX; see
518 the RFC itself for full legal notices.";
520 revision "2017-10-30" {
521 description
522 "Initial version";
523 reference
524 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
525 }
527 // features
529 feature tls-server-hello-params-config {
530 description
531 "TLS hello message parameters are configurable on a TLS
532 server.";
534 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
536 }
538 // groupings
540 grouping tls-server-grouping {
541 description
542 "A reusable grouping for configuring a TLS server without
543 any consideration for how underlying TCP sessions are
544 established.";
546 container server-identity {
547 description
548 "The list of certificates the TLS server will present when
549 establishing a TLS connection in its Certificate message,
550 as defined in Section 7.4.2 in RFC 5246.";
551 reference
552 "RFC 5246:
553 The Transport Layer Security (TLS) Protocol Version 1.2";
554 uses ks:private-key-grouping;
555 uses ks:certificate-grouping;
556 }
558 container client-auth {
559 description
560 "A reference to a list of pinned certificate authority (CA)
561 certificates and a reference to a list of pinned client
562 certificates.";
563 leaf pinned-ca-certs {
564 type ks:pinned-certificates;
565 description
566 "A reference to a list of certificate authority (CA)
567 certificates used by the TLS server to authenticate
568 TLS client certificates. A client certificate is
569 authenticated if it has a valid chain of trust to
570 a configured pinned CA certificate.";
571 }
572 leaf pinned-client-certs {
573 type ks:pinned-certificates;
574 description
575 "A reference to a list of client certificates used by
576 the TLS server to authenticate TLS client certificates.
577 A clients certificate is authenticated if it is an
578 exact match to a configured pinned client certificate.";
579 }
580 }
582 container hello-params {
584 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
586 if-feature tls-server-hello-params-config;
587 uses tlscmn:hello-params-grouping;
588 description
589 "Configurable parameters for the TLS hello message.";
590 }
592 } // end tls-server-grouping
594 }
595
597 5. The TLS Common Model
599 The TLS common model presented in this section contains identities
600 and groupings common to both TLS clients and TLS servers. The hello-
601 params-grouping can be used to configure the list of TLS algorithms
602 permitted by the TLS client or TLS server. The lists of algorithms
603 are ordered such that, if multiple algorithms are permitted by the
604 client, the algorithm that appears first in its list that is also
605 permitted by the server is used for the TLS transport layer
606 connection. The ability to restrict the the algorithms allowed is
607 provided in this grouping for TLS clients and TLS servers that are
608 capable of doing so and may serve to make TLS clients and TLS servers
609 compliant with security policies.
611 Features are defined for algorithms that are OPTIONAL or are not
612 widely supported by popular implementations. Note that the list of
613 algorithms is not exhaustive.
615 5.1. Tree Diagram
617 The following tree diagram [I-D.ietf-netmod-yang-tree-diagrams]
618 provides an overview of the data model for the "ietf-tls-common"
619 module.
621 module: ietf-tls-common
623 grouping hello-params-grouping
624 +---- tls-versions
625 | +---- tls-version* identityref
626 +---- cipher-suites
627 +---- cipher-suite* identityref
629 5.2. Example Usage
631 This section shows how it would appear if the transport-params-
632 grouping were populated with some data.
634 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
636
637
640
641 tlscmn:tls-1.1
642 tlscmn:tls-1.2
643
644
645 tlscmn:dhe-rsa-with-aes-128-cbc-sha
646 tlscmn:rsa-with-aes-128-cbc-sha
647 tlscmn:rsa-with-3des-ede-cbc-sha
648
649
651 5.3. YANG Module
653 This YANG module has a normative references to [RFC2246], [RFC4346],
654 [RFC4492], [RFC5246], [RFC5288], and [RFC5289].
656 file "ietf-tls-common@2017-10-30.yang"
657 module ietf-tls-common {
658 yang-version 1.1;
660 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
661 prefix "tlscmn";
663 organization
664 "IETF NETCONF (Network Configuration) Working Group";
666 contact
667 "WG Web:
668 WG List:
670 Author: Kent Watsen
671
673 Author: Gary Wu
674 ";
676 description
677 "This module defines a common features, identities, and groupings
678 for Transport Layer Security (TLS).
680 Copyright (c) 2017 IETF Trust and the persons identified as
681 authors of the code. All rights reserved.
683 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
685 Redistribution and use in source and binary forms, with or
686 without modification, is permitted pursuant to, and subject
687 to the license terms contained in, the Simplified BSD
688 License set forth in Section 4.c of the IETF Trust's
689 Legal Provisions Relating to IETF Documents
690 (http://trustee.ietf.org/license-info).
692 This version of this YANG module is part of RFC XXXX; see
693 the RFC itself for full legal notices.";
695 revision "2017-10-30" {
696 description
697 "Initial version";
698 reference
699 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
700 }
702 // features
704 feature tls-1_0 {
705 description
706 "TLS Protocol Version 1.0 is supported.";
707 reference
708 "RFC 2246: The TLS Protocol Version 1.0";
709 }
711 feature tls-1_1 {
712 description
713 "TLS Protocol Version 1.1 is supported.";
714 reference
715 "RFC 4346: The Transport Layer Security (TLS) Protocol
716 Version 1.1";
717 }
719 feature tls-1_2 {
720 description
721 "TLS Protocol Version 1.2 is supported.";
722 reference
723 "RFC 5246: The Transport Layer Security (TLS) Protocol
724 Version 1.2";
725 }
727 feature tls-ecc {
728 description
729 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
730 reference
731 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
732 for Transport Layer Security (TLS)";
734 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
736 }
738 feature tls-dhe {
739 description
740 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
741 reference
742 "RFC 5246: The Transport Layer Security (TLS) Protocol
743 Version 1.2";
744 }
746 feature tls-3des {
747 description
748 "The Triple-DES block cipher is supported for TLS.";
749 reference
750 "RFC 5246: The Transport Layer Security (TLS) Protocol
751 Version 1.2";
752 }
754 feature tls-gcm {
755 description
756 "The Galois/Counter Mode authenticated encryption mode is
757 supported for TLS.";
758 reference
759 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
760 TLS";
761 }
763 feature tls-sha2 {
764 description
765 "The SHA2 family of cryptographic hash functions is supported
766 for TLS.";
767 reference
768 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
769 }
771 // identities
773 identity tls-version-base {
774 description
775 "Base identity used to identify TLS protocol versions.";
776 }
778 identity tls-1.0 {
779 base tls-version-base;
780 if-feature tls-1_0;
781 description
782 "TLS Protocol Version 1.0.";
783 reference
785 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
787 "RFC 2246: The TLS Protocol Version 1.0";
788 }
790 identity tls-1.1 {
791 base tls-version-base;
792 if-feature tls-1_1;
793 description
794 "TLS Protocol Version 1.1.";
795 reference
796 "RFC 4346: The Transport Layer Security (TLS) Protocol
797 Version 1.1";
798 }
800 identity tls-1.2 {
801 base tls-version-base;
802 if-feature tls-1_2;
803 description
804 "TLS Protocol Version 1.2.";
805 reference
806 "RFC 5246: The Transport Layer Security (TLS) Protocol
807 Version 1.2";
808 }
810 identity cipher-suite-base {
811 description
812 "Base identity used to identify TLS cipher suites.";
813 }
815 identity rsa-with-aes-128-cbc-sha {
816 base cipher-suite-base;
817 description
818 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
819 reference
820 "RFC 5246: The Transport Layer Security (TLS) Protocol
821 Version 1.2";
822 }
824 identity rsa-with-aes-256-cbc-sha {
825 base cipher-suite-base;
826 description
827 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
828 reference
829 "RFC 5246: The Transport Layer Security (TLS) Protocol
830 Version 1.2";
831 }
833 identity rsa-with-aes-128-cbc-sha256 {
834 base cipher-suite-base;
836 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
838 if-feature tls-sha2;
839 description
840 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
841 reference
842 "RFC 5246: The Transport Layer Security (TLS) Protocol
843 Version 1.2";
844 }
846 identity rsa-with-aes-256-cbc-sha256 {
847 base cipher-suite-base;
848 if-feature tls-sha2;
849 description
850 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
851 reference
852 "RFC 5246: The Transport Layer Security (TLS) Protocol
853 Version 1.2";
854 }
856 identity dhe-rsa-with-aes-128-cbc-sha {
857 base cipher-suite-base;
858 if-feature tls-dhe;
859 description
860 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
861 reference
862 "RFC 5246: The Transport Layer Security (TLS) Protocol
863 Version 1.2";
864 }
866 identity dhe-rsa-with-aes-256-cbc-sha {
867 base cipher-suite-base;
868 if-feature tls-dhe;
869 description
870 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
871 reference
872 "RFC 5246: The Transport Layer Security (TLS) Protocol
873 Version 1.2";
874 }
876 identity dhe-rsa-with-aes-128-cbc-sha256 {
877 base cipher-suite-base;
878 if-feature "tls-dhe and tls-sha2";
879 description
880 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
881 reference
882 "RFC 5246: The Transport Layer Security (TLS) Protocol
883 Version 1.2";
884 }
886 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
888 identity dhe-rsa-with-aes-256-cbc-sha256 {
889 base cipher-suite-base;
890 if-feature "tls-dhe and tls-sha2";
891 description
892 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
893 reference
894 "RFC 5246: The Transport Layer Security (TLS) Protocol
895 Version 1.2";
896 }
898 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
899 base cipher-suite-base;
900 if-feature "tls-ecc and tls-sha2";
901 description
902 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
903 reference
904 "RFC 5289: TLS Elliptic Curve Cipher Suites with
905 SHA-256/384 and AES Galois Counter Mode (GCM)";
906 }
908 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
909 base cipher-suite-base;
910 if-feature "tls-ecc and tls-sha2";
911 description
912 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
913 reference
914 "RFC 5289: TLS Elliptic Curve Cipher Suites with
915 SHA-256/384 and AES Galois Counter Mode (GCM)";
916 }
918 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
919 base cipher-suite-base;
920 if-feature "tls-ecc and tls-sha2";
921 description
922 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
923 reference
924 "RFC 5289: TLS Elliptic Curve Cipher Suites with
925 SHA-256/384 and AES Galois Counter Mode (GCM)";
926 }
928 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
929 base cipher-suite-base;
930 if-feature "tls-ecc and tls-sha2";
931 description
932 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
933 reference
934 "RFC 5289: TLS Elliptic Curve Cipher Suites with
935 SHA-256/384 and AES Galois Counter Mode (GCM)";
937 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
939 }
941 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
942 base cipher-suite-base;
943 if-feature "tls-ecc and tls-gcm and tls-sha2";
944 description
945 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
946 reference
947 "RFC 5289: TLS Elliptic Curve Cipher Suites with
948 SHA-256/384 and AES Galois Counter Mode (GCM)";
949 }
951 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
952 base cipher-suite-base;
953 if-feature "tls-ecc and tls-gcm and tls-sha2";
954 description
955 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
956 reference
957 "RFC 5289: TLS Elliptic Curve Cipher Suites with
958 SHA-256/384 and AES Galois Counter Mode (GCM)";
959 }
961 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
962 base cipher-suite-base;
963 if-feature "tls-ecc and tls-gcm and tls-sha2";
964 description
965 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
966 reference
967 "RFC 5289: TLS Elliptic Curve Cipher Suites with
968 SHA-256/384 and AES Galois Counter Mode (GCM)";
969 }
971 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
972 base cipher-suite-base;
973 if-feature "tls-ecc and tls-gcm and tls-sha2";
974 description
975 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
976 reference
977 "RFC 5289: TLS Elliptic Curve Cipher Suites with
978 SHA-256/384 and AES Galois Counter Mode (GCM)";
979 }
981 identity rsa-with-3des-ede-cbc-sha {
982 base cipher-suite-base;
983 if-feature tls-3des;
984 description
985 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
986 reference
988 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
990 "RFC 5246: The Transport Layer Security (TLS) Protocol
991 Version 1.2";
992 }
994 identity ecdhe-rsa-with-3des-ede-cbc-sha {
995 base cipher-suite-base;
996 if-feature "tls-ecc and tls-3des";
997 description
998 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
999 reference
1000 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
1001 for Transport Layer Security (TLS)";
1002 }
1004 identity ecdhe-rsa-with-aes-128-cbc-sha {
1005 base cipher-suite-base;
1006 if-feature "tls-ecc";
1007 description
1008 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
1009 reference
1010 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
1011 for Transport Layer Security (TLS)";
1012 }
1014 identity ecdhe-rsa-with-aes-256-cbc-sha {
1015 base cipher-suite-base;
1016 if-feature "tls-ecc";
1017 description
1018 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1019 reference
1020 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
1021 for Transport Layer Security (TLS)";
1022 }
1024 // groupings
1026 grouping hello-params-grouping {
1027 description
1028 "A reusable grouping for TLS hello message parameters.";
1029 reference
1030 "RFC 5246: The Transport Layer Security (TLS) Protocol
1031 Version 1.2";
1033 container tls-versions {
1034 description
1035 "Parameters regarding TLS versions.";
1036 leaf-list tls-version {
1037 type identityref {
1039 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1041 base tls-version-base;
1042 }
1043 description
1044 "Acceptable TLS protocol versions.
1046 If this leaf-list is not configured (has zero elements)
1047 the acceptable TLS protocol versions are implementation-
1048 defined.";
1049 }
1050 }
1051 container cipher-suites {
1052 description
1053 "Parameters regarding cipher suites.";
1054 leaf-list cipher-suite {
1055 type identityref {
1056 base cipher-suite-base;
1057 }
1058 ordered-by user;
1059 description
1060 "Acceptable cipher suites in order of descending
1061 preference.
1063 If this leaf-list is not configured (has zero elements)
1064 the acceptable cipher suites are implementation-
1065 defined.";
1066 }
1067 }
1069 } // end hello-params-grouping
1071 }
1072
1074 6. Security Considerations
1076 The YANG modules defined in this document are designed to be accessed
1077 via YANG based management protocols, such as NETCONF [RFC6241] and
1078 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1079 implement secure transport layers (e.g., SSH, TLS) with mutual
1080 authentication.
1082 The NETCONF access control model (NACM) [RFC6536] provides the means
1083 to restrict access for particular users to a pre-configured subset of
1084 all available protocol operations and content.
1086 Since the modules defined in this document only define groupings,
1087 these considerations are primarily for the designers of other modules
1088 that use these groupings.
1090 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1092 There are a number of data nodes defined in the YANG modules that are
1093 writable/creatable/deletable (i.e., config true, which is the
1094 default). These data nodes may be considered sensitive or vulnerable
1095 in some network environments. Write operations (e.g., edit-config)
1096 to these data nodes without proper protection can have a negative
1097 effect on network operations. These are the subtrees and data nodes
1098 and their sensitivity/vulnerability:
1100 /: The entire data tree of all the groupings defined in this draft
1101 is sensitive to write operations. For instance, the addition
1102 or removal of references to keys, certificates, trusted
1103 anchors, etc., can dramatically alter the implemented security
1104 policy. However, no NACM annotations are applied as the data
1105 SHOULD be editable by users other than a designated 'recovery
1106 session'.
1108 Some of the readable data nodes in the YANG modules may be considered
1109 sensitive or vulnerable in some network environments. It is thus
1110 important to control read access (e.g., via get, get-config, or
1111 notification) to these data nodes. These are the subtrees and data
1112 nodes and their sensitivity/vulnerability:
1114 NONE
1116 Some of the RPC operations in this YANG module may be considered
1117 sensitive or vulnerable in some network environments. It is thus
1118 important to control access to these operations. These are the
1119 operations and their sensitivity/vulnerability:
1121 NONE
1123 7. IANA Considerations
1125 7.1. The IETF XML Registry
1127 This document registers three URIs in the IETF XML registry
1128 [RFC3688]. Following the format in [RFC3688], the following
1129 registrations are requested:
1131 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1133 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1134 Registrant Contact: The NETCONF WG of the IETF.
1135 XML: N/A, the requested URI is an XML namespace.
1137 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1138 Registrant Contact: The NETCONF WG of the IETF.
1139 XML: N/A, the requested URI is an XML namespace.
1141 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1142 Registrant Contact: The NETCONF WG of the IETF.
1143 XML: N/A, the requested URI is an XML namespace.
1145 7.2. The YANG Module Names Registry
1147 This document registers three YANG modules in the YANG Module Names
1148 registry [RFC7950]. Following the format in [RFC7950], the the
1149 following registrations are requested:
1151 name: ietf-tls-client
1152 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1153 prefix: tlsc
1154 reference: RFC XXXX
1156 name: ietf-tls-server
1157 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1158 prefix: tlss
1159 reference: RFC XXXX
1161 name: ietf-tls-common
1162 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1163 prefix: tlscmn
1164 reference: RFC XXXX
1166 8. Acknowledgements
1168 The authors would like to thank for following for lively discussions
1169 on list and in the halls (ordered by last name): Andy Bierman, Martin
1170 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
1171 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
1172 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
1174 9. References
1176 9.1. Normative References
1178 [I-D.ietf-netconf-keystore]
1179 Watsen, K., "Keystore Model", draft-ietf-netconf-
1180 keystore-02 (work in progress), June 2017.
1182 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1185 Requirement Levels", BCP 14, RFC 2119,
1186 DOI 10.17487/RFC2119, March 1997,
1187 .
1189 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1190 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1191 .
1193 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1194 (TLS) Protocol Version 1.1", RFC 4346,
1195 DOI 10.17487/RFC4346, April 2006,
1196 .
1198 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
1199 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
1200 for Transport Layer Security (TLS)", RFC 4492,
1201 DOI 10.17487/RFC4492, May 2006,
1202 .
1204 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1205 (TLS) Protocol Version 1.2", RFC 5246,
1206 DOI 10.17487/RFC5246, August 2008,
1207 .
1209 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1210 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1211 DOI 10.17487/RFC5288, August 2008,
1212 .
1214 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1215 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1216 DOI 10.17487/RFC5289, August 2008,
1217 .
1219 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
1220 Protocol (NETCONF) Access Control Model", RFC 6536,
1221 DOI 10.17487/RFC6536, March 2012,
1222 .
1224 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1225 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1226 .
1228 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1230 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1231 NETCONF Protocol over Transport Layer Security (TLS) with
1232 Mutual X.509 Authentication", RFC 7589,
1233 DOI 10.17487/RFC7589, June 2015,
1234 .
1236 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1237 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1238 .
1240 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1241 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1242 May 2017, .
1244 9.2. Informative References
1246 [I-D.ietf-netmod-yang-tree-diagrams]
1247 Bjorklund, M. and L. Berger, "YANG Tree Diagrams", draft-
1248 ietf-netmod-yang-tree-diagrams-02 (work in progress),
1249 October 2017.
1251 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1252 DOI 10.17487/RFC2818, May 2000,
1253 .
1255 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1256 DOI 10.17487/RFC3688, January 2004,
1257 .
1259 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1260 and A. Bierman, Ed., "Network Configuration Protocol
1261 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1262 .
1264 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1265 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1266 .
1268 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1269 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1270 .
1272 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1274 Appendix A. Change Log
1276 A.1. 00 to 01
1278 o Noted that '0.0.0.0' and '::' might have special meanings.
1280 o Renamed "keychain" to "keystore".
1282 A.2. 01 to 02
1284 o Removed the groupings containing transport-level configuration.
1285 Now modules contain only the transport-independent groupings.
1287 o Filled in previously incomplete 'ietf-tls-client' module.
1289 o Added cipher suites for various algorithms into new 'ietf-tls-
1290 common' module.
1292 A.3. 02 to 03
1294 o Added a 'must' statement to container 'server-auth' asserting that
1295 at least one of the various auth mechanisms must be specified.
1297 o Fixed description statement for leaf 'trusted-ca-certs'.
1299 A.4. 03 to 04
1301 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
1303 o Updated leafref paths to point to new keystore path
1305 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
1306 'tlscmn'.
1308 o Added TLS protocol verions 1.0 and 1.1.
1310 o Made author lists consistent
1312 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
1314 o Updated YANG to use typedefs around leafrefs to common keystore
1315 paths
1317 o Now inlines key and certificates (no longer a leafref to keystore)
1319 Internet-DrafYANG Groupings for TLS Clients and TLS Servers October 2017
1321 Authors' Addresses
1323 Kent Watsen
1324 Juniper Networks
1326 EMail: kwatsen@juniper.net
1328 Gary Wu
1329 Cisco Systems
1331 EMail: garywu@cisco.com