Internet DRAFT - draft-pritikin-coap-bootstrap
draft-pritikin-coap-bootstrap
ANIMA WG M. Pritikin
Internet-Draft P. Kampanakis
Intended status: Informational Cisco Systems
Expires: May 4, 2017 October 31, 2016
BRSKI over CoAP
draft-pritikin-coap-bootstrap-01
Abstract
This document provides an initial discussion of Bootstrapping of
Remote Secure key infrastructures (BRSKI) when the device being
bootstrapped speaks CoAP. The HTTPS REST methods leveraged by BRSKI
are mapped to CoAP methods. Fragmentation management of large
messages during EST certificate enrollment is addressed.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Pritikin & Kampanakis Expires May 4, 2017 [Page 1]
Internet-Draft BRSKI over CoAP October 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Scope of solution . . . . . . . . . . . . . . . . . . . . . . 3
4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. Message Bindings . . . . . . . . . . . . . . . . . . . . . . 4
5.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 6
5.3. csrattr . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4. requestaudittoken, requestauditlog . . . . . . . . . . . 7
6. Data Fragmentation . . . . . . . . . . . . . . . . . . . . . 7
6.1. Fragmented response example with Block2 . . . . . . . . . 8
6.2. Fragmented request example with Block1 . . . . . . . . . 11
6.3. Fragmented request/response example with Block1, Size1
and Block2 . . . . . . . . . . . . . . . . . . . . . . . 11
7. Proxying . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. CoAP Parameters . . . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Update Tracking . . . . . . . . . . . . . . . . . . . . . . . 11
11. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Many IoT and other devices are expected to use CoAP over UDP
extensively. Bootstrapping these devices without requiring a full
TCP stack is an often raised requirement for
[I-D.ietf-anima-bootstrapping-keyinfra]. BRSKI provides REST methods
over TLS that can be functional in a UDP setting with the folling
necessary additions:
DTLS: Because the CoAP use of DTLS includes support for large
handshake messages there is little to describe here. BRSKI and
EST [RFC7030] are expanded to include DTLS.
REST: The mapping of BRSKI and EST messages to CoAP REST calls is
described.
Fragmentation: Use of block chaining to support fragmentation of
large BRSKI and EST messages is described.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
Pritikin & Kampanakis Expires May 4, 2017 [Page 2]
Internet-Draft BRSKI over CoAP October 2016
3. Scope of solution
The definition of BRSKI over DTLS and CoAP is not intended to expand
the scope of BRSKI to highly constrained devices. (ref: [RFC7228]).
Instead it is intended to ensure that bootstrapping works for less
constained devices that choose to limit their communications stack to
UDP/CoAP.
The BRSKI document details extensions to EST as well as making
section 5.7 requirements on EST flows. This document's references to
BRSKI are intended to include all BRSKI extensions and all existing
EST messages. This document could replace BRSKI -03 section 5.7.5.
[[TODO: making this section 5.8 might make the most sense.]]
Support for Observe CoAP options ( https://tools.ietf.org/html/
rfc7641 ) in Blocks with BRSKI is not supported in the current BRSKI/
EST message flows and is thus out-of-scope for this discussion.
Observe options could be used by the server to notify clients about a
change in the cacerts or csr attributes (resources) and might be an
area of future work.
4. DTLS
COAP was designed to avoid fragmentation. DTLS is used to secure
COAP messages. When using DTLS, even though it can be avoided by
using pre-shared keys or ECC ciphersuites, sometimes fragmentation
will be needed. During the DTLS handshake, if fragmentation is
necessary, "DTLS provides a mechanism for fragmenting a handshake
message over a number of records, each of which can be transmitted
separately, thus avoiding IP fragmentation" [RFC6347].
Within BRSKI and EST when "TLS" is referred to, it is understood that
CoAP security is provided using DTLS instead. No other changes are
necessary (all provisional modes etc are the same as for TLS).
In a constrained CoAP environment, endpoints can't afford to
establish a DTLS connection for every EST transaction.
Authenticating and negotiating DTLS keys requires resources on low-
end endpoints and consumes valuable bandwidth. The DTLS connection
SHOULD remain open for persistent EST connections. For example, an
EST cacerts request that is followed by an simpleenroll request can
use the same authenticated DTLS connection. Given that after a
successfull enrollment, it is more likely that a new EST transaction
will take place after a significant amount of time, the DTLS
connections SHOULD only be kept alive for EST messages that are
relatively close to each other.
Pritikin & Kampanakis Expires May 4, 2017 [Page 3]
Internet-Draft BRSKI over CoAP October 2016
5. Message Bindings
This section describes BRSKI to CoAP message mappings.
CoAP defines confirmed (CON), acknowledgements (ACK), reset (RST) and
non-corfirmed (NON) message types. For confirmable messages, the
responses are CoAP ACKs or RSTs. All /cacerts, /simpleenroll,
/simplereenroll, /csrattrs, /fullcmc and /serverkeygen EST messages
expect a response, so they are all COAP CON messages.
The HTTP responses in BRSKI are translated to COAP Response Codes as
explained in [RFC7252] section 5.3.1
A CoAP message has the following fields ([I-D.ietf-core-block]):
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ver| T | TKL | Code | Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Token (if any, TKL bytes) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1 1 1 1| Payload (if any) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Then Ver, TKL, Token, Message ID are not affected in BRSKI. Their
use is the same as in CoAP.
The options that can be used in a CoAP header have the following
format (from [I-D.ietf-core-block] Figure 8):
0 1 2 3 4 5 6 7
+---------------+---------------+
| Option Delta | Option Length | 1 byte
+---------------+---------------+
/ Option Delta / 0-2 bytes
\ (extended) \
+-------------------------------+
/ Option Length / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Option Value / 0 or more bytes
\ \
+-------------------------------+
Pritikin & Kampanakis Expires May 4, 2017 [Page 4]
Internet-Draft BRSKI over CoAP October 2016
Options are used to convey Uri-Host, Uri-Path, Uri-Port, Content-
Format and more in COAP. For BRSKI, COAP Options are used to
communicate the HTTP fields used in the BRSKI REST messages.
BRSKI URLs are HTTPS based (https:// ), in CoAP these will be assumed
to be transformed to coaps (coaps://)
Some examples of how an BRSKI message would be translated in CoAP
follow. [[TODO: This section to be expanded to ensure it covers all
BRSKI edge conditions.]]
5.1. cacerts
First let's see how a get cacerts message in EST would be in CoAP.
The HTTPS cacerts message can be
GET /.well-known/est/cacerts HTTP/1.1
User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0
OpenSSL/1.0.1 zlib/1.2.3.4 libidn/1.23 librtmp/2.3
Host: 192.0.2.1:8085
Accept: */*
The corresponding CoAP fields would be:
Ver = 1
T = 0 (CON)
Code = 0x01 (0.01 is GET)
Options
Option1 (Uri-Host)
Option Delta = 0x3
Option Length = 0x9
Option Value = 192.0.2.1
Option2 (Uri-Port)
Option Delta = 0xA
Option Length = 0x4
Option Value = 8085
Option3 (Uri-Path)
Option Delta = 0xD
Option Length = 0xD
Extended Option Delta = 0x08
Extended Option Length = 0x14
Option Value = /.well-known/est/cacerts HTTP/1.1
Payload = [Empty]
Now let's say we have a 200 OK response with a cert in EST:
Pritikin & Kampanakis Expires May 4, 2017 [Page 5]
Internet-Draft BRSKI over CoAP October 2016
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime
Content-Transfer-Encoding: base64 (TODO: Verify if we need a new
option registry for Encoding?)
Content-Length: 4246 (TODO: this example overflows and would
need fragmentation. Choose a better example.
Regardless we might need an CoAP option for
the content-length ie the CoAP payload?)
MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExADALBgkqhkiG9w0BBwGgggwMMIIC
+zCCAeOgAwIBAgIJAJpY3nUZO3qcMA0GCSqGSIb3DQEBBQUAMBsxGTAXBgNVBAMT
...
The corresponding CoAP fields would be:
Ver = 1
T = 2 (ACK)
Code = 0x21 (TODO: Maybe we need to create a 0x200 response code.)
Options
Option1 (Content-Format)
Option Delta = 0xC
Option Length = 0xD
Extended Option Length = 0x09
Option Value = <number for application/pkcs7-mime>
(TODO: We need a new CoAP IANA registered value
application/pkcs7-mime; smime-type=certs-only,
application/csrattrs, application/pkcs10,
application/pkcs8,
application/pkcs12 )
Payload = MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYCAQExA \
DALBgkqhkiG9w0BBwGgggwMMIIC...
5.2. enroll / reenroll
[[TODO: username/password authentication can be described here but is
not a primary focus for BRSKI. It is important for generic EST
exchanges but would an endpoint device with sufficient user interface
to allow username/password input from an end user be required to use
CoAP instead of a full HTTPS exchange?]]
[[TODO: We might need a new Option for the Retry-After response
message. We might need a new Option for the WWW-Authenticate
response.]]
Pritikin & Kampanakis Expires May 4, 2017 [Page 6]
Internet-Draft BRSKI over CoAP October 2016
5.3. csrattr
5.4. requestaudittoken, requestauditlog
6. Data Fragmentation
Even though ECC certificates are small in size, they can vary greatly
based on signature algorithms, key sizes, and OID fields used. Even
with ECC certs, BRSKI CoAP messages carrying such certificates can
still exceed sizes in MTU of 1280 for IPv6 or 60-80 bytes for 6LoWPAN
[RFC4919]) (section 2 of [I-D.ietf-core-block]). For 256-bit curves,
common ECDSA cert sizes are 500-1000 bytes which could fluctuate
further based on the algorithms, OIDs, SANs and cert fields. For
384-bit curves, ECDSA certs increase in size and can sometimes reach
1.5KB. Additionally, there are times when the EST cacert response
from the server can include multiple certs that amount large
payloads.
CoAP RFC section 4.6 describes the possible payload sizes: "if
nothing is known about the size of the headers, good upper bounds are
1152 bytes for the message size and 1024 bytes for the payload size".
Also "If IPv4 support on unusual networks is a consideration,
implementations may want to limit themselves to more conservative
IPv4 datagram sizes such as 576 bytes; per [RFC0791], the absolute
minimum value of the IP MTU for IPv4 is as low as 68 bytes, which
would leave only 40 bytes minus security overhead for a UDP payload".
Thus, after the DTLS connection is established, fragmentation will
sometimes be needed for the CoAP messages which involve certificate
enrollment and management. A fragmentation solution for BRSKI and
EST CoAP message is required.
The [I-D.ietf-core-block] document describes how fragmentation can be
done by using a pair of Block options added to the CoAP flow. Block1
options are used by the client PUT and POST requests. A Block1 in a
client request requires a Block1 option in the responses. A Block2
comes from a server response that will also need Block2 from the
client to acknowledge the block and get the rest of blocks from the
server. So, Block1 is used when a request (POST for example) is done
in BRSKI over CoAP with a payload that needs fragmentation. Then the
server responds with Block1 option to acknowledge the fragment-
blocks. Block2 is used when a BRSKI server response is big and needs
fragmentation. The Block2 acknowledgements are requests with the
same options as the initial request and a Block2 option. "To
influence the block size used in a response, the requester MAY also
use the Block2 Option on the initial request, giving the desired
size, a block number of zero and an M bit of zero". As explained in
see section 2.8 of [I-D.ietf-core-block]), blockwise transfers SHOULD
Pritikin & Kampanakis Expires May 4, 2017 [Page 7]
Internet-Draft BRSKI over CoAP October 2016
be used in Confirmable COAP messages to avoid the exacerbation of
lost blocks.
In a scenario with a big BRSKI POST request we might have Block1
options from client to server and Block2 from server to client. In
this case the Block1 blocks get completed and then the Block2 comes
the other direction.
The BLOCK draft also defines Size1 and Size2 options. These are used
to convey the size of the resources in the requests or responses.
The Size1 response MAY be parsed by the client as an size indication
of the Block2 resource in the server response or by the server as a
request for a size estimate by the client. Similarly, Size2 option
defined in BLOCK should be parsed by the server as an indication of
the size of the resource carried in Block1 options and by the client
as a maximum size expected in the 4.13 (Request Entity Too Large)
response to a request.
6.1. Fragmented response example with Block2
An example of a server cacerts response that exceeds the MTU is:
An example of a server cacerts response that exceeds the MTU is
HTTP/1.1 200 OK
Status: 200 OK
Content-Type: application/pkcs7-mime; smime-type=certs-only
Content-Transfer-Encoding: base64
Content-Length: 1122
MIIDOAYJKoZIhvcNAQcCoIIDKTCCAyUCAQExADALBgkqhkiG9w0BBwGgggMLMIID
BzCCAe+gAwIBAgIBFTANBgkqhkiG9w0BAQUFADAbMRkwFwYDVQQDExBlc3RFeGFt
cGxlQ0EgTndOMB4XDTEzMDUwOTIzMTU1M1oXDTE0MDUwOTIzMTU1M1owHzEdMBsG
A1UEAxMUZGVtb3N0ZXA0IDEzNjgxNDEzNTIwggEiMA0GCSqGSIb3DQEBAQUAA4IB
DwAwggEKAoIBAQClNp+kdz+Nj8XpEp9kaumWxDZ3eFYJpQKz9ddD5e5OzUeCm103
ZIXQIxc0eVtMCatnRr3dnZRCAxGjwbqoB3eKt29/XSQffVv+odbyw0WdkQOIbntC
Qry8YdcBZ+8LjI/N7M2krmjmoSLmLwU2V4aNKf0YMLR5Krmah3Ik31jmYCSvwTnv
6mx6pr2pTJ82JavhTEIIt/fAYq1RYhkM1CXoBL+yhEoDanN7TzC94skfS3VV+f53
J9SkUxTYcy1Rw0k3VXfxWwy+cSKEPREl7I6k0YeKtDEVAgBIEYM/L1S69RXTLuji
rwnqSRjOquzkAkD31BE961KZCxeYGrhxaR4PAgMBAAGjUjBQMA4GA1UdDwEB/wQE
AwIEsDAdBgNVHQ4EFgQU/qDdB6ii6icQ8wGMXvy1jfE4xtUwHwYDVR0jBBgwFoAU
scRp5lujBKfYl6OLO7+5arIyQjwwDQYJKoZIhvcNAQEFBQADggEBACmxg1hvL6+7
a+lFTARoxainBx5gxdZ9omSb0L+qL+4PDvg/+KHzKsDnMCrcU6M4YP5n0EDKmGa6
4lY8fbET4tt7juJg6ixb95/760Th0vuctwkGr6+D6ETTfqyHnrbhX3lAhnB+0Ja7
o1gv4CWxh1I8aRaTXdpOHORvN0SMXdcrlCys2vrtOl+LjR2a3kajJO6eQ5leOdzF
QlZfOPhaLWen0e2BLNJI0vsC2Fa+2LMCnfC38XfGALa5A8e7fNHXWZBjXZLBCza3
rEs9Mlh2CjA/ocSC/WxmMvd+Eqnt/FpggRy+F8IZSRvBaRUCtGE1lgDmu6AFUxce
R4POrT2xz8ChADEA
Pritikin & Kampanakis Expires May 4, 2017 [Page 8]
Internet-Draft BRSKI over CoAP October 2016
Block options in CoAP messages can contain fields, SZX, M and NUM
which are not affected by BRSKI.
Let's assume that the cacerts message will need to be broken up to 3
messages. The first Block2 will be:
Ver = 1
T = 2 (ACK)
Code = 0x21 (2.01 success message.
TODO: Do we need to create a 0x200 respond code.)
Options
Option1 (Content-Format)
Option Delta = 0xC
Option Length = 0xD
Extended Option Length = 0x09
Option Value = <number for application/pkcs7-mime;
smime-type=certs-only>
(TODO: We need a new CoAP IANA registered value
application/pkcs7-mime, application/csrattrs,
application/pkcs10, application/pkcs8,
application/pkcs12 )
Option2 (Block2)
Option Delta = 0xD
Option Length = 0x1
Extended Option Delta = 0x16
Option Value = 0x0D
Payload = MIIMOQYJKoZIhvcNAQcCoIIMKjCCDCYC \
AQExADALBgkqhkiG9w0BBwGgggwMMIIC... (512 bytes)
The second Block2:
Pritikin & Kampanakis Expires May 4, 2017 [Page 9]
Internet-Draft BRSKI over CoAP October 2016
Ver = 1
T = 2 (means ACK)
Code = 0x21
Options
Option1 (Content-Format)
Option Delta = 0xC
Option Length = 0xD
Extended Option Length = 0x09
Option Value = <number for application/pkcs7-mime;
smime-type=certs-only>
(TODO: We need a new CoAP IANA registered value
application/pkcs7-mime, application/csrattrs,
application/pkcs10, application/pkcs8,
application/pkcs12 )
Option2 (Block2)
Option Delta = 0xD
Option Length = 0x1
Extended Option Delta = 0x16
Option Value = 0x1D
Payload = ... (512 bytes)
The third and final Block2:
Ver = 1
T = 2 (means ACK)
Code = 0x21
Options
Option1 (Content-Format)
Option Delta = 0xC
Option Length = 0xD
Extended Option Length = 0x09
Option Value = <number for application/pkcs7-mime;
smime-type=certs-only>
(TODO: We need a new CoAP IANA registered value
application/pkcs7-mime, application/csrattrs,
application/pkcs10, application/pkcs8,
application/pkcs12 )
Option2 (Block2)
Option Delta = 0xD
Option Length = 0x1
Extended Option Delta = 0x16
Option Value = 0x25
Payload = ...
Pritikin & Kampanakis Expires May 4, 2017 [Page 10]
Internet-Draft BRSKI over CoAP October 2016
6.2. Fragmented request example with Block1
6.3. Fragmented request/response example with Block1, Size1 and Block2
7. Proxying
[[TODO: This section to be populated. It will address how proxying
can take place by an entity that resides at the edge of the CoAP
network, such as the Registrar, and can reach the BRSKI server
residing in a traditional "TCP setting". ]]
8. CoAP Parameters
[[TODO: This section to be populated. It will address transmission
parameters for BRSKI described in sections 4.7 and 4.8 of the CoAP
draft. BRSKI does not impose any unique parameters that affect the
CoAP parameters in Table 2 and 3 in the CoAP draft but the ones in
CoAP could be affecting BRSKI. For example the processing delay of
CAs could be less then 2s, but in this case they should send an CoAP
ACK every 2s while processing. ]]
9. Security Considerations
[[TODO: This section to be populated. This document describes an
existing protocol moved to CoAP and there should not be additional
security concerns added beyond the protocol's or CoAP's specifics
security considerations.]]
10. Update Tracking
-01:
Added more binding usecases and Block examples subsections to be
expanded on later. Made various text improvements and
clarifications.
Added two clarifying sentences in the relevant sections to address
Brian C.'s comments and explain that message fragmentation can be
avoided to a degree in DTLS and that fragments of block transfers
should be confirmed to prevent exacerbated fragment loss in
constrained networks.
11. Normative References
Pritikin & Kampanakis Expires May 4, 2017 [Page 11]
Internet-Draft BRSKI over CoAP October 2016
[I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., and S.
Bjarnason, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-03 (work in progress), June 2016.
[I-D.ietf-core-block]
Bormann, D. and Z. Shelby, "Block-wise transfers in CoAP",
draft-ietf-core-block-20 (work in progress), April 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014,
<http://www.rfc-editor.org/info/rfc7252>.
Authors' Addresses
Max Pritikin
Cisco Systems
Email: pritikin@cisco.com
Panos Kampanakis
Cisco Systems
Email: pkampana@cisco.com
Pritikin & Kampanakis Expires May 4, 2017 [Page 12]
