idnits 2.17.1
draft-ietf-netconf-tls-client-server-09.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (March 9, 2019) is 1875 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Outdated reference: A later version (-34) exists of
draft-ietf-netconf-crypto-types-02
== Outdated reference: A later version (-35) exists of
draft-ietf-netconf-keystore-08
== Outdated reference: A later version (-28) exists of
draft-ietf-netconf-trust-anchors-03
-- Obsolete informational reference (is this intentional?): RFC 2246
(Obsoleted by RFC 4346)
-- Obsolete informational reference (is this intentional?): RFC 2818
(Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 4346
(Obsoleted by RFC 5246)
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 5 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 NETCONF Working Group K. Watsen
3 Internet-Draft Watsen Networks
4 Intended status: Standards Track G. Wu
5 Expires: September 10, 2019 Cisco Systems
6 L. Xia
7 Huawei
8 March 9, 2019
10 YANG Groupings for TLS Clients and TLS Servers
11 draft-ietf-netconf-tls-client-server-09
13 Abstract
15 This document defines three YANG modules: the first defines groupings
16 for a generic TLS client, the second defines groupings for a generic
17 TLS server, and the third defines common identities and groupings
18 used by both the client and the server. It is intended that these
19 groupings will be used by applications using the TLS protocol.
21 Editorial Note (To be removed by RFC Editor)
23 This draft contains many placeholder values that need to be replaced
24 with finalized values at the time of publication. This note
25 summarizes all of the substitutions that are needed. No other RFC
26 Editor instructions are specified elsewhere in this document.
28 This document contains references to other drafts in progress, both
29 in the Normative References section, as well as in body text
30 throughout. Please update the following references to reflect their
31 final RFC assignments:
33 o I-D.ietf-netconf-trust-anchors
35 o I-D.ietf-netconf-keystore
37 Artwork in this document contains shorthand references to drafts in
38 progress. Please apply the following replacements:
40 o "XXXX" --> the assigned RFC value for this draft
42 o "YYYY" --> the assigned RFC value for I-D.ietf-netconf-trust-
43 anchors
45 o "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-keystore
47 Artwork in this document contains placeholder values for the date of
48 publication of this draft. Please apply the following replacement:
50 o "2019-03-09" --> the publication date of this draft
52 The following Appendix section is to be removed prior to publication:
54 o Appendix A. Change Log
56 Status of This Memo
58 This Internet-Draft is submitted in full conformance with the
59 provisions of BCP 78 and BCP 79.
61 Internet-Drafts are working documents of the Internet Engineering
62 Task Force (IETF). Note that other groups may also distribute
63 working documents as Internet-Drafts. The list of current Internet-
64 Drafts is at https://datatracker.ietf.org/drafts/current/.
66 Internet-Drafts are draft documents valid for a maximum of six months
67 and may be updated, replaced, or obsoleted by other documents at any
68 time. It is inappropriate to use Internet-Drafts as reference
69 material or to cite them other than as "work in progress."
71 This Internet-Draft will expire on September 10, 2019.
73 Copyright Notice
75 Copyright (c) 2019 IETF Trust and the persons identified as the
76 document authors. All rights reserved.
78 This document is subject to BCP 78 and the IETF Trust's Legal
79 Provisions Relating to IETF Documents
80 (https://trustee.ietf.org/license-info) in effect on the date of
81 publication of this document. Please review these documents
82 carefully, as they describe your rights and restrictions with respect
83 to this document. Code Components extracted from this document must
84 include Simplified BSD License text as described in Section 4.e of
85 the Trust Legal Provisions and are provided without warranty as
86 described in the Simplified BSD License.
88 Table of Contents
90 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
91 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
92 3. The TLS Client Model . . . . . . . . . . . . . . . . . . . . 4
93 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 4
94 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5
95 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 6
96 4. The TLS Server Model . . . . . . . . . . . . . . . . . . . . 10
97 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10
98 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11
99 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 13
100 5. The TLS Common Model . . . . . . . . . . . . . . . . . . . . 17
101 5.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 25
102 5.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 25
103 5.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 25
104 6. Security Considerations . . . . . . . . . . . . . . . . . . . 34
105 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
106 7.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 35
107 7.2. The YANG Module Names Registry . . . . . . . . . . . . . 35
108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
109 8.1. Normative References . . . . . . . . . . . . . . . . . . 36
110 8.2. Informative References . . . . . . . . . . . . . . . . . 37
111 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 39
112 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 39
113 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 39
114 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 39
115 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 39
116 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 40
117 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 40
118 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 40
119 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 40
120 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 40
121 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
124 1. Introduction
126 This document defines three YANG 1.1 [RFC7950] modules: the first
127 defines a grouping for a generic TLS client, the second defines a
128 grouping for a generic TLS server, and the third defines identities
129 and groupings common to both the client and the server (TLS is
130 defined in [RFC5246]). It is intended that these groupings will be
131 used by applications using the TLS protocol. For instance, these
132 groupings could be used to help define the data model for an HTTPS
133 [RFC2818] server or a NETCONF over TLS [RFC7589] based server.
135 The client and server YANG modules in this document each define one
136 grouping, which is focused on just TLS-specific configuration, and
137 specifically avoids any transport-level configuration, such as what
138 ports to listen-on or connect-to. This affords applications the
139 opportunity to define their own strategy for how the underlying TCP
140 connection is established. For instance, applications supporting
141 NETCONF Call Home [RFC8071] could use the "ssh-server-grouping"
142 grouping for the TLS parts it provides, while adding data nodes for
143 the TCP-level call-home configuration.
145 The modules defined in this document use groupings defined in
146 [I-D.ietf-netconf-keystore] enabling keys to be either locally
147 defined or a reference to globally configured values.
149 2. Terminology
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
153 "OPTIONAL" in this document are to be interpreted as described in BCP
154 14 [RFC2119] [RFC8174] when, and only when, they appear in all
155 capitals, as shown here.
157 3. The TLS Client Model
159 3.1. Tree Diagram
161 This section provides a tree diagram [RFC8340] for the "ietf-tls-
162 client" module that does not have groupings expanded.
164 module: ietf-tls-client
166 grouping tls-client-grouping
167 +---u client-identity-grouping
168 +---u server-auth-grouping
169 +---u hello-params-grouping
170 +---u keepalives-grouping
171 grouping client-identity-grouping
172 +-- tls-client-identity
173 +-- (auth-type)?
174 +--:(certificate)
175 +-- certificate
176 +---u client-identity-grouping
177 grouping server-auth-grouping
178 +-- tls-server-auth
179 +-- pinned-ca-certs? ta:pinned-certificates-ref
180 | {ta:x509-certificates}?
181 +-- pinned-server-certs? ta:pinned-certificates-ref
182 {ta:x509-certificates}?
183 grouping hello-params-grouping
184 +-- tls-hello-params {tls-client-hello-params-config}?
185 +---u hello-params-grouping
186 grouping keepalives-grouping
187 +-- tls-keepalives {tls-client-keepalives}?
188 +-- max-wait? uint16
189 +-- max-attempts? uint8
191 3.2. Example Usage
193 This section presents two examples showing the tls-client-grouping
194 populated with some data. These examples are effectively the same
195 except the first configures the client identity using a local key
196 while the second uses a key configured in a keystore. Both examples
197 are consistent with the examples presented in Section 3 of
198 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
199 [I-D.ietf-netconf-keystore].
201 The following example configures the client identity using a local
202 key:
204 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
206
208
209
210
211
212 ct:rsa2048
214 base64encodedvalue==
215 base64encodedvalue==
216 base64encodedvalue==
217
218
219
221
222
223 explicitly-trusted-server-ca-certs
225 explicitly-trusted-server-certs
227
229
230 30
231 3
232
234
236 The following example configures the client identity using a key from
237 the keystore:
239 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
241
243
244
245
246 ex-rsa-cert
247
248
250
251
252 explicitly-trusted-server-ca-certs
254 explicitly-trusted-server-certs
256
258
259 30
260 3
261
263
265 3.3. YANG Module
267 This YANG module has normative references to
268 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
270 file "ietf-tls-client@2019-03-09.yang"
271 module ietf-tls-client {
272 yang-version 1.1;
273 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-client";
274 prefix "tlsc";
276 import ietf-tls-common {
277 prefix tlscmn;
278 revision-date 2019-03-09; // stable grouping definitions
279 reference
280 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
281 }
283 import ietf-trust-anchors {
284 prefix ta;
285 reference
286 "RFC YYYY: YANG Data Model for Global Trust Anchors";
288 }
290 import ietf-keystore {
291 prefix ks;
292 reference
293 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
294 }
296 organization
297 "IETF NETCONF (Network Configuration) Working Group";
299 contact
300 "WG Web:
301 WG List:
302 Author: Kent Watsen
303 Author: Gary Wu ";
305 description
306 "This module defines reusable groupings for TLS clients that
307 can be used as a basis for specific TLS client instances.
309 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
310 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
311 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
312 are to be interpreted as described in BCP 14 [RFC2119]
313 [RFC8174] when, and only when, they appear in all
314 capitals, as shown here.
316 Copyright (c) 2019 IETF Trust and the persons identified as
317 authors of the code. All rights reserved.
319 Redistribution and use in source and binary forms, with or
320 without modification, is permitted pursuant to, and subject
321 to the license terms contained in, the Simplified BSD
322 License set forth in Section 4.c of the IETF Trust's
323 Legal Provisions Relating to IETF Documents
324 (http://trustee.ietf.org/license-info).
326 This version of this YANG module is part of RFC XXXX; see
327 the RFC itself for full legal notices.";
329 revision "2019-03-09" {
330 description
331 "Initial version";
332 reference
333 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
334 }
335 // Features
337 feature tls-client-hello-params-config {
338 description
339 "TLS hello message parameters are configurable on a TLS
340 client.";
341 }
343 feature tls-client-keepalives {
344 description
345 "Per socket TLS keepalive parameters are configurable for
346 TLS clients on the server implementing this feature.";
347 }
349 // Groupings
351 grouping tls-client-grouping {
352 description
353 "A reusable grouping for configuring a TLS client without
354 any consideration for how an underlying TCP session is
355 established.";
356 uses client-identity-grouping;
357 uses server-auth-grouping;
358 uses hello-params-grouping;
359 uses keepalives-grouping;
360 }
362 grouping client-identity-grouping {
363 description
364 "A reusable grouping for configuring a TLS client identity.";
365 container tls-client-identity {
366 description
367 "The credentials used by the client to authenticate to
368 the TLS server.";
370 choice auth-type {
371 description
372 "The authentication type.";
373 container certificate {
374 uses
375 ks:local-or-keystore-end-entity-cert-with-key-grouping;
376 description
377 "A locally-defined or referenced certificate
378 to be used for client authentication.";
379 reference
380 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
381 }
382 }
384 }
385 }
387 grouping server-auth-grouping {
388 description
389 "A reusable grouping for configuring TLS server
390 authentication.";
391 container tls-server-auth {
392 must 'pinned-ca-certs or pinned-server-certs';
393 description
394 "Trusted server identities.";
395 leaf pinned-ca-certs {
396 if-feature "ta:x509-certificates";
397 type ta:pinned-certificates-ref;
398 description
399 "A reference to a list of certificate authority (CA)
400 certificates used by the TLS client to authenticate
401 TLS server certificates. A server certificate is
402 authenticated if it has a valid chain of trust to
403 a configured pinned CA certificate.";
404 }
405 leaf pinned-server-certs {
406 if-feature "ta:x509-certificates";
407 type ta:pinned-certificates-ref;
408 description
409 "A reference to a list of server certificates used by
410 the TLS client to authenticate TLS server certificates.
411 A server certificate is authenticated if it is an
412 exact match to a configured pinned server certificate.";
413 }
414 }
415 }
417 grouping hello-params-grouping {
418 description
419 "A reusable grouping for configuring a TLS transport
420 parameters.";
421 container tls-hello-params {
422 if-feature tls-client-hello-params-config;
423 uses tlscmn:hello-params-grouping;
424 description
425 "Configurable parameters for the TLS hello message.";
426 }
427 }
429 grouping keepalives-grouping {
430 description
431 "A reusable grouping for configuring TLS client keepalive
432 parameters.";
433 container tls-keepalives {
434 if-feature "tls-client-keepalives";
435 description
436 "Configures the keep-alive policy, to proactively test
437 the aliveness of the TLS server. An unresponsive
438 TLS server is dropped after approximately max-wait
439 * max-attempts seconds.";
440 leaf max-wait {
441 type uint16 {
442 range "1..max";
443 }
444 units seconds;
445 default 30;
446 description
447 "Sets the amount of time in seconds after which if no data
448 has been received from the TLS server, a TLS-level message
449 will be sent to test the aliveness of the TLS server.";
450 }
451 leaf max-attempts {
452 type uint8;
453 default 3;
454 description
455 "Sets the maximum number of sequential keep-alive messages
456 that can fail to obtain a response from the TLS server
457 before assuming the TLS server is no longer alive.";
458 }
459 }
460 }
461 }
462
464 4. The TLS Server Model
466 4.1. Tree Diagram
468 This section provides a tree diagram [RFC8340] for the "ietf-tls-
469 server" module that does not have groupings expanded.
471 module: ietf-tls-server
473 grouping tls-server-grouping
474 +---u server-identity-grouping
475 +---u client-auth-grouping
476 +---u hello-params-grouping
477 +---u keepalives-grouping
478 grouping server-identity-grouping
479 +-- tls-server-identity
480 +---u server-identity-grouping
481 grouping client-auth-grouping
482 +-- tls-client-auth
483 +-- pinned-ca-certs? ta:pinned-certificates-ref
484 | {ta:x509-certificates}?
485 +-- pinned-client-certs? ta:pinned-certificates-ref
486 {ta:x509-certificates}?
487 grouping hello-params-grouping
488 +-- tls-hello-params {tls-server-hello-params-config}?
489 +---u hello-params-grouping
490 grouping keepalives-grouping
491 +-- tls-keepalives {tls-server-keepalives}?
492 +-- max-wait? uint16
493 +-- max-attempts? uint8
495 4.2. Example Usage
497 This section presents two examples showing the tls-server-grouping
498 populated with some data. These examples are effectively the same
499 except the first configures the server identity using a local key
500 while the second uses a key configured in a keystore. Both examples
501 are consistent with the examples presented in Section 3 of
502 [I-D.ietf-netconf-trust-anchors] and Section 3.2 of
503 [I-D.ietf-netconf-keystore].
505 The following example configures the server identity using a local
506 key:
508 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
510
512
513
514
515 ct:rsa2048
517 base64encodedvalue==
518 base64encodedvalue==
519 base64encodedvalue==
520
521
523
524
525 explicitly-trusted-client-ca-certs
527 explicitly-trusted-client-certs
529
531
533 The following example configures the server identity using a key from
534 the keystore:
536 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) ===========
538
540
541
542 ex-rsa-cert
543
545
546
547 explicitly-trusted-client-ca-certs
549 explicitly-trusted-client-certs
551
553
555 4.3. YANG Module
557 This YANG module has a normative references to [RFC5246],
558 [I-D.ietf-netconf-trust-anchors] and [I-D.ietf-netconf-keystore].
560 file "ietf-tls-server@2019-03-09.yang"
561 module ietf-tls-server {
562 yang-version 1.1;
563 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-server";
564 prefix "tlss";
566 import ietf-tls-common {
567 prefix tlscmn;
568 revision-date 2019-03-09; // stable grouping definitions
569 reference
570 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
571 }
573 import ietf-trust-anchors {
574 prefix ta;
575 reference
576 "RFC YYYY: YANG Data Model for Global Trust Anchors";
577 }
579 import ietf-keystore {
580 prefix ks;
581 reference
582 "RFC ZZZZ: YANG Data Model for a 'Keystore' Mechanism";
583 }
585 organization
586 "IETF NETCONF (Network Configuration) Working Group";
588 contact
589 "WG Web:
590 WG List:
591 Author: Kent Watsen
592 Author: Gary Wu ";
594 description
595 "This module defines reusable groupings for TLS servers that
596 can be used as a basis for specific TLS server instances.
598 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
599 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
600 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
601 are to be interpreted as described in BCP 14 [RFC2119]
602 [RFC8174] when, and only when, they appear in all
603 capitals, as shown here.
605 Copyright (c) 2019 IETF Trust and the persons identified as
606 authors of the code. All rights reserved.
608 Redistribution and use in source and binary forms, with or
609 without modification, is permitted pursuant to, and subject
610 to the license terms contained in, the Simplified BSD
611 License set forth in Section 4.c of the IETF Trust's
612 Legal Provisions Relating to IETF Documents
613 (http://trustee.ietf.org/license-info).
615 This version of this YANG module is part of RFC XXXX; see
616 the RFC itself for full legal notices.";
618 revision "2019-03-09" {
619 description
620 "Initial version";
621 reference
622 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
623 }
625 // Features
627 feature tls-server-hello-params-config {
628 description
629 "TLS hello message parameters are configurable on a TLS
630 server.";
631 }
633 feature tls-server-keepalives {
634 description
635 "Per socket TLS keepalive parameters are configurable for
636 TLS servers on the server implementing this feature.";
637 }
639 // Groupings
641 grouping tls-server-grouping {
642 description
643 "A reusable grouping for configuring a TLS server without
644 any consideration for how underlying TCP sessions are
645 established.";
646 uses server-identity-grouping;
647 uses client-auth-grouping;
648 uses hello-params-grouping;
649 uses keepalives-grouping;
651 }
653 grouping server-identity-grouping {
654 description
655 "A reusable grouping for configuring a TLS server identity.";
656 container tls-server-identity {
657 description
658 "A locally-defined or referenced end-entity certificate,
659 including any configured intermediate certificates, the
660 TLS server will present when establishing a TLS connection
661 in its Certificate message, as defined in Section 7.4.2
662 in RFC 5246.";
663 reference
664 "RFC 5246:
665 The Transport Layer Security (TLS) Protocol Version 1.2
666 RFC ZZZZ:
667 YANG Data Model for a 'Keystore' Mechanism";
668 uses ks:local-or-keystore-end-entity-cert-with-key-grouping;
669 }
670 }
672 grouping client-auth-grouping {
673 description
674 "A reusable grouping for configuring a TLS client
675 authentication.";
676 container tls-client-auth {
677 description
678 "A reference to a list of pinned certificate authority (CA)
679 certificates and a reference to a list of pinned client
680 certificates.";
681 leaf pinned-ca-certs {
682 if-feature "ta:x509-certificates";
683 type ta:pinned-certificates-ref;
684 description
685 "A reference to a list of certificate authority (CA)
686 certificates used by the TLS server to authenticate
687 TLS client certificates. A client certificate is
688 authenticated if it has a valid chain of trust to
689 a configured pinned CA certificate.";
690 reference
691 "RFC YYYY: YANG Data Model for Global Trust Anchors";
692 }
693 leaf pinned-client-certs {
694 if-feature "ta:x509-certificates";
695 type ta:pinned-certificates-ref;
696 description
697 "A reference to a list of client certificates used by
698 the TLS server to authenticate TLS client certificates.
700 A clients certificate is authenticated if it is an
701 exact match to a configured pinned client certificate.";
702 reference
703 "RFC YYYY: YANG Data Model for Global Trust Anchors";
704 }
705 }
706 }
708 grouping hello-params-grouping {
709 description
710 "A reusable grouping for configuring a TLS transport
711 parameters.";
712 container tls-hello-params {
713 if-feature tls-server-hello-params-config;
714 uses tlscmn:hello-params-grouping;
715 description
716 "Configurable parameters for the TLS hello message.";
717 }
718 }
720 grouping keepalives-grouping {
721 description
722 "A reusable grouping for configuring TLS server keepalive
723 parameters.";
724 container tls-keepalives {
725 if-feature "tls-server-keepalives";
726 description
727 "Configures the keep-alive policy, to proactively test
728 the aliveness of the TLS client. An unresponsive
729 TLS client is dropped after approximately max-wait
730 * max-attempts seconds.";
731 leaf max-wait {
732 type uint16 {
733 range "1..max";
734 }
735 units seconds;
736 default 30;
737 description
738 "Sets the amount of time in seconds after which if no data
739 has been received from the TLS client, a TLS-level message
740 will be sent to test the aliveness of the TLS client.";
741 }
742 leaf max-attempts {
743 type uint8;
744 default 3;
745 description
746 "Sets the maximum number of sequential keep-alive messages
747 that can fail to obtain a response from the TLS client
748 before assuming the TLS client is no longer alive.";
749 }
750 }
751 }
752 }
753
755 5. The TLS Common Model
757 The TLS common model presented in this section contains identities
758 and groupings common to both TLS clients and TLS servers. The hello-
759 params-grouping can be used to configure the list of TLS algorithms
760 permitted by the TLS client or TLS server. The lists of algorithms
761 are ordered such that, if multiple algorithms are permitted by the
762 client, the algorithm that appears first in its list that is also
763 permitted by the server is used for the TLS transport layer
764 connection. The ability to restrict the algorithms allowed is
765 provided in this grouping for TLS clients and TLS servers that are
766 capable of doing so and may serve to make TLS clients and TLS servers
767 compliant with local security policies. This model supports both
768 TLS1.2 [RFC5246] and TLS 1.3 [RFC8446].
770 TLS 1.2 and TLS 1.3 have different ways defining their own supported
771 cryptographic algorithms, see TLS and DTLS IANA registries page
772 (https://www.iana.org/assignments/tls-parameters/tls-
773 parameters.xhtml):
775 o TLS 1.2 defines four categories of registries for cryptographic
776 algorithms: TLS Cipher Suites, TLS SignatureAlgorithm, TLS
777 HashAlgorithm, TLS Supported Groups. TLS Cipher Suites plays the
778 role of combining all of them into one set, as each value of the
779 set represents a unique and feasible combination of all the
780 cryptographic algorithms, and thus the other three registry
781 categories do not need to be considered here. In this document,
782 the TLS common model only chooses those TLS1.2 algorithms in TLS
783 Cipher Suites which are marked as recommended:
784 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
785 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,
786 TLS_DHE_PSK_WITH_AES_128_GCM_SHA256,
787 TLS_DHE_PSK_WITH_AES_256_GCM_SHA384, and so on. All chosen
788 algorithms are enumerated in Table 1-1 below;
790 o TLS 1.3 defines its supported algorithms differently. Firstly, it
791 defines three categories of registries for cryptographic
792 algorithms: TLS Cipher Suites, TLS SignatureScheme, TLS Supported
793 Groups. Secondly, all three of these categories are useful, since
794 they represent different parts of all the supported algorithms
795 respectively. Thus, all of these registries categories are
796 considered here. In this draft, the TLS common model chooses only
797 those TLS1.3 algorithms specified in B.4, 4.2.3, 4.2.7 of
798 [RFC8446].
800 Thus, in order to support both TLS1.2 and TLS1.3, the cipher-suites
801 part of the hello-params-grouping should include three parameters for
802 configuring its permitted TLS algorithms, which are: TLS Cipher
803 Suites, TLS SignatureScheme, TLS Supported Groups. Note that TLS1.2
804 only uses TLS Cipher Suites.
806 [I-D.ietf-netconf-crypto-types] defines six categories of
807 cryptographic algorithms (hash-algorithm, symmetric-key-encryption-
808 algorithm, mac-algorithm, asymmetric-key-encryption-algorithm,
809 signature-algorithm, key-negotiation-algorithm) and lists several
810 widely accepted algorithms for each of them. The TLS client and
811 server models use one or more of these algorithms. The following
812 tables are provided, in part to define the subset of algorithms
813 defined in the crypto-types model used by TLS, and in part to ensure
814 compatibility of configured TLS cryptographic parameters for
815 configuring its permitted TLS algorithms:
817 +-----------------------------------------------+---------+
818 | ciper-suites in hello-params-grouping | HASH |
819 +-----------------------------------------------+---------+
820 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
821 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
822 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
823 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
824 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | sha-256 |
825 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | sha-384 |
826 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | sha-256 |
827 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | sha-384 |
828 | TLS_DHE_RSA_WITH_AES_128_CCM | sha-256 |
829 | TLS_DHE_RSA_WITH_AES_256_CCM | sha-256 |
830 | TLS_DHE_PSK_WITH_AES_128_CCM | sha-256 |
831 | TLS_DHE_PSK_WITH_AES_256_CCM | sha-256 |
832 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
833 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
834 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
835 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
836 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | sha-256 |
837 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | sha-256 |
838 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | sha-384 |
839 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | sha-256 |
840 +-----------------------------------------------+---------+
842 Table 1-1 TLS 1.2 Compatibility Matrix Part 1: ciper-suites mapping
843 to hash-algorithm
845 +--------------------------------------------- +---------------------+
846 | ciper-suites in hello-params-grouping | symmetric |
847 | | |
848 +--------------------------------------------- +---------------------+
849 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
850 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
851 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
852 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
853 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
854 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
855 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
856 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
857 | TLS_DHE_RSA_WITH_AES_128_CCM | enc-aes-128-ccm |
858 | TLS_DHE_RSA_WITH_AES_256_CCM | enc-aes-256-ccm |
859 | TLS_DHE_PSK_WITH_AES_128_CCM | enc-aes-128-ccm |
860 | TLS_DHE_PSK_WITH_AES_256_CCM | enc-aes-256-ccm |
861 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
862 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|enc-chacha20-poly1305|
863 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
864 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
865 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |enc-chacha20-poly1305|
866 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | enc-aes-128-gcm |
867 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | enc-aes-256-gcm |
868 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | enc-aes-128-ccm |
869 +--------------------------------------------- +---------------------+
871 Table 1-2 TLS 1.2 Compatibility Matrix Part 2: ciper-suites mapping
872 to symmetric-key-encryption-algorithm
874 +--------------------------------------------- +---------------------+
875 | ciper-suites in hello-params-grouping | MAC |
876 | | |
877 +--------------------------------------------- +---------------------+
878 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
879 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
880 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
881 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
882 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
883 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
884 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
885 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
886 | TLS_DHE_RSA_WITH_AES_128_CCM | mac-aes-128-ccm |
887 | TLS_DHE_RSA_WITH_AES_256_CCM | mac-aes-256-ccm |
888 | TLS_DHE_PSK_WITH_AES_128_CCM | mac-aes-128-ccm |
889 | TLS_DHE_PSK_WITH_AES_256_CCM | mac-aes-256-ccm |
890 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
891 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|mac-chacha20-poly1305|
892 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
893 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
894 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |mac-chacha20-poly1305|
895 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | mac-aes-128-gcm |
896 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | mac-aes-256-gcm |
897 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | mac-aes-128-ccm |
898 +--------------------------------------------- +---------------------+
900 Table 1-3 TLS 1.2 Compatibility Matrix Part 3: ciper-suites mapping
901 to MAC-algorithm
903 +----------------------------------------------+----------------------+
904 |ciper-suites in hello-params-grouping | signature |
905 +--------------------------------------------- +----------------------+
906 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
907 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
908 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
909 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
910 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 |ecdsa-secp256r1-sha256|
911 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 |ecdsa-secp384r1-sha384|
912 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | rsa-pkcs1-sha256 |
913 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | rsa-pkcs1-sha384 |
914 | TLS_DHE_RSA_WITH_AES_128_CCM | rsa-pkcs1-sha256 |
915 | TLS_DHE_RSA_WITH_AES_256_CCM | rsa-pkcs1-sha256 |
916 | TLS_DHE_PSK_WITH_AES_128_CCM | N/A |
917 | TLS_DHE_PSK_WITH_AES_256_CCM | N/A |
918 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
919 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256|ecdsa-secp256r1-sha256|
920 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | rsa-pkcs1-sha256 |
921 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
922 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | N/A |
923 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 | N/A |
924 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 | N/A |
925 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 | N/A |
926 +----------------------------------------------+----------------------+
928 Table 1-4 TLS 1.2 Compatibility Matrix Part 4: ciper-suites mapping
929 to signature-algorithm
931 +----------------------------------------------+-----------------------+
932 |ciper-suites in hello-params-grouping | key-negotiation |
933 +----------------------------------------------+-----------------------+
934 | TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | dhe-ffdhe2048, ... |
935 | TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | dhe-ffdhe2048, ... |
936 | TLS_DHE_PSK_WITH_AES_128_GCM_SHA256 | psk-dhe-ffdhe2048, ...|
937 | TLS_DHE_PSK_WITH_AES_256_GCM_SHA384 | psk-dhe-ffdhe2048, ...|
938 | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
939 | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
940 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 | ecdhe-secp256r1, ... |
941 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 | ecdhe-secp256r1, ... |
942 | TLS_DHE_RSA_WITH_AES_128_CCM | dhe-ffdhe2048, ... |
943 | TLS_DHE_RSA_WITH_AES_256_CCM | dhe-ffdhe2048, ... |
944 | TLS_DHE_PSK_WITH_AES_128_CCM | psk-dhe-ffdhe2048, ...|
945 | TLS_DHE_PSK_WITH_AES_256_CCM | psk-dhe-ffdhe2048, ...|
946 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | ecdhe-secp256r1, ... |
947 | TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256| ecdhe-secp256r1, ... |
948 | TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | dhe-ffdhe2048, ... |
949 | TLS_ECDHE_PSK_WITH_CHACHA20_POLY1305_SHA256 |psk-ecdhe-secp256r1,...|
950 | TLS_DHE_PSK_WITH_CHACHA20_POLY1305_SHA256 | psk-dhe-ffdhe2048, ...|
951 | TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 |psk-ecdhe-secp256r1,...|
952 | TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384 |psk-ecdhe-secp256r1,...|
953 | TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256 |psk-ecdhe-secp256r1,...|
954 +----------------------------------------------+-----------------------+
956 Table 1-5 TLS 1.2 Compatibility Matrix Part 5: ciper-suites mapping
957 to key-negotiation-algorithm
959 +------------------------------+---------+
960 | ciper-suites in hello | HASH |
961 | -params-grouping | |
962 +------------------------------+---------+
963 | TLS_AES_128_GCM_SHA256 | sha-256 |
964 | TLS_AES_256_GCM_SHA384 | sha-384 |
965 | TLS_CHACHA20_POLY1305_SHA256 | sha-256 |
966 | TLS_AES_128_CCM_SHA256 | sha-256 |
967 +------------------------------+---------+
969 Table 2-1 TLS 1.3 Compatibility Matrix Part 1: ciper-suites mapping
970 to hash-algorithm
972 +------------------------------+-----------------------+
973 | ciper-suites in hello | symmetric |
974 | -params-grouping | |
975 +------------------------------+-----------------------+
976 | TLS_AES_128_GCM_SHA256 | enc-aes-128-gcm |
977 | TLS_AES_256_GCM_SHA384 | enc-aes-128-gcm |
978 | TLS_CHACHA20_POLY1305_SHA256 | enc-chacha20-poly1305 |
979 | TLS_AES_128_CCM_SHA256 | enc-aes-128-ccm |
980 +------------------------------+-----------------------+
982 Table 2-2 TLS 1.3 Compatibility Matrix Part 2: ciper-suites mapping
983 to symmetric-key--encryption-algorithm
985 +------------------------------+-----------------------+
986 | ciper-suites in hello | symmetric |
987 | -params-grouping | |
988 +------------------------------+-----------------------+
989 | TLS_AES_128_GCM_SHA256 | mac-aes-128-gcm |
990 | TLS_AES_256_GCM_SHA384 | mac-aes-128-gcm |
991 | TLS_CHACHA20_POLY1305_SHA256 | mac-chacha20-poly1305 |
992 | TLS_AES_128_CCM_SHA256 | mac-aes-128-ccm |
993 +------------------------------+-----------------------+
995 Table 2-3 TLS 1.3 Compatibility Matrix Part 3: ciper-suites mapping
996 to MAC-algorithm
998 +----------------------------+-------------------------+
999 |signatureScheme in hello | signature |
1000 | -params-grouping | |
1001 +----------------------------+-------------------------+
1002 | rsa-pkcs1-sha256 | rsa-pkcs1-sha256 |
1003 | rsa-pkcs1-sha384 | rsa-pkcs1-sha384 |
1004 | rsa-pkcs1-sha512 | rsa-pkcs1-sha512 |
1005 | rsa-pss-rsae-sha256 | rsa-pss-rsae-sha256 |
1006 | rsa-pss-rsae-sha384 | rsa-pss-rsae-sha384 |
1007 | rsa-pss-rsae-sha512 | rsa-pss-rsae-sha512 |
1008 | rsa-pss-pss-sha256 | rsa-pss-pss-sha256 |
1009 | rsa-pss-pss-sha384 | rsa-pss-pss-sha384 |
1010 | rsa-pss-pss-sha512 | rsa-pss-pss-sha512 |
1011 | ecdsa-secp256r1-sha256 | ecdsa-secp256r1-sha256 |
1012 | ecdsa-secp384r1-sha384 | ecdsa-secp384r1-sha384 |
1013 | ecdsa-secp521r1-sha512 | ecdsa-secp521r1-sha512 |
1014 | ed25519 | ed25519 |
1015 | ed448 | ed448 |
1016 +----------------------------+-------------------------+
1018 Table 2-4 TLS 1.3 Compatibility Matrix Part 4: SignatureScheme
1019 mapping to signature-algorithm
1021 +----------------------------+-------------------------+
1022 |supported Groups in hello | key-negotiation |
1023 | -params-grouping | |
1024 +----------------------------+-------------------------+
1025 | dhe-ffdhe2048 | dhe-ffdhe2048 |
1026 | dhe-ffdhe3072 | dhe-ffdhe3072 |
1027 | dhe-ffdhe4096 | dhe-ffdhe4096 |
1028 | dhe-ffdhe6144 | dhe-ffdhe6144 |
1029 | dhe-ffdhe8192 | dhe-ffdhe8192 |
1030 | psk-dhe-ffdhe2048 | psk-dhe-ffdhe2048 |
1031 | psk-dhe-ffdhe3072 | psk-dhe-ffdhe3072 |
1032 | psk-dhe-ffdhe4096 | psk-dhe-ffdhe4096 |
1033 | psk-dhe-ffdhe6144 | psk-dhe-ffdhe6144 |
1034 | psk-dhe-ffdhe8192 | psk-dhe-ffdhe8192 |
1035 | ecdhe-secp256r1 | ecdhe-secp256r1 |
1036 | ecdhe-secp384r1 | ecdhe-secp384r1 |
1037 | ecdhe-secp521r1 | ecdhe-secp521r1 |
1038 | ecdhe-x25519 | ecdhe-x25519 |
1039 | ecdhe-x448 | ecdhe-x448 |
1040 | psk-ecdhe-secp256r1 | psk-ecdhe-secp256r1 |
1041 | psk-ecdhe-secp384r1 | psk-ecdhe-secp384r1 |
1042 | psk-ecdhe-secp521r1 | psk-ecdhe-secp521r1 |
1043 | psk-ecdhe-x25519 | psk-ecdhe-x25519 |
1044 | psk-ecdhe-x448 | psk-ecdhe-x448 |
1045 +----------------------------+-------------------------+
1047 Table 2-5 TLS 1.3 Compatibility Matrix Part 5: Supported Groups
1048 mapping to key-negotiation-algorithm
1050 Note that in Table 1-5:
1052 o dhe-ffdhe2048, ... is the abbreviation of dhe-ffdhe2048, dhe-
1053 ffdhe3072, dhe-ffdhe4096, dhe-ffdhe6144, dhe-ffdhe8192;
1055 o psk-dhe-ffdhe2048, ... is the abbreviation of psk-dhe-ffdhe2048,
1056 psk-dhe-ffdhe3072, psk-dhe-ffdhe4096, psk-dhe-ffdhe6144, psk-dhe-
1057 ffdhe8192;
1059 o ecdhe-secp256r1, ... is the abbreviation of ecdhe-secp256r1,
1060 ecdhe-secp384r1, ecdhe-secp521r1, ecdhe-x25519, ecdhe-x448;
1062 o psk-ecdhe-secp256r1, ... is the abbreviation of psk-ecdhe-
1063 secp256r1, psk-ecdhe-secp384r1, psk-ecdhe-secp521r1, psk-ecdhe-
1064 x25519, psk-ecdhe-x448.
1066 Features are defined for algorithms that are OPTIONAL or are not
1067 widely supported by popular implementations. Note that the list of
1068 algorithms is not exhaustive.
1070 5.1. Tree Diagram
1072 The following tree diagram [RFC8340] provides an overview of the data
1073 model for the "ietf-tls-common" module.
1075 module: ietf-tls-common
1077 grouping hello-params-grouping
1078 +-- tls-versions
1079 | +-- tls-version* identityref
1080 +-- cipher-suites
1081 +-- cipher-suite* identityref
1083 5.2. Example Usage
1085 This section shows how it would appear if the transport-params-
1086 grouping were populated with some data.
1088
1091
1092 tlscmn:tls-1.1
1093 tlscmn:tls-1.2
1094
1095
1096 tlscmn:dhe-rsa-with-aes-128-cbc-sha
1097 tlscmn:rsa-with-aes-128-cbc-sha
1098 tlscmn:rsa-with-3des-ede-cbc-sha
1099
1100
1102 5.3. YANG Module
1104 This YANG module has a normative references to [RFC4346], [RFC5246],
1105 [RFC5288], [RFC5289], and [RFC8422].
1107 This YANG module has a informative references to [RFC2246],
1108 [RFC4346], [RFC5246], and [RFC8446].
1110 file "ietf-tls-common@2019-03-09.yang"
1111 module ietf-tls-common {
1112 yang-version 1.1;
1113 namespace "urn:ietf:params:xml:ns:yang:ietf-tls-common";
1114 prefix "tlscmn";
1116 organization
1117 "IETF NETCONF (Network Configuration) Working Group";
1119 contact
1120 "WG Web:
1121 WG List:
1122 Author: Kent Watsen
1123 Author: Gary Wu ";
1125 description
1126 "This module defines a common features, identities, and
1127 groupings for Transport Layer Security (TLS).
1129 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
1130 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
1131 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document
1132 are to be interpreted as described in BCP 14 [RFC2119]
1133 [RFC8174] when, and only when, they appear in all
1134 capitals, as shown here.
1136 Copyright (c) 2019 IETF Trust and the persons identified as
1137 authors of the code. All rights reserved.
1139 Redistribution and use in source and binary forms, with or
1140 without modification, is permitted pursuant to, and subject
1141 to the license terms contained in, the Simplified BSD
1142 License set forth in Section 4.c of the IETF Trust's
1143 Legal Provisions Relating to IETF Documents
1144 (http://trustee.ietf.org/license-info).
1146 This version of this YANG module is part of RFC XXXX; see
1147 the RFC itself for full legal notices.";
1149 revision "2019-03-09" {
1150 description
1151 "Initial version";
1152 reference
1153 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1154 }
1156 // Features
1158 feature tls-1_0 {
1159 description
1160 "TLS Protocol Version 1.0 is supported.";
1161 reference
1162 "RFC 2246: The TLS Protocol Version 1.0";
1163 }
1165 feature tls-1_1 {
1166 description
1167 "TLS Protocol Version 1.1 is supported.";
1168 reference
1169 "RFC 4346: The Transport Layer Security (TLS) Protocol
1170 Version 1.1";
1171 }
1173 feature tls-1_2 {
1174 description
1175 "TLS Protocol Version 1.2 is supported.";
1176 reference
1177 "RFC 5246: The Transport Layer Security (TLS) Protocol
1178 Version 1.2";
1179 }
1181 feature tls-1_3 {
1182 description
1183 "TLS Protocol Version 1.2 is supported.";
1184 reference
1185 "RFC 8446: The Transport Layer Security (TLS) Protocol
1186 Version 1.3";
1187 }
1189 feature tls-ecc {
1190 description
1191 "Elliptic Curve Cryptography (ECC) is supported for TLS.";
1192 reference
1193 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1194 for Transport Layer Security (TLS)";
1195 }
1197 feature tls-dhe {
1198 description
1199 "Ephemeral Diffie-Hellman key exchange is supported for TLS.";
1200 reference
1201 "RFC 5246: The Transport Layer Security (TLS) Protocol
1202 Version 1.2";
1203 }
1205 feature tls-3des {
1206 description
1207 "The Triple-DES block cipher is supported for TLS.";
1208 reference
1209 "RFC 5246: The Transport Layer Security (TLS) Protocol
1210 Version 1.2";
1211 }
1213 feature tls-gcm {
1214 description
1215 "The Galois/Counter Mode authenticated encryption mode is
1216 supported for TLS.";
1217 reference
1218 "RFC 5288: AES Galois Counter Mode (GCM) Cipher Suites for
1219 TLS";
1220 }
1222 feature tls-sha2 {
1223 description
1224 "The SHA2 family of cryptographic hash functions is supported
1225 for TLS.";
1226 reference
1227 "FIPS PUB 180-4: Secure Hash Standard (SHS)";
1228 }
1230 // Identities
1232 identity tls-version-base {
1233 description
1234 "Base identity used to identify TLS protocol versions.";
1235 }
1237 identity tls-1.0 {
1238 base tls-version-base;
1239 if-feature tls-1_0;
1240 description
1241 "TLS Protocol Version 1.0.";
1242 reference
1243 "RFC 2246: The TLS Protocol Version 1.0";
1244 }
1246 identity tls-1.1 {
1247 base tls-version-base;
1248 if-feature tls-1_1;
1249 description
1250 "TLS Protocol Version 1.1.";
1251 reference
1252 "RFC 4346: The Transport Layer Security (TLS) Protocol
1253 Version 1.1";
1254 }
1256 identity tls-1.2 {
1257 base tls-version-base;
1258 if-feature tls-1_2;
1259 description
1260 "TLS Protocol Version 1.2.";
1261 reference
1262 "RFC 5246: The Transport Layer Security (TLS) Protocol
1263 Version 1.2";
1264 }
1266 identity cipher-suite-base {
1267 description
1268 "Base identity used to identify TLS cipher suites.";
1269 }
1271 identity rsa-with-aes-128-cbc-sha {
1272 base cipher-suite-base;
1273 description
1274 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.";
1275 reference
1276 "RFC 5246: The Transport Layer Security (TLS) Protocol
1277 Version 1.2";
1278 }
1280 identity rsa-with-aes-256-cbc-sha {
1281 base cipher-suite-base;
1282 description
1283 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA.";
1284 reference
1285 "RFC 5246: The Transport Layer Security (TLS) Protocol
1286 Version 1.2";
1287 }
1289 identity rsa-with-aes-128-cbc-sha256 {
1290 base cipher-suite-base;
1291 if-feature tls-sha2;
1292 description
1293 "Cipher suite TLS_RSA_WITH_AES_128_CBC_SHA256.";
1294 reference
1295 "RFC 5246: The Transport Layer Security (TLS) Protocol
1296 Version 1.2";
1297 }
1299 identity rsa-with-aes-256-cbc-sha256 {
1300 base cipher-suite-base;
1301 if-feature tls-sha2;
1302 description
1303 "Cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.";
1304 reference
1305 "RFC 5246: The Transport Layer Security (TLS) Protocol
1306 Version 1.2";
1307 }
1309 identity dhe-rsa-with-aes-128-cbc-sha {
1310 base cipher-suite-base;
1311 if-feature tls-dhe;
1312 description
1313 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.";
1314 reference
1315 "RFC 5246: The Transport Layer Security (TLS) Protocol
1316 Version 1.2";
1317 }
1319 identity dhe-rsa-with-aes-256-cbc-sha {
1320 base cipher-suite-base;
1321 if-feature tls-dhe;
1322 description
1323 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA.";
1324 reference
1325 "RFC 5246: The Transport Layer Security (TLS) Protocol
1326 Version 1.2";
1327 }
1329 identity dhe-rsa-with-aes-128-cbc-sha256 {
1330 base cipher-suite-base;
1331 if-feature "tls-dhe and tls-sha2";
1332 description
1333 "Cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA256.";
1334 reference
1335 "RFC 5246: The Transport Layer Security (TLS) Protocol
1336 Version 1.2";
1337 }
1339 identity dhe-rsa-with-aes-256-cbc-sha256 {
1340 base cipher-suite-base;
1341 if-feature "tls-dhe and tls-sha2";
1342 description
1343 "Cipher suite TLS_DHE_RSA_WITH_AES_256_CBC_SHA256.";
1344 reference
1345 "RFC 5246: The Transport Layer Security (TLS) Protocol
1346 Version 1.2";
1347 }
1349 identity ecdhe-ecdsa-with-aes-128-cbc-sha256 {
1350 base cipher-suite-base;
1351 if-feature "tls-ecc and tls-sha2";
1352 description
1353 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256.";
1354 reference
1355 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1356 SHA-256/384 and AES Galois Counter Mode (GCM)";
1357 }
1358 identity ecdhe-ecdsa-with-aes-256-cbc-sha384 {
1359 base cipher-suite-base;
1360 if-feature "tls-ecc and tls-sha2";
1361 description
1362 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384.";
1363 reference
1364 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1365 SHA-256/384 and AES Galois Counter Mode (GCM)";
1366 }
1368 identity ecdhe-rsa-with-aes-128-cbc-sha256 {
1369 base cipher-suite-base;
1370 if-feature "tls-ecc and tls-sha2";
1371 description
1372 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256.";
1373 reference
1374 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1375 SHA-256/384 and AES Galois Counter Mode (GCM)";
1376 }
1378 identity ecdhe-rsa-with-aes-256-cbc-sha384 {
1379 base cipher-suite-base;
1380 if-feature "tls-ecc and tls-sha2";
1381 description
1382 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384.";
1383 reference
1384 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1385 SHA-256/384 and AES Galois Counter Mode (GCM)";
1386 }
1388 identity ecdhe-ecdsa-with-aes-128-gcm-sha256 {
1389 base cipher-suite-base;
1390 if-feature "tls-ecc and tls-gcm and tls-sha2";
1391 description
1392 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.";
1393 reference
1394 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1395 SHA-256/384 and AES Galois Counter Mode (GCM)";
1396 }
1398 identity ecdhe-ecdsa-with-aes-256-gcm-sha384 {
1399 base cipher-suite-base;
1400 if-feature "tls-ecc and tls-gcm and tls-sha2";
1401 description
1402 "Cipher suite TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384.";
1403 reference
1404 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1405 SHA-256/384 and AES Galois Counter Mode (GCM)";
1407 }
1409 identity ecdhe-rsa-with-aes-128-gcm-sha256 {
1410 base cipher-suite-base;
1411 if-feature "tls-ecc and tls-gcm and tls-sha2";
1412 description
1413 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.";
1414 reference
1415 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1416 SHA-256/384 and AES Galois Counter Mode (GCM)";
1417 }
1419 identity ecdhe-rsa-with-aes-256-gcm-sha384 {
1420 base cipher-suite-base;
1421 if-feature "tls-ecc and tls-gcm and tls-sha2";
1422 description
1423 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.";
1424 reference
1425 "RFC 5289: TLS Elliptic Curve Cipher Suites with
1426 SHA-256/384 and AES Galois Counter Mode (GCM)";
1427 }
1429 identity rsa-with-3des-ede-cbc-sha {
1430 base cipher-suite-base;
1431 if-feature tls-3des;
1432 description
1433 "Cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.";
1434 reference
1435 "RFC 5246: The Transport Layer Security (TLS) Protocol
1436 Version 1.2";
1437 }
1439 identity ecdhe-rsa-with-3des-ede-cbc-sha {
1440 base cipher-suite-base;
1441 if-feature "tls-ecc and tls-3des";
1442 description
1443 "Cipher suite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA.";
1444 reference
1445 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1446 for Transport Layer Security (TLS)";
1447 }
1449 identity ecdhe-rsa-with-aes-128-cbc-sha {
1450 base cipher-suite-base;
1451 if-feature "tls-ecc";
1452 description
1453 "Cipher suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.";
1454 reference
1455 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1456 for Transport Layer Security (TLS)";
1457 }
1459 identity ecdhe-rsa-with-aes-256-cbc-sha {
1460 base cipher-suite-base;
1461 if-feature "tls-ecc";
1462 description
1463 "Cipher suite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA.";
1464 reference
1465 "RFC 8422: Elliptic Curve Cryptography (ECC) Cipher Suites
1466 for Transport Layer Security (TLS)";
1467 }
1469 // Groupings
1471 grouping hello-params-grouping {
1472 description
1473 "A reusable grouping for TLS hello message parameters.";
1474 reference
1475 "RFC 5246: The Transport Layer Security (TLS) Protocol
1476 Version 1.2";
1478 container tls-versions {
1479 description
1480 "Parameters regarding TLS versions.";
1481 leaf-list tls-version {
1482 type identityref {
1483 base tls-version-base;
1484 }
1485 description
1486 "Acceptable TLS protocol versions.
1488 If this leaf-list is not configured (has zero elements)
1489 the acceptable TLS protocol versions are implementation-
1490 defined.";
1491 }
1492 }
1493 container cipher-suites {
1494 description
1495 "Parameters regarding cipher suites.";
1496 leaf-list cipher-suite {
1497 type identityref {
1498 base cipher-suite-base;
1499 }
1500 ordered-by user;
1501 description
1502 "Acceptable cipher suites in order of descending
1503 preference. The configured host key algorithms should
1504 be compatible with the algorithm used by the configured
1505 private key. Please see Section 5 of RFC XXXX for
1506 valid combinations.
1508 If this leaf-list is not configured (has zero elements)
1509 the acceptable cipher suites are implementation-
1510 defined.";
1511 reference
1512 "RFC XXXX: YANG Groupings for TLS Clients and TLS Servers";
1513 }
1514 }
1516 }
1517 }
1518
1520 6. Security Considerations
1522 The YANG modules defined in this document are designed to be accessed
1523 via YANG based management protocols, such as NETCONF [RFC6241] and
1524 RESTCONF [RFC8040]. Both of these protocols have mandatory-to-
1525 implement secure transport layers (e.g., SSH, TLS) with mutual
1526 authentication.
1528 The NETCONF access control model (NACM) [RFC8341] provides the means
1529 to restrict access for particular users to a pre-configured subset of
1530 all available protocol operations and content.
1532 Since the modules defined in this document only define groupings,
1533 these considerations are primarily for the designers of other modules
1534 that use these groupings.
1536 There are a number of data nodes defined in the YANG modules that are
1537 writable/creatable/deletable (i.e., config true, which is the
1538 default). These data nodes may be considered sensitive or vulnerable
1539 in some network environments. Write operations (e.g., edit-config)
1540 to these data nodes without proper protection can have a negative
1541 effect on network operations. These are the subtrees and data nodes
1542 and their sensitivity/vulnerability:
1544 /: The entire data tree of all the groupings defined in this draft
1545 is sensitive to write operations. For instance, the addition
1546 or removal of references to keys, certificates, trusted
1547 anchors, etc., can dramatically alter the implemented security
1548 policy. However, no NACM annotations are applied as the data
1549 SHOULD be editable by users other than a designated 'recovery
1550 session'.
1552 Some of the readable data nodes in the YANG modules may be considered
1553 sensitive or vulnerable in some network environments. It is thus
1554 important to control read access (e.g., via get, get-config, or
1555 notification) to these data nodes. These are the subtrees and data
1556 nodes and their sensitivity/vulnerability:
1558 NONE
1560 Some of the RPC operations in this YANG module may be considered
1561 sensitive or vulnerable in some network environments. It is thus
1562 important to control access to these operations. These are the
1563 operations and their sensitivity/vulnerability:
1565 NONE
1567 7. IANA Considerations
1569 7.1. The IETF XML Registry
1571 This document registers three URIs in the "ns" subregistry of the
1572 IETF XML Registry [RFC3688]. Following the format in [RFC3688], the
1573 following registrations are requested:
1575 URI: urn:ietf:params:xml:ns:yang:ietf-tls-client
1576 Registrant Contact: The NETCONF WG of the IETF.
1577 XML: N/A, the requested URI is an XML namespace.
1579 URI: urn:ietf:params:xml:ns:yang:ietf-tls-server
1580 Registrant Contact: The NETCONF WG of the IETF.
1581 XML: N/A, the requested URI is an XML namespace.
1583 URI: urn:ietf:params:xml:ns:yang:ietf-tls-common
1584 Registrant Contact: The NETCONF WG of the IETF.
1585 XML: N/A, the requested URI is an XML namespace.
1587 7.2. The YANG Module Names Registry
1589 This document registers three YANG modules in the YANG Module Names
1590 registry [RFC6020]. Following the format in [RFC6020], the following
1591 registrations are requested:
1593 name: ietf-tls-client
1594 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-client
1595 prefix: tlsc
1596 reference: RFC XXXX
1598 name: ietf-tls-server
1599 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-server
1600 prefix: tlss
1601 reference: RFC XXXX
1603 name: ietf-tls-common
1604 namespace: urn:ietf:params:xml:ns:yang:ietf-tls-common
1605 prefix: tlscmn
1606 reference: RFC XXXX
1608 8. References
1610 8.1. Normative References
1612 [I-D.ietf-netconf-crypto-types]
1613 Watsen, K. and H. Wang, "Common YANG Data Types for
1614 Cryptography", draft-ietf-netconf-crypto-types-02 (work in
1615 progress), October 2018.
1617 [I-D.ietf-netconf-keystore]
1618 Watsen, K., "YANG Data Model for a Centralized Keystore
1619 Mechanism", draft-ietf-netconf-keystore-08 (work in
1620 progress), March 2019.
1622 [I-D.ietf-netconf-trust-anchors]
1623 Watsen, K., "YANG Data Model for Global Trust Anchors",
1624 draft-ietf-netconf-trust-anchors-03 (work in progress),
1625 March 2019.
1627 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1628 Requirement Levels", BCP 14, RFC 2119,
1629 DOI 10.17487/RFC2119, March 1997,
1630 .
1632 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
1633 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
1634 DOI 10.17487/RFC5288, August 2008,
1635 .
1637 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
1638 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
1639 DOI 10.17487/RFC5289, August 2008,
1640 .
1642 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
1643 the Network Configuration Protocol (NETCONF)", RFC 6020,
1644 DOI 10.17487/RFC6020, October 2010,
1645 .
1647 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
1648 NETCONF Protocol over Transport Layer Security (TLS) with
1649 Mutual X.509 Authentication", RFC 7589,
1650 DOI 10.17487/RFC7589, June 2015,
1651 .
1653 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
1654 RFC 7950, DOI 10.17487/RFC7950, August 2016,
1655 .
1657 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1658 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1659 May 2017, .
1661 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
1662 Access Control Model", STD 91, RFC 8341,
1663 DOI 10.17487/RFC8341, March 2018,
1664 .
1666 [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
1667 Curve Cryptography (ECC) Cipher Suites for Transport Layer
1668 Security (TLS) Versions 1.2 and Earlier", RFC 8422,
1669 DOI 10.17487/RFC8422, August 2018,
1670 .
1672 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
1673 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
1674 .
1676 8.2. Informative References
1678 [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
1679 RFC 2246, DOI 10.17487/RFC2246, January 1999,
1680 .
1682 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
1683 DOI 10.17487/RFC2818, May 2000,
1684 .
1686 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1687 DOI 10.17487/RFC3688, January 2004,
1688 .
1690 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
1691 (TLS) Protocol Version 1.1", RFC 4346,
1692 DOI 10.17487/RFC4346, April 2006,
1693 .
1695 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
1696 (TLS) Protocol Version 1.2", RFC 5246,
1697 DOI 10.17487/RFC5246, August 2008,
1698 .
1700 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
1701 and A. Bierman, Ed., "Network Configuration Protocol
1702 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
1703 .
1705 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
1706 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
1707 .
1709 [RFC8071] Watsen, K., "NETCONF Call Home and RESTCONF Call Home",
1710 RFC 8071, DOI 10.17487/RFC8071, February 2017,
1711 .
1713 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
1714 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
1715 .
1717 Appendix A. Change Log
1719 A.1. 00 to 01
1721 o Noted that '0.0.0.0' and '::' might have special meanings.
1723 o Renamed "keychain" to "keystore".
1725 A.2. 01 to 02
1727 o Removed the groupings containing transport-level configuration.
1728 Now modules contain only the transport-independent groupings.
1730 o Filled in previously incomplete 'ietf-tls-client' module.
1732 o Added cipher suites for various algorithms into new 'ietf-tls-
1733 common' module.
1735 A.3. 02 to 03
1737 o Added a 'must' statement to container 'server-auth' asserting that
1738 at least one of the various auth mechanisms must be specified.
1740 o Fixed description statement for leaf 'trusted-ca-certs'.
1742 A.4. 03 to 04
1744 o Updated title to "YANG Groupings for TLS Clients and TLS Servers"
1746 o Updated leafref paths to point to new keystore path
1748 o Changed the YANG prefix for ietf-tls-common from 'tlscom' to
1749 'tlscmn'.
1751 o Added TLS protocol verions 1.0 and 1.1.
1753 o Made author lists consistent
1755 o Now tree diagrams reference ietf-netmod-yang-tree-diagrams
1757 o Updated YANG to use typedefs around leafrefs to common keystore
1758 paths
1760 o Now inlines key and certificates (no longer a leafref to keystore)
1762 A.5. 04 to 05
1764 o Merged changes from co-author.
1766 A.6. 05 to 06
1768 o Updated to use trust anchors from trust-anchors draft (was
1769 keystore draft)
1771 o Now Uses new keystore grouping enabling asymmetric key to be
1772 either locally defined or a reference to the keystore.
1774 A.7. 06 to 07
1776 o factored the tls-[client|server]-groupings into more reusable
1777 groupings.
1779 o added if-feature statements for the new "x509-certificates"
1780 feature defined in draft-ietf-netconf-trust-anchors.
1782 A.8. 07 to 08
1784 o Added a number of compatibility matrices to Section 5 (thanks
1785 Frank!)
1787 o Clarified that any configured "cipher-suite" values need to be
1788 compatible with the configured private key.
1790 A.9. 08 to 09
1792 o Updated examples to reflect update to groupings defined in the
1793 keystore draft.
1795 o Add TLS keepalives features and groupings.
1797 o Prefixed top-level TLS grouping nodes with 'tls-' and support
1798 mashups.
1800 o Updated copyright date, boilerplate template, affiliation, and
1801 folding algorithm.
1803 Acknowledgements
1805 The authors would like to thank for following for lively discussions
1806 on list and in the halls (ordered by last name): Andy Bierman, Martin
1807 Bjorklund, Benoit Claise, Mehmet Ersue, Balazs Kovacs, David
1808 Lamparter, Alan Luchuk, Ladislav Lhotka, Radek Krejci, Tom Petch,
1809 Juergen Schoenwaelder, Phil Shafer, Sean Turner, and Bert Wijnen.
1811 Authors' Addresses
1813 Kent Watsen
1814 Watsen Networks
1816 EMail: kent+ietf@watsen.net
1818 Gary Wu
1819 Cisco Systems
1821 EMail: garywu@cisco.com
1823 Liang Xia
1824 Huawei
1826 EMail: frank.xialiang@huawei.com