idnits 2.17.1
draft-ietf-netconf-tls-client-server-02.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 8 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 seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (March 13, 2017) is 2601 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-00
** 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: 4 errors (**), 0 flaws (~~), 3 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: September 14, 2017 Cisco Systems
6 March 13, 2017
8 TLS Client and Server Models
9 draft-ietf-netconf-tls-client-server-02
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-03-13" --> the publication date of this draft
45 The following two Appendix sections are to be removed prior to
46 publication:
48 o Appendix A. Change Log
49 o Appendix B. Open Issues
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 http://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 September 14, 2017.
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 (http://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
99 4.3. YANG Model . . . . . . . . . . . . . . . . . . . . . . . 13
100 5. Security Considerations . . . . . . . . . . . . . . . . . . . 21
101 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
102 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 22
103 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 22
104 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
105 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
106 8.1. Normative References . . . . . . . . . . . . . . . . . . 23
107 8.2. Informative References . . . . . . . . . . . . . . . . . 24
108 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
109 A.1. server-model-09 to 00 . . . . . . . . . . . . . . . . . . 25
110 A.2. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 25
111 A.3. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 25
112 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 25
113 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
115 1. Introduction
117 This document defines three YANG [RFC7950] modules: the first defines
118 a grouping for a generic TLS client, the second defines a grouping
119 for a generic TLS server, and the third defines identities and
120 groupings common to both the client and the server (TLS is defined in
121 [RFC5246]). It is intended that these groupings will be used by
122 applications using the TLS protocol. For instance, these groupings
123 could be used to help define the data model for an HTTPS [RFC2818]
124 server or a NETCONF over TLS [RFC7589] based server.
126 The client and server YANG modules in this document each define one
127 grouping, which is focused on just TLS-specific configuration, and
128 specifically avoids any transport-level configuration, such as what
129 ports to listen-on or connect-to. This enables applications the
130 opportunity to define their own strategy for how the underlying TCP
131 connection is established. For instance, applications supporting
132 NETCONF Call Home [RFC8071] could use the grouping for the TLS parts
133 it provides, while adding data nodes for the TCP-level call-home
134 configuration.
136 1.1. Terminology
138 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
140 document are to be interpreted as described in RFC 2119 [RFC2119].
142 1.2. Tree Diagrams
144 A simplified graphical representation of the data models is used in
145 this document. The meaning of the symbols in these diagrams is as
146 follows:
148 o Brackets "[" and "]" enclose list keys.
150 o Braces "{" and "}" enclose feature names, and indicate that the
151 named feature must be present for the subtree to be present.
153 o Abbreviations before data node names: "rw" means configuration
154 (read-write) and "ro" state data (read-only).
156 o Symbols after data node names: "?" means an optional node, "!"
157 means a presence container, and "*" denotes a list and leaf-list.
159 o Parentheses enclose choice and case nodes, and case nodes are also
160 marked with a colon (":").
162 o Ellipsis ("...") stands for contents of subtrees that are not
163 shown.
165 2. The TLS Client Model
167 The TLS client model presented in this section contains one YANG
168 grouping, to just configure the TLS client omitting, for instance,
169 any configuration for which IP address or port the client should
170 connect to.
172 This grouping references data nodes defined by the keystore model
173 [I-D.ietf-netconf-keystore]. For instance, a reference to the
174 keystore model is made to indicate which trusted CA certificate a
175 client should use to authenticate the server's certificate.
177 2.1. Tree Diagram
179 The following tree diagram presents the data model for the grouping
180 defined in the ietf-tls-client module. Please see Section 1.2 for
181 tree diagram notation.
183 module: ietf-tls-client
184 groupings:
185 tls-client-grouping
186 +---- server-auth
187 | +---- trusted-ca-certs?
188 | | -> /ks:keystore/trusted-certificates/name
189 | +---- trusted-server-certs?
190 | -> /ks:keystore/trusted-certificates/name
191 +---- client-auth
192 | +---- (auth-type)?
193 | +--:(certificate)
194 | +---- certificate? leafref
195 +---- hello-params {tls-client-hello-params-config}?
196 +---- tls-versions
197 | +---- tls-version* identityref
198 +---- cipher-suites
199 +---- cipher-suite* identityref
201 2.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
208
210
211
212 deployment-specific-ca-certs
213 explicitly-trusted-client-certs
214
216
217
218 builtin-idevid-cert
219
221
223 2.3. YANG Model
225 This YANG module has a normative references to [RFC6991] and
226 [I-D.ietf-netconf-keystore].
228 file "ietf-tls-client@2017-03-13.yang"
229 module ietf-tls-client {
230 yang-version 1.1;
232 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
233 prefix "tlsc";
235 import ietf-tls-common {
236 prefix tlscom;
237 revision-date 2017-03-13; // stable grouping definitions
238 reference
239 "RFC XXXX: TLS Client and Server Models";
240 }
242 import ietf-keystore {
243 prefix ks;
244 reference
245 "RFC YYYY: Keystore Model";
246 }
248 organization
249 "IETF NETCONF (Network Configuration) Working Group";
251 contact
252 "WG Web:
253 WG List:
255 Author: Kent Watsen
256 ";
258 description
259 "This module defines a reusable grouping for a TLS client that
260 can be used as a basis for specific TLS client instances.
262 Copyright (c) 2014 IETF Trust and the persons identified as
263 authors of the code. All rights reserved.
265 Redistribution and use in source and binary forms, with or
266 without modification, is permitted pursuant to, and subject
267 to the license terms contained in, the Simplified BSD
268 License set forth in Section 4.c of the IETF Trust's
269 Legal Provisions Relating to IETF Documents
270 (http://trustee.ietf.org/license-info).
272 This version of this YANG module is part of RFC XXXX; see
273 the RFC itself for full legal notices.";
275 revision "2017-03-13" {
276 description
277 "Initial version";
278 reference
279 "RFC XXXX: TLS Client and Server Models";
280 }
282 feature tls-client-hello-params-config {
283 description
284 "TLS hello message parameters are configurable on a TLS
285 client.";
286 }
288 grouping tls-client-grouping {
289 description
290 "A reusable grouping for configuring a TLS client without
291 any consideration for how an underlying TCP session is
292 established.";
294 container server-auth {
295 description
296 "Trusted server identities.";
298 leaf trusted-ca-certs {
299 type leafref {
300 path "/ks:keystore/ks:trusted-certificates/ks:name";
301 }
302 description
303 "A reference to a list of certificate authority (CA)
304 certificates used by the TLS client to authenticate
305 TLS server certificates.";
306 }
308 leaf trusted-server-certs {
309 type leafref {
310 path "/ks:keystore/ks:trusted-certificates/ks:name";
311 }
312 description
313 "A reference to a list of server certificates used by
314 the TLS client to authenticate TLS server certificates.
315 A server certificate is authenticated if it is an
316 exact match to a configured trusted server certificate.";
317 }
318 }
320 container client-auth {
321 description
322 "The credentials used by the client to authenticate to
323 the TLS server.";
325 choice auth-type {
326 description
327 "The authentication type.";
328 leaf certificate {
329 type leafref {
330 path "/ks:keystore/ks:keys/ks:key/ks:certificates"
331 + "/ks:certificate/ks:name";
332 }
333 description
334 "A certificates to be used for user authentication.";
335 }
336 }
337 }
339 container hello-params {
340 if-feature tls-client-hello-params-config;
341 uses tlscom:hello-params-grouping;
342 description
343 "Configurable parameters for the TLS hello message.";
344 }
346 } // end tls-client-grouping
348 }
350
352 3. The TLS Server Model
354 The TLS server model presented in this section contains one YANG
355 grouping, for just the TLS-level configuration omitting, for
356 instance, configuration for which ports to open to listen for
357 connections on.
359 This grouping references data nodes defined by the keystore model
360 [I-D.ietf-netconf-keystore]. For instance, a reference to the
361 keystore model is made to indicate which certificate a server should
362 present.
364 3.1. Tree Diagram
366 The following tree diagram presents the data model for the grouping
367 defined in the ietf-tls-server module. Please see Section 1.2 for
368 tree diagram notation.
370 module: ietf-tls-server
371 groupings:
372 tls-server-grouping
373 +---- certificates
374 | +---- certificate* [name]
375 | +---- name? leafref
376 +---- client-auth
377 | +---- trusted-ca-certs?
378 | | -> /ks:keystore/trusted-certificates/name
379 | +---- trusted-client-certs?
380 | -> /ks:keystore/trusted-certificates/name
381 +---- hello-params {tls-server-hello-params-config}?
382 +---- tls-versions
383 | +---- tls-version* identityref
384 +---- cipher-suites
385 +---- cipher-suite* identityref
387 3.2. Example Usage
389 This section shows how it would appear if the tls-server-grouping
390 were populated with some data. This example is consistent with the
391 examples presented in Section 2.2 of [I-D.ietf-netconf-keystore].
393
395
397
398
399 tls-ec-cert
400
401
402
403 deployment-specific-ca-certs
404 explicitly-trusted-client-certs
405
406
408 3.3. YANG Model
410 This YANG module has a normative references to [RFC6991], and
411 [I-D.ietf-netconf-keystore].
413 file "ietf-tls-server@2017-03-13.yang"
415 module ietf-tls-server {
416 yang-version 1.1;
418 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
419 prefix "tlss";
421 import ietf-tls-common {
422 prefix tlscom;
423 revision-date 2017-03-13; // stable grouping definitions
424 reference
425 "RFC XXXX: TLS Client and Server Models";
426 }
428 import ietf-keystore {
429 prefix ks;
430 reference
431 "RFC YYYY: Keystore Model";
432 }
434 organization
435 "IETF NETCONF (Network Configuration) Working Group";
437 contact
438 "WG Web:
439 WG List:
441 Author: Kent Watsen
442 ";
444 description
445 "This module defines a reusable grouping for a TLS server that
446 can be used as a basis for specific TLS server instances.
448 Copyright (c) 2014 IETF Trust and the persons identified as
449 authors of the code. All rights reserved.
451 Redistribution and use in source and binary forms, with or
452 without modification, is permitted pursuant to, and subject
453 to the license terms contained in, the Simplified BSD
454 License set forth in Section 4.c of the IETF Trust's
455 Legal Provisions Relating to IETF Documents
456 (http://trustee.ietf.org/license-info).
458 This version of this YANG module is part of RFC XXXX; see
459 the RFC itself for full legal notices.";
461 revision "2017-03-13" {
462 description
463 "Initial version";
464 reference
465 "RFC XXXX: TLS Client and Server Models";
466 }
468 feature tls-server-hello-params-config {
469 description
470 "TLS hello message parameters are configurable on a TLS
471 server.";
472 }
474 // grouping
475 grouping tls-server-grouping {
476 description
477 "A reusable grouping for configuring a TLS server without
478 any consideration for how underlying TCP sessions are
479 established.";
480 container certificates {
481 description
482 "The list of certificates the TLS server will present when
483 establishing a TLS connection in its Certificate message,
484 as defined in Section 7.4.2 in RRC 5246.";
485 reference
486 "RFC 5246:
487 The Transport Layer Security (TLS) Protocol Version 1.2";
488 list certificate {
489 key name;
490 min-elements 1;
491 description
492 "An unordered list of certificates the TLS server can pick
493 from when sending its Server Certificate message.";
494 reference
495 "RFC 5246: The TLS Protocol, Section 7.4.2";
496 leaf name {
497 type leafref {
498 path "/ks:keystore/ks:keys/ks:key/ks:certificates/"
499 + "ks:certificate/ks:name";
500 }
501 description
502 "The name of the certificate in the keystore.";
503 }
504 }
505 }
507 container client-auth {
508 description
509 "A reference to a list of trusted certificate authority (CA)
510 certificates and a reference to a list of trusted client
511 certificates.";
512 leaf trusted-ca-certs {
513 type leafref {
514 path "/ks:keystore/ks:trusted-certificates/ks:name";
515 }
516 description
517 "A reference to a list of certificate authority (CA)
518 certificates used by the TLS server to authenticate
519 TLS client certificates.";
520 }
522 leaf trusted-client-certs {
523 type leafref {
524 path "/ks:keystore/ks:trusted-certificates/ks:name";
525 }
526 description
527 "A reference to a list of client certificates used by
528 the TLS server to authenticate TLS client certificates.
529 A clients certificate is authenticated if it is an
530 exact match to a configured trusted client certificate.";
531 }
532 }
534 container hello-params {
535 if-feature tls-server-hello-params-config;
536 uses tlscom:hello-params-grouping;
537 description
538 "Configurable parameters for the TLS hello message.";
539 }
541 } // end tls-server-grouping
543 }
545
547 4. The TLS Common Model
549 The TLS common model presented in this section contains identities
550 and groupings common to both TLS clients and TLS servers. The hello-
551 params-grouping can be used to configure the list of TLS algorithms
552 permitted by the TLS client or TLS server. The lists of algorithms
553 are ordered such that, if multiple algorithms are permitted by the
554 client, the algorithm that appears first in its list that is also
555 permitted by the server is used for the TLS transport layer
556 connection. The ability to restrict the the algorithms allowed is
557 provided in this grouping for TLS clients and TLS servers that are
558 capable of doing so and may serve to make TLS clients and TLS servers
559 compliant with security policies.
561 Features are defined for algorithms that are OPTIONAL or are not
562 widely supported by popular implementations. Note that the list of
563 algorithms is not exhaustive.
565 4.1. Tree Diagram
567 The following tree diagram presents the data model for the grouping
568 defined in the ietf-tls-common module. Please see Section 1.2 for
569 tree diagram notation.
571 module: ietf-tls-common
572 groupings:
573 hello-params-grouping
574 +---- tls-versions
575 | +---- tls-version* identityref
576 +---- cipher-suites
577 +---- cipher-suite* identityref
579 4.2. Example Usage
581 This section shows how it would appear if the transport-params-
582 grouping were populated with some data.
584
585
587
588 tls-1.2
589
590
591 ecdhe-rsa-with-3des-ede-cbc-sha
592 dhe-rsa-with-aes-128-cbc-sha
593 rsa-with-aes-128-cbc-sha
594 rsa-with-3des-ede-cbc-sha
595
597
599 4.3. YANG Model
601 This YANG module has a normative references to [RFC4492], [RFC5246],
602 [RFC5288], and [RFC5289].
604 file "ietf-tls-common@2017-03-13.yang"
606 module ietf-tls-common {
607 yang-version 1.1;
609 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
610 prefix "tlscom";
612 organization
613 "IETF NETCONF (Network Configuration) Working Group";
615 contact
616 "WG Web:
617 WG List:
619 Author: Kent Watsen
620
622 Author: Gary Wu
623 ";
625 description
626 "This module defines a common features, identities, and groupings
627 for Transport Layer Security (TLS).
629 Copyright (c) 2017 IETF Trust and the persons identified as
630 authors of the code. All rights reserved.
632 Redistribution and use in source and binary forms, with or
633 without modification, is permitted pursuant to, and subject
634 to the license terms contained in, the Simplified BSD
635 License set forth in Section 4.c of the IETF Trust's
636 Legal Provisions Relating to IETF Documents
637 (http://trustee.ietf.org/license-info).
639 This version of this YANG module is part of RFC XXXX; see
640 the RFC itself for full legal notices.";
642 revision "2017-03-13" {
643 description
644 "Initial version";
645 reference
646 "RFC XXXX: TLS Client and Server Models";
647 }
649 // features
650 feature tls-ecc {
651 description
652 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
653 reference
654 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
655 for Transport Layer Security (TLS)";
656 }
658 feature tls-dhe {
659 description
660 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
661 reference
662 "RFC 5246: The Transport Layer Security (TLS) Protocol
663 Version 1.2";
664 }
666 feature tls-3des {
667 description
668 "The Triple-DES block cipher is supported for TLS.";
669 reference
670 "RFC 5246: The Transport Layer Security (TLS) Protocol
671 Version 1.2";
672 }
674 feature tls-gcm {
675 description
676 "The Galois/Counter Mode authenticated encryption mode is
677 supported for TLS.";
678 reference
679 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS";
680 }
682 feature tls-sha2 {
683 description
684 "The SHA2 family of cryptographic hash functions is supported
685 for TLS.";
686 reference
687 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
688 }
690 // identities
691 identity tls-version-base {
692 description
693 "Base identity used to identify TLS protocol versions.";
694 }
696 identity tls-1.2 {
697 base tls-version-base;
698 description
699 "TLS protocol version 1.2.";
700 reference
701 "RFC 5246: The Transport Layer Security (TLS) Protocol
702 Version 1.2";
703 }
705 identity cipher-suite-base {
706 description
707 "Base identity used to identify TLS cipher suites.";
708 }
710 identity rsa-with-aes-128-cbc-sha {
711 base cipher-suite-base;
712 description
713 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
714 reference
715 "RFC 5246: The Transport Layer Security (TLS) Protocol
716 Version 1.2";
717 }
719 identity rsa-with-aes-256-cbc-sha {
720 base cipher-suite-base;
721 description
722 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
723 reference
724 "RFC 5246: The Transport Layer Security (TLS) Protocol
725 Version 1.2";
726 }
728 identity rsa-with-aes-128-cbc-sha256 {
729 base cipher-suite-base;
730 if-feature tls-sha2;
731 description
732 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
733 reference
734 "RFC 5246: The Transport Layer Security (TLS) Protocol
735 Version 1.2";
736 }
738 identity rsa-with-aes-256-cbc-sha256 {
739 base cipher-suite-base;
740 if-feature tls-sha2;
741 description
742 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
743 reference
744 "RFC 5246: The Transport Layer Security (TLS) Protocol
745 Version 1.2";
746 }
747 identity dhe-rsa-with-aes-128-cbc-sha {
748 base cipher-suite-base;
749 if-feature tls-dhe;
750 description
751 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
752 reference
753 "RFC 5246: The Transport Layer Security (TLS) Protocol
754 Version 1.2";
755 }
757 identity dhe-rsa-with-aes-256-cbc-sha {
758 base cipher-suite-base;
759 if-feature tls-dhe;
760 description
761 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
762 reference
763 "RFC 5246: The Transport Layer Security (TLS) Protocol
764 Version 1.2";
765 }
767 identity dhe-rsa-with-aes-128-cbc-sha256 {
768 base cipher-suite-base;
769 if-feature "tls-dhe and tls-sha2";
770 description
771 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
772 reference
773 "RFC 5246: The Transport Layer Security (TLS) Protocol
774 Version 1.2";
775 }
777 identity dhe-rsa-with-aes-256-cbc-sha256 {
778 base cipher-suite-base;
779 if-feature "tls-dhe and tls-sha2";
780 description
781 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
782 reference
783 "RFC 5246: The Transport Layer Security (TLS) Protocol
784 Version 1.2";
785 }
787 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
788 base cipher-suite-base;
789 if-feature "tls-ecc and tls-sha2";
790 description
791 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
792 reference
793 "RFC 5289: TLS Elliptic Curve Cipher Suites with
794 SHA-256/384 and AES Galois Counter Mode (GCM)";
796 }
798 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
799 base cipher-suite-base;
800 if-feature "tls-ecc and tls-sha2";
801 description
802 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
803 reference
804 "RFC 5289: TLS Elliptic Curve Cipher Suites with
805 SHA-256/384 and AES Galois Counter Mode (GCM)";
806 }
808 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
809 base cipher-suite-base;
810 if-feature "tls-ecc and tls-sha2";
811 description
812 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
813 reference
814 "RFC 5289: TLS Elliptic Curve Cipher Suites with
815 SHA-256/384 and AES Galois Counter Mode (GCM)";
816 }
818 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
819 base cipher-suite-base;
820 if-feature "tls-ecc and tls-sha2";
821 description
822 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
823 reference
824 "RFC 5289: TLS Elliptic Curve Cipher Suites with
825 SHA-256/384 and AES Galois Counter Mode (GCM)";
826 }
828 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
829 base cipher-suite-base;
830 if-feature "tls-ecc and tls-gcm and tls-sha2";
831 description
832 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
833 reference
834 "RFC 5289: TLS Elliptic Curve Cipher Suites with
835 SHA-256/384 and AES Galois Counter Mode (GCM)";
836 }
838 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
839 base cipher-suite-base;
840 if-feature "tls-ecc and tls-gcm and tls-sha2";
841 description
842 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
843 reference
844 "RFC 5289: TLS Elliptic Curve Cipher Suites with
845 SHA-256/384 and AES Galois Counter Mode (GCM)";
846 }
848 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
849 base cipher-suite-base;
850 if-feature "tls-ecc and tls-gcm and tls-sha2";
851 description
852 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
853 reference
854 "RFC 5289: TLS Elliptic Curve Cipher Suites with
855 SHA-256/384 and AES Galois Counter Mode (GCM)";
856 }
858 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
859 base cipher-suite-base;
860 if-feature "tls-ecc and tls-gcm and tls-sha2";
861 description
862 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
863 reference
864 "RFC 5289: TLS Elliptic Curve Cipher Suites with
865 SHA-256/384 and AES Galois Counter Mode (GCM)";
866 }
868 identity rsa-with-3des-ede-cbc-sha {
869 base cipher-suite-base;
870 if-feature tls-3des;
871 description
872 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
873 reference
874 "RFC 5246: The Transport Layer Security (TLS) Protocol
875 Version 1.2";
876 }
878 identity ecdhe-rsa-with-3des-ede-cbc-sha {
879 base cipher-suite-base;
880 if-feature "tls-ecc and tls-3des";
881 description
882 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
883 reference
884 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
885 for Transport Layer Security (TLS)";
886 }
888 identity ecdhe-rsa-with-aes-128-cbc-sha {
889 base cipher-suite-base;
890 if-feature "tls-ecc";
891 description
892 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
893 reference
894 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
895 for Transport Layer Security (TLS)";
896 }
898 identity ecdhe-rsa-with-aes-256-cbc-sha {
899 base cipher-suite-base;
900 if-feature "tls-ecc";
901 description
902 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
903 reference
904 "RFC 4492: Elliptic Curve Cryptography (ECC) Cipher Suites
905 for Transport Layer Security (TLS)";
906 }
908 // groupings
909 grouping hello-params-grouping {
910 description
911 "A reusable grouping for TLS hello message parameters. For
912 configurable parameters, a zero-element leaf-list indicates the
913 system default configuration for that parameter.";
914 reference
915 "RFC 5246: The Transport Layer Security (TLS) Protocol
916 Version 1.2";
917 container tls-versions {
918 description
919 "Parameters regarding TLS versions.";
920 leaf-list tls-version {
921 type identityref {
922 base tls-version-base;
923 }
924 description
925 "Allowed TLS protocol versions.";
926 }
927 }
928 container cipher-suites {
929 description
930 "Parameters regarding cipher suites.";
931 leaf-list cipher-suite {
932 type identityref {
933 base cipher-suite-base;
934 }
935 ordered-by user;
936 description
937 "Cipher suites in order of descending preference.";
938 }
939 }
941 }
942 }
944
946 5. Security Considerations
948 The YANG module defined in this document is designed to be accessed
949 via YANG based management protocols, such as NETCONF [RFC6241] and
950 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
951 implement secure transport layers (e.g., SSH, TLS) with mutual
952 authentication.
954 The NETCONF access control model (NACM) [RFC6536] provides the means
955 to restrict access for particular users to a pre-configured subset of
956 all available protocol operations and content.
958 There are a number of data nodes defined in this YANG module that are
959 writable/creatable/deletable (i.e., config true, which is the
960 default). These data nodes may be considered sensitive or vulnerable
961 in some network environments. Write operations (e.g., edit-config)
962 to these data nodes without proper protection can have a negative
963 effect on network operations. These are the subtrees and data nodes
964 and their sensitivity/vulnerability:
966 /: The entire data tree defined by this module is sensitive to
967 write operations. For instance, the addition or removal of
968 references to keys, certificates, trusted anchors, etc., can
969 dramatically alter the implemented security policy. However,
970 no NACM annotations are applied as the data SHOULD be editable
971 by users other than a designated 'recovery session'.
973 Some of the readable data nodes in this YANG module may be considered
974 sensitive or vulnerable in some network environments. It is thus
975 important to control read access (e.g., via get, get-config, or
976 notification) to these data nodes. These are the subtrees and data
977 nodes and their sensitivity/vulnerability:
979 NONE
981 Some of the RPC operations in this YANG module may be considered
982 sensitive or vulnerable in some network environments. It is thus
983 important to control access to these operations. These are the
984 operations and their sensitivity/vulnerability:
986 NONE
988 6. IANA Considerations
990 6.1. The IETF XML Registry
992 This document registers three URIs in the IETF XML registry
993 [RFC3688]. Following the format in [RFC3688], the following
994 registrations are requested:
996 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
997 Registrant Contact: The NETCONF WG of the IETF.
998 XML: N/A, the requested URI is an XML namespace.
1000 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1001 Registrant Contact: The NETCONF WG of the IETF.
1002 XML: N/A, the requested URI is an XML namespace.
1004 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1005 Registrant Contact: The NETCONF WG of the IETF.
1006 XML: N/A, the requested URI is an XML namespace.
1008 6.2. The YANG Module Names Registry
1010 This document registers three YANG modules in the YANG Module Names
1011 registry [RFC7950]. Following the format in [RFC7950], the the
1012 following registrations are requested:
1014 name: ietf-tls-client
1015 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1016 prefix: tlsc
1017 reference: RFC XXXX
1019 name: ietf-tls-server
1020 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1021 prefix: tlss
1022 reference: RFC XXXX
1024 name: ietf-tls-common
1025 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1026 prefix: tlss
1027 reference: RFC XXXX
1029 7. Acknowledgements
1031 The authors would like to thank for following for lively discussions
1032 on list and in the halls (ordered by last name): Andy Bierman, Martin
1033 Bjorklund, Benoit Claise, Mehmet Ersue, David Lamparter, Alan Luchuk,
1034 Ladislav Lhotka, Radek Krejci, Tom Petch, Juergen Schoenwaelder, Phil
1035 Shafer, Sean Turner, and Bert Wijnen.
1037 8. References
1039 8.1. Normative References
1041 [I-D.ietf-netconf-keystore]
1042 Watsen, K. and G. Wu, "Keystore Model", draft-ietf-
1043 netconf-keystore-00 (work in progress), October 2016.
1045 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1046 Requirement Levels", BCP 14, RFC 2119,
1047 DOI 10.17487/RFC2119, March 1997,
1048 .
1050 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
1051 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
1052 for Transport Layer Security (TLS)", RFC 4492,
1053 DOI 10.17487/RFC4492, May 2006,
1054 .
1056 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1057 (TLS) Protocol Version 1.2", RFC 5246,
1058 DOI 10.17487/RFC5246, August 2008,
1059 .
1061 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1062 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1063 DOI 10.17487/RFC5288, August 2008,
1064 .
1066 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1067 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1068 DOI 10.17487/RFC5289, August 2008,
1069 .
1071 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration
1072 Protocol (NETCONF) Access Control Model", RFC 6536,
1073 DOI 10.17487/RFC6536, March 2012,
1074 .
1076 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types",
1077 RFC 6991, DOI 10.17487/RFC6991, July 2013,
1078 .
1080 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1081 NETCONF Protocol over Transport Layer Security (TLS) with
1082 Mutual X.509 Authentication", RFC 7589,
1083 DOI 10.17487/RFC7589, June 2015,
1084 .
1086 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1087 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1088 .
1090 8.2. Informative References
1092 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1093 DOI 10.17487/RFC2818, May 2000,
1094 .
1096 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1097 DOI 10.17487/RFC3688, January 2004,
1098 .
1100 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1101 and A. Bierman, Ed., "Network Configuration Protocol
1102 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1103 .
1105 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1106 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1107 .
1109 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1110 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1111 .
1113 Appendix A. Change Log
1115 A.1. server-model-09 to 00
1117 o This draft was split out from draft-ietf-netconf-server-model-09.
1119 o Noted that '0.0.0.0' and '::' might have special meanings.
1121 A.2. 00 to 01
1123 o Renamed "keychain" to "keystore".
1125 A.3. 01 to 02
1127 o Removed the groupings containing transport-level configuration.
1128 Now modules contain only the transport-independent groupings.
1130 o Filled in previously incomplete 'ietf-tls-client' module.
1132 o Added cipher suites for various algorithms into new 'ietf-tls-
1133 common' module.
1135 Appendix B. Open Issues
1137 Please see: https://github.com/netconf-wg/tls-client-server/issues.
1139 Authors' Addresses
1141 Kent Watsen
1142 Juniper Networks
1144 EMail: kwatsen@juniper.net
1146 Gary Wu
1147 Cisco Systems
1149 EMail: garywu@cisco.com