draft-ietf-anima-constrained-voucher-01.txt   draft-ietf-anima-constrained-voucher-02.txt 
anima Working Group M. Richardson anima Working Group M. Richardson
Internet-Draft Sandelman Software Works Internet-Draft Sandelman Software Works
Intended status: Standards Track P. van der Stok Intended status: Standards Track P. van der Stok
Expires: March 1, 2019 vanderstok consultancy Expires: March 15, 2019 vanderstok consultancy
P. Kampanakis P. Kampanakis
Cisco Systems Cisco Systems
August 28, 2018 September 11, 2018
Constrained Voucher Artifacts for Bootstrapping Protocols Constrained Voucher Artifacts for Bootstrapping Protocols
draft-ietf-anima-constrained-voucher-01 draft-ietf-anima-constrained-voucher-02
Abstract Abstract
This document defines a strategy to securely assign a pledge to an This document defines a strategy to securely assign a pledge to an
owner, using an artifact signed, directly or indirectly, by the owner, using an artifact signed, directly or indirectly, by the
pledge's manufacturer. This artifact is known as a "voucher". pledge's manufacturer. This artifact is known as a "voucher".
This document builds upon the work in [RFC8366], encoding the This document builds upon the work in [RFC8366], encoding the
resulting artifact in CBOR. Use with two signature technologies are resulting artifact in CBOR. Use with two signature technologies are
described. described.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 1, 2019. This Internet-Draft will expire on March 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4 4. Survey of Voucher Types . . . . . . . . . . . . . . . . . . . 4
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 4 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 5
6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 6 6.1. Voucher Request artifact . . . . . . . . . . . . . . . . 7
6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 6 6.1.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 7
6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 7 6.1.2. SID values . . . . . . . . . . . . . . . . . . . . . 7
6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 7 6.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 8
6.1.4. Example voucher request artifacts . . . . . . . . . . 10 6.1.4. Example voucher request artifact . . . . . . . . . . 11
6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 10 6.2. Voucher artifact . . . . . . . . . . . . . . . . . . . . 12
6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 11 6.2.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . 12
6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 11 6.2.2. SID values . . . . . . . . . . . . . . . . . . . . . 13
6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 11 6.2.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 13
6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 13 6.2.4. Example voucher artifacts . . . . . . . . . . . . . . 15
6.3. CMS format voucher and voucher-request artifacts . . . . 14 6.3. CMS format voucher and voucher-request artifacts . . . . 16
6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 15 6.3.1. COSE signing . . . . . . . . . . . . . . . . . . . . 17
7. Design Considerations . . . . . . . . . . . . . . . . . . . . 16 7. Design Considerations . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 16 8.1. Clock Sensitivity . . . . . . . . . . . . . . . . . . . . 17
8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 16 8.2. Protect Voucher PKI in HSM . . . . . . . . . . . . . . . 17
8.3. Test Domain Certificate Validity when Signing . . . . . . 16 8.3. Test Domain Certificate Validity when Signing . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 16 9.1. Resource Type Registry . . . . . . . . . . . . . . . . . 18
9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 16 9.2. The IETF XML Registry . . . . . . . . . . . . . . . . . . 18
9.3. The YANG Module Names Registry . . . . . . . . . . . . . 17 9.3. The YANG Module Names Registry . . . . . . . . . . . . . 18
9.4. The SMI Security for S/MIME CMS Content Type Registry . . 17 9.4. The SMI Security for S/MIME CMS Content Type Registry . . 19
9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 17 9.5. The SID registry . . . . . . . . . . . . . . . . . . . . 19
9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 18 9.6. Media-Type Registry . . . . . . . . . . . . . . . . . . . 19
9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 18 9.6.1. application/voucher-cms+cbor . . . . . . . . . . . . 19
9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 18 9.6.2. application/voucher-cose+cbor . . . . . . . . . . . . 20
9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 19 9.7. CoAP Content-Format Registry . . . . . . . . . . . . . . 21
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 22 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 24
A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 22 A.1. enrollstatus . . . . . . . . . . . . . . . . . . . . . . 24
A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 23 A.2. voucher_status . . . . . . . . . . . . . . . . . . . . . 25
A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 23 A.3. requestvoucher . . . . . . . . . . . . . . . . . . . . . 26
A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 23 A.3.1. signed requestvoucher . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 A.3.2. unsigned requestvoucher . . . . . . . . . . . . . . . 26
A.4. requestauditing . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
Enrollment of new nodes into constrained networks with constrained Enrollment of new nodes into constrained networks with constrained
nodes present unique challenges. nodes present unique challenges.
There are bandwidth and code space issues to contend. A solution There are bandwidth and code space issues to contend. A solution
such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in such as [I-D.ietf-anima-bootstrapping-keyinfra] may be too large in
terms of code space or bandwidth required. terms of code space or bandwidth required.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
[RFC8366] defined only the voucher artifact, and not the Voucher [RFC8366] defined only the voucher artifact, and not the Voucher
Request artifact, which was defined in Request artifact, which was defined in
[I-D.ietf-anima-bootstrapping-keyinfra]. [I-D.ietf-anima-bootstrapping-keyinfra].
This document defines both a constrained voucher and a constrained This document defines both a constrained voucher and a constrained
voucher-request. They are presented in the order voucher-request, voucher-request. They are presented in the order voucher-request,
followed by voucher response as this is the time order that they followed by voucher response as this is the time order that they
occur. occur.
This document defines both CMS-signed voucher requests and responses,
and COSE signed voucher requests and responses. The use of CMS
signatures implies the use of PKIX format certificates. The pinned-
domain-cert present in such a voucher, is the certificate of the
Registrar.
The use of COSE signatures permits the use of both PKIX format
certificates, and also raw public keys (RPK). When RPKs are used,
the voucher produced by the MASA pins the raw public key of the
Registrar: the pinned-domain-subject-public-key-info in such a
voucher, is the raw public key of the Registrar. This is described
in the YANG definition for the constrained voucher.
5. Discovery and URI 5. Discovery and URI
This section describes the BRSKI extensions to EST-coaps This section describes the BRSKI extensions to EST-coaps
[I-D.ietf-ace-coap-est] to transport the voucher between registrar, [I-D.ietf-ace-coap-est] to transport the voucher between registrar,
proxy and pledge over CoAP. The extensions are targeted to low- proxy and pledge over CoAP. The extensions are targeted to low-
resource networks with small packets. Saving header space is resource networks with small packets. Saving header space is
important and the EST-coaps URI is shorter than the EST URI. important and the EST-coaps URI is shorter than the EST URI.
The presence and location of (path to) the management data are The presence and location of (path to) the management data are
discovered by sending a GET request to "/.well-known/core" including discovered by sending a GET request to "/.well-known/core" including
skipping to change at page 6, line 24 skipping to change at page 6, line 33
The first line MUST be returned in response to the GET, The following The first line MUST be returned in response to the GET, The following
four lines MAY be returned to show the supported Content-Formats. four lines MAY be returned to show the supported Content-Formats.
The return of the content-types allows the client to choose the most The return of the content-types allows the client to choose the most
appropriate one from multiple content types. appropriate one from multiple content types.
ct=16 stands for the Content-Format "application/cose", and ct=TBD2 ct=16 stands for the Content-Format "application/cose", and ct=TBD2
stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3 stands for Content-Format "application/voucher-cms+cbor, and ct=TBD3
stands for Content-Format "application/voucher-cose+cbor". stands for Content-Format "application/voucher-cose+cbor".
Content-Formats TBD2 and TBD3 are defined in this document. The Content-Formats TBD2 and TBD3 are defined in this document. The
return of the content-formts allows the client to choose the most return of the content-formats allows the client to choose the most
appropriate one from multiple content formats. appropriate one from multiple content formats.
The Content-Format ("application/json") 50 MAY be supported. The Content-Format ("application/json") 50 MAY be supported.
Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be Content-Formats ("application/cbor") 60, TBD2, TBD3, and 16 MUST be
supported. supported.
6. Artifacts 6. Artifacts
This section describes the abstract (tree) definition as explained in This section describes the abstract (tree) definition as explained in
[I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high- [I-D.ietf-netmod-yang-tree-diagrams] first. This provides a high-
level view of the contents of each artifact. level view of the contents of each artifact.
Then the assigned SID values are presented. These have been assigned Then the assigned SID values are presented. These have been assigned
using the rules in [I-D.ietf-core-yang-cbor], with an allocation that using the rules in [I-D.ietf-core-yang-cbor], with an allocation that
was made via the http://comi.space service. was made via the http://comi.space service.
((EDNOTE: it is unclear if there is further IANA work))
6.1. Voucher Request artifact 6.1. Voucher Request artifact
6.1.1. Tree Diagram 6.1.1. Tree Diagram
The following diagram is largely a duplicate of the contents of The following diagram is largely a duplicate of the contents of
[RFC8366], with the addition of proximity-registrar-subject-public- [RFC8366], with the addition of proximity-registrar-subject-public-
key-info, proximity-registrar-cert, and prior-signed-voucher-request. key-info, proximity-registrar-cert, and prior-signed-voucher-request.
prior-signed-voucher-request is only used between the Registrar and prior-signed-voucher-request is only used between the Registrar and
the MASA. proximity-registrar-subject-public-key-info replaces the MASA. proximity-registrar-subject-public-key-info replaces
proximity-registrar-cert for the extremely constrained cases. proximity-registrar-cert for the extremely constrained cases.
module: ietf-constrained-voucher-request module: ietf-constrained-voucher-request
grouping voucher-request-constrained-grouping grouping voucher-request-constrained-grouping
+---- voucher +-- voucher
+---- created-on +-- created-on?
| yang:date-and-time | yang:date-and-time
+---- expires-on? +-- expires-on?
| yang:date-and-time | yang:date-and-time
+---- assertion +-- assertion enumeration
| enumeration +-- serial-number string
+---- serial-number string +-- idevid-issuer? binary
+---- idevid-issuer? binary +-- pinned-domain-cert? binary
+---- pinned-domain-cert binary +-- domain-cert-revocation-checks? boolean
+---- domain-cert-revocation-checks? boolean +-- nonce? binary
+---- nonce? binary +-- last-renewal-date?
+---- last-renewal-date?
| yang:date-and-time | yang:date-and-time
+---- proximity-registrar-subject-public-key-info? binary +-- proximity-registrar-subject-public-key-info? binary
+---- proximity-registrar-cert? binary +-- proximity-registrar-cert? binary
+---- prior-signed-voucher-request? binary +-- prior-signed-voucher-request? binary
6.1.2. SID values 6.1.2. SID values
SID Assigned to
[[EDNOTE - to be fixed ]] --------- --------------------------------------------------
1001154 data /ietf-constrained-voucher-request:voucher
1001155 data .../assertion
1001156 data .../created-on
1001157 data .../domain-cert-revocation-checks
1001158 data .../expires-on
1001159 data .../idevid-issuer
1001160 data .../last-renewal-date
1001161 data /ietf-constrained-voucher-request:voucher/nonce
1001162 data .../pinned-domain-cert
1001163 data .../prior-signed-voucher-request
1001164 data .../proximity-registrar-cert
1001165 data .../proximity-registrar-subject-public-key-info
1001166 data .../serial-number
6.1.3. YANG Module 6.1.3. YANG Module
In the constrained-voucher-request YANG module, the voucher is "used" In the constrained-voucher-request YANG module, the voucher is
and not "augmented" such that one continuous set of SID values is "augmented" within the "used" grouping statement such that one
generated for the constrained-voucher-request module name, all continuous set of SID values is generated for the constrained-
voucher attributes, and the constrained-voucher-request attribute. voucher-request module name, all voucher attributes, and the
constrained-voucher-request attribute. Two attributes of the voucher
are "refined" to be optional.
<CODE BEGINS> file "ietf-constrained-voucher-request@2018-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher-request@2018-09-01.yang"
module ietf-constrained-voucher-request { module ietf-constrained-voucher-request {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher-request";
prefix "constrained"; prefix "constrained";
import ietf-restconf { import ietf-restconf {
skipping to change at page 9, line 20 skipping to change at page 10, line 7
// YANG data template for a voucher. // YANG data template for a voucher.
uses voucher-request-constrained-grouping; uses voucher-request-constrained-grouping;
} }
// Grouping defined for future usage // Grouping defined for future usage
grouping voucher-request-constrained-grouping { grouping voucher-request-constrained-grouping {
description description
"Grouping to allow reuse/extensions in future work."; "Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { uses v:voucher-artifact-grouping {
refine voucher/created-on {
mandatory false;
}
refine voucher/pinned-domain-cert {
mandatory false;
}
augment "voucher" { augment "voucher" {
description "Base the constrained voucher-request upon the description "Base the constrained voucher-request upon the
regular one"; regular one";
leaf proximity-registrar-subject-public-key-info { leaf proximity-registrar-subject-public-key-info {
type binary; type binary;
description description
"The proximity-registrar-subject-public-key-info replaces "The proximity-registrar-subject-public-key-info replaces
the proximit-registrar-cert in constrained uses of the proximit-registrar-cert in constrained uses of
the voucher-request. the voucher-request.
skipping to change at page 10, line 33 skipping to change at page 11, line 30
when accepting a voucher for imprinting. Other when accepting a voucher for imprinting. Other
parties MAY examine the prior signed voucher parties MAY examine the prior signed voucher
information for the purposes of policy decisions. information for the purposes of policy decisions.
For example this information could be useful to a For example this information could be useful to a
MASA to determine that both pledge and registrar MASA to determine that both pledge and registrar
agree on proximity assertions. The MASA SHOULD agree on proximity assertions. The MASA SHOULD
remove all prior-signed-voucher-request information when remove all prior-signed-voucher-request information when
signing a voucher for imprinting so as to minimize the signing a voucher for imprinting so as to minimize the
final voucher size."; final voucher size.";
} }
} }
} }
} }
} }
<CODE ENDS> <CODE ENDS>
6.1.4. Example voucher request artifacts 6.1.4. Example voucher request artifact
TBD Below a CBOR serialization of the constrained-voucher-request is
shown in diagnostic CBOR notation. The enum value of the assertion
field is calculated to be zero by following the algorithm described
in section 9.6.4.2 of [RFC7950].
{
1001101: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on /
+1 : 0, / SID = 1001102, assertion /
/ "verified" /
+12: "JADA123456789", / SID = 1001113, serial-number /
+5 : h'01020D0F', / SID = 1001106, idevid-issuer /
+8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/
+3 : true, / SID = 1001104, domain-cert
-revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date /
+11: h'01020D0F' / SID = 1001112, proximity
-registrar-subject-public-key-info /
}
}
6.2. Voucher artifact 6.2. Voucher artifact
The voucher's primary purpose is to securely assign a pledge to an The voucher's primary purpose is to securely assign a pledge to an
owner. The voucher informs the pledge which entity it should owner. The voucher informs the pledge which entity it should
consider to be its owner. consider to be its owner.
This document defines a voucher that is a CBOR encoded instance of This document defines a voucher that is a CBOR encoded instance of
the YANG module defined in Section 5.3 that has been signed with CMS the YANG module defined in Section 5.3 that has been signed with CMS
or with COSE. or with COSE.
6.2.1. Tree Diagram 6.2.1. Tree Diagram
The following diagram is largely a duplicate of the contents of The following diagram is largely a duplicate of the contents of
[RFC8366], with only the addition of pinned-domain-subject-public- [RFC8366], with only the addition of pinned-domain-subject-public-
key-info. key-info.
module: ietf-constrained-voucher module: ietf-constrained-voucher
grouping voucher-constrained-grouping grouping voucher-constrained-grouping
+---- voucher +-- voucher
+---- created-on +-- created-on? yang:date-and-time
| yang:date-and-time +-- expires-on? yang:date-and-time
+---- expires-on? +-- assertion enumeration
| yang:date-and-time +-- serial-number string
+---- assertion enumeration +-- idevid-issuer? binary
+---- serial-number string +-- pinned-domain-cert? binary
+---- idevid-issuer? binary +-- domain-cert-revocation-checks? boolean
+---- pinned-domain-cert binary +-- nonce? binary
+---- domain-cert-revocation-checks? boolean +-- last-renewal-date? yang:date-and-time
+---- nonce? binary +-- pinned-domain-subject-public-key-info? binary
+---- last-renewal-date?
| yang:date-and-time
+---- pinned-domain-subject-public-key-info? binary
6.2.2. SID values 6.2.2. SID values
SID Assigned to
--------- --------------------------------------------------
1001104 data .../voucher
1001105 data .../assertion
1001106 data .../created-on
1001107 data .../domain-cert-revocation-checks
1001108 data .../expires-on
1001109 data .../idevid-issuer
1001110 data .../last-renewal-date
1001111 data .../nonce
1001112 data .../pinned-domain-cert
1001113 data .../pinned-domain-subject-public-key-info
1001114 data .../serial-number
6.2.3. YANG Module 6.2.3. YANG Module
In the constraine-voucher YANG module, the voucher is "used" and not In the constraine-voucher YANG module, the voucher is "augmented"
"augmented" such that one continuous set of SID values is generated within the "used" grouping statement such that one continuous set of
for the constrained-voucher module name, all voucher attributes, and SID values is generated for the constrained-voucher module name, all
the constrained-voucher attribute. voucher attributes, and the constrained-voucher attribute. Two
attributes of the voucher are "refined" to be optional.
<CODE BEGINS> file "ietf-constrained-voucher@2018-09-01.yang" <CODE BEGINS> file "ietf-constrained-voucher@2018-09-01.yang"
module ietf-constrained-voucher { module ietf-constrained-voucher {
yang-version 1.1; yang-version 1.1;
namespace namespace
"urn:ietf:params:xml:ns:yang:ietf-constrained-voucher"; "urn:ietf:params:xml:ns:yang:ietf-constrained-voucher";
prefix "constrained"; prefix "constrained";
import ietf-restconf { import ietf-restconf {
prefix rc; prefix rc;
description description
"This import statement is only present to access "This import statement is only present to access
the yang-data extension defined in RFC 8040."; the yang-data extension defined in RFC 8040.";
reference "RFC 8040: RESTCONF Protocol"; reference "RFC 8040: RESTCONF Protocol";
}
} import ietf-voucher {
prefix "v";
}
import ietf-voucher { organization
prefix "v"; "IETF ANIMA Working Group";
}
organization contact
"IETF ANIMA Working Group"; "WG Web: <http://tools.ietf.org/wg/anima/>
WG List: <mailto:anima@ietf.org>
Author: Michael Richardson
<mailto:mcr+ietf@sandelman.ca>
Author: Peter van der Stok
<mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis
<mailto: pkampana@cisco.com>";
description
"This module defines the format for a voucher, which is produced
by a pledge's manufacturer or delegate (MASA) to securely assign
one or more pledges to an 'owner', so that the pledges may
establis a secure connection to the owner's network
infrastructure.
contact This version provides a very restricted subset appropriate
"WG Web: <http://tools.ietf.org/wg/anima/> for very constrained devices.
WG List: <mailto:anima@ietf.org> In particular, it assumes that nonce-ful operation is
Author: Michael Richardson always required, that expiration dates are rather weak, as no
<mailto:mcr+ietf@sandelman.ca> clocks can be assumed, and that the Registrar is identified
Author: Peter van der Stok by a pinned Raw Public Key.
<mailto: consultancy@vanderstok.org>
Author: Panos Kampanakis
<mailto: pkampana@cisco.com>";
description
"This module defines the format for a voucher, which is produced
by a pledge's manufacturer or delegate (MASA) to securely assign
one or more pledges to an 'owner', so that the pledges may
establis a secure connection to the owner's network
infrastructure.
This version provides a very restricted subset appropriate The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
for very constrained devices. 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY',
In particular, it assumes that nonce-ful operation is and 'OPTIONAL' in the module text are to be interpreted as
always required, that expiration dates are rather weak, as no described in RFC 2119.";
clocks can be assumed, and that the Registrar is identified
by a pinned Raw Public Key.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', revision "2018-09-01" {
'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', description
and 'OPTIONAL' in the module text are to be interpreted as "Initial version";
described in RFC 2119."; reference
"RFC XXXX: Voucher Profile for Constrained Devices";
}
revision "2018-09-01" { rc:yang-data voucher-constrained-artifact {
description // YANG data template for a voucher.
"Initial version"; uses voucher-constrained-grouping;
reference }
"RFC XXXX: Voucher Profile for Constrained Devices";
}
rc:yang-data voucher-constrained-artifact { // Grouping defined for future usage
// YANG data template for a voucher. grouping voucher-constrained-grouping {
uses voucher-constrained-grouping; description
} "Grouping to allow reuse/extensions in future work.";
// Grouping defined for future usage
grouping voucher-constrained-grouping {
description
"Grouping to allow reuse/extensions in future work.";
uses v:voucher-artifact-grouping { uses v:voucher-artifact-grouping {
augment "voucher" {
description "Base the constrained voucher upon the regular one"; refine voucher/created-on {
leaf pinned-domain-subject-public-key-info { mandatory false;
type binary; }
description
"The pinned-domain-subject replaces the refine voucher/pinned-domain-cert {
pinned-domain-certificate in constrained uses of mandatory false;
the voucher. The pinned-domain-subject-public-key-info }
is the Raw Public Key of the Registrar.
This field is encoded as specified in RFC7250, section 3. augment "voucher" {
The ECDSA algorithm MUST be supported. description "Base the constrained voucher
The EdDSA algorithm as specified in upon the regular one";
draft-ietf-tls-rfc4492bis-17 SHOULD be supported. leaf pinned-domain-subject-public-key-info {
Support for the DSA algorithm is not recommended. type binary;
Support for the RSA algorithm is a MAY."; description
} "The pinned-domain-subject-public-key-info replaces the
} pinned-domain-cert in constrained uses of
} the voucher. The pinned-domain-subject-public-key-info
} is the Raw Public Key of the Registrar.
} This field is encoded as specified in RFC7250,
<CODE ENDS> section 3.
The ECDSA algorithm MUST be supported.
The EdDSA algorithm as specified in
draft-ietf-tls-rfc4492bis-17 SHOULD be supported.
Support for the DSA algorithm is not recommended.
Support for the RSA algorithm is a MAY.";
}
}
}
}
}
<CODE ENDS>
6.2.4. Example voucher artifacts 6.2.4. Example voucher artifacts
Below a the CBOR serialization of the the constrained-voucher and Below a the CBOR serialization of the the constrained-voucher and
constrained-voucher-request are shown in diagnostic CBOR notation. constrained-voucher-request are shown in diagnostic CBOR notation.
The enum value of the assertion field is calculated to be zero by
following the algorithm described in section 9.6.4.2 of [RFC7950].
6.2.4.1. CBOR serialization of constrained-voucher
{ {
1001051: { 1001051: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on / +2 : "2016-10-07T19:31:42Z", / SID = 1001053, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on / +4 : "2016-10-21T19:31:42Z", / SID = 1001055, expires-on /
+1 : "verified", / SID = 1001052, assertion / +1 : 0, / SID = 1001052, assertion /
+11: "JADA123456789", / SID = 1001062, serial-number / / "verified" /
+10: "JADA123456789", / SID = 1001061, serial-number /
+5 : h'01020D0F', / SID = 1001056, idevid-issuer / +5 : h'01020D0F', / SID = 1001056, idevid-issuer /
+8 : h'01020D0F', / SID = 1001059, pinned-domain-cert/ +8 : h'01020D0F', / SID = 1001059, pinned-domain-cert/
+3 : true, / SID = 1001054, domain-cert +3 : true, / SID = 1001054, domain-cert
-revocation-checks/ -revocation-checks/
+6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date / +6 : "2017-10-07T19:31:42Z", / SID = 1001057, last-renewal-date /
+9 : h'01020D0F' / SID = 1001060, pinned-domain +9 : h'01020D0F' / SID = 1001060, pinned-domain
-subject-public-key-info / -subject-public-key-info /
} }
} }
6.2.4.2. CBOR serialization of constrained-voucher-request
{
1001101: {
+2 : "2016-10-07T19:31:42Z", / SID = 1001103, created-on /
+4 : "2016-10-21T19:31:42Z", / SID = 1001105, expires-on /
+1 : "verified", / SID = 1001102, assertion /
+11: "JADA123456789", / SID = 1001112, serial-number /
+5 : h'01020D0F', / SID = 1001106, idevid-issuer /
+8 : h'01020D0F', / SID = 1001109, pinned-domain-cert/
+3 : true, / SID = 1001104, domain-cert
-revocation-checks /
+6 : "2017-10-07T19:31:42Z", / SID = 1001107, last-renewal-date /
+10: h'01020D0F' / SID = 1001111, proximity
-registrar-subject-public-key-info /
}
}
6.3. CMS format voucher and voucher-request artifacts 6.3. CMS format voucher and voucher-request artifacts
The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed The IETF evolution of PKCS#7 is CMS [RFC5652]. The CMS signed
voucher is much like the equivalent voucher defined in [RFC8366]. voucher is much like the equivalent voucher defined in [RFC8366].
A different eContentType of TBD1 is used to indicate that the A different eContentType of TBD1 is used to indicate that the
contents are in a different format than in [RFC8366]. contents are in a different format than in [RFC8366].
The ContentInfo structure contains a payload consisting of the CBOR The ContentInfo structure contains a payload consisting of the CBOR
encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding encoded voucher. The [I-D.ietf-core-yang-cbor] use of delta encoding
skipping to change at page 15, line 44 skipping to change at page 17, line 26
CBOR object that carries the body, the signature, and the information CBOR object that carries the body, the signature, and the information
about the body and signature is called the COSE_Sign1 structure. It about the body and signature is called the COSE_Sign1 structure. It
is used when only one signature is used on the body. The signature is used when only one signature is used on the body. The signature
algorithm is ECSDA with three curves P-256, P-384, and P-512. algorithm is ECSDA with three curves P-256, P-384, and P-512.
Support for EdDSA is encouraged. Support for EdDSA is encouraged.
Unlike with the CMS structure, the COSE-Sign1 structure does not Unlike with the CMS structure, the COSE-Sign1 structure does not
provide a standard way for the signing keys to be included in the provide a standard way for the signing keys to be included in the
structure. This will not, in general, be a problem for the Pledge, structure. This will not, in general, be a problem for the Pledge,
as it the key needed to verify the signature MUST be included at as the key needed to verify the signature MUST be included at
manufacturing time. manufacturing time.
A problem arises for the Registrar, in order for it to verify the A problem arises for the Registrar: to verify the voucher, the
voucher, it must have access to the MASA's public key. This document Registrar must have access to the MASA's public key. This document
does not specify how to transfer the relevant key. does not specify how to transfer the relevant key.
7. Design Considerations 7. Design Considerations
The design considerations for the CBOR encoding of vouchers is much The design considerations for the CBOR encoding of vouchers is much
the same as for [RFC8366]. the same as for [RFC8366].
One key difference is that the names of the leaves in the YANG does One key difference is that the names of the leaves in the YANG does
not have a material effect on the size of the resulting CBOR, as the not have a material effect on the size of the resulting CBOR, as the
SID translation process assigns integers to the names. SID translation process assigns integers to the names.
skipping to change at page 20, line 7 skipping to change at page 22, line 7
choices. choices.
Michel Veillette did extensive work on pyang to extend it to support Michel Veillette did extensive work on pyang to extend it to support
the SID allocation process, and this document was among the first the SID allocation process, and this document was among the first
users. users.
We are grateful for the suggestions done by Esko Dijk. We are grateful for the suggestions done by Esko Dijk.
11. Changelog 11. Changelog
-02
Example of requestvoucher with unsigned appllication/cbor is added
attributes of voucher "refined" to optional
CBOR serialization of vouchers improved
-01 -01
application/json is optional, application/cbor is compulsory application/json is optional, application/cbor is compulsory
Cms and cose mediatypes are introduced Cms and cose mediatypes are introduced
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-ace-cbor-web-token] [I-D.ietf-ace-cbor-web-token]
skipping to change at page 21, line 29 skipping to change at page 23, line 35
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
RFC 7950, DOI 10.17487/RFC7950, August 2016,
<https://www.rfc-editor.org/info/rfc7950>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert, [RFC8366] Watsen, K., Richardson, M., Pritikin, M., and T. Eckert,
"A Voucher Artifact for Bootstrapping Protocols", "A Voucher Artifact for Bootstrapping Protocols",
RFC 8366, DOI 10.17487/RFC8366, May 2018, RFC 8366, DOI 10.17487/RFC8366, May 2018,
<https://www.rfc-editor.org/info/rfc8366>. <https://www.rfc-editor.org/info/rfc8366>.
12.2. Informative References 12.2. Informative References
skipping to change at page 23, line 32 skipping to change at page 26, line 11
A 2.05 Content response with a non signed CBOR voucher (ct=60) will A 2.05 Content response with a non signed CBOR voucher (ct=60) will
then be: then be:
2.05 Content (Content-Format: application/cbor) 2.05 Content (Content-Format: application/cbor)
Payload = Payload =
[EDNOTE: put here voucher payload ] [EDNOTE: put here voucher payload ]
A.3. requestvoucher A.3. requestvoucher
A coaps requestvoucher message can be : Two request-voucher request payloads are possible from pledge to
Registrar, a signed one and an unsigned one, as explained in
Section 5.2 of [I-D.ietf-anima-bootstrapping-keyinfra].
A.3.1. signed requestvoucher
A coaps signed requestvoucher message from RA to MASA can be :
POST coaps://[2001:db8::2:1]:61616]/est/rv POST coaps://[2001:db8::2:1]:61616]/est/rv
A 2.04 Changed response returning CBOR voucher signed with a cms A 2.04 Changed response returning CBOR voucher signed with a cms
structure(ct=TBD2) will then be: structure(ct=TBD2) will then be:
2.05 Changed (Content-Format: application/voucher-cms+cbor) 2.04 Changed (Content-Format: application/voucher-cms+cbor)
Payload =
[EDNOTE: put here encrypted voucher payload ]
A.3.2. unsigned requestvoucher
A coaps unsigned requestvoucher message from pledge to Registrar can
be :
POST coaps://[2001:db8::2:1]:61616]/est/rv
A 2.04 Changed response returning CBOR voucher (ct=60) will then be:
2.04 Changed (Content-Format: application/cbor)
Payload = Payload =
[EDNOTE: put here encrypted voucher payload ] [EDNOTE: put here encrypted voucher payload ]
A.4. requestauditing A.4. requestauditing
A coaps requestauditing message can be : A coaps requestauditing message can be :
GET coaps://[2001:db8::2:1]:61616]/est/ra GET coaps://[2001:db8::2:1]:61616]/est/ra
A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will A 2.05 Content response returning a COSE_Sign1 object (ct=TBD3) will
 End of changes. 46 change blocks. 
193 lines changed or deleted 284 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/