draft-ietf-ace-coap-est-01.txt   draft-ietf-ace-coap-est-02.txt 
ACE P. van der Stok ACE P. van der Stok
Internet-Draft Consultant Internet-Draft Consultant
Intended status: Standards Track P. Kampanakis Intended status: Standards Track P. Kampanakis
Expires: December 8, 2018 Cisco Systems Expires: December 23, 2018 Cisco Systems
S. Kumar S. Kumar
Philips Lighting Research Philips Lighting Research
M. Richardson M. Richardson
SSW SSW
M. Furuhed M. Furuhed
Nexus Group Nexus Group
S. Raza S. Raza
RISE SICS RISE SICS
June 6, 2018 June 21, 2018
EST over secure CoAP (EST-coaps) EST over secure CoAP (EST-coaps)
draft-ietf-ace-coap-est-01 draft-ietf-ace-coap-est-02
Abstract Abstract
Enrollment over Secure Transport (EST) is used as a certificate Enrollment over Secure Transport (EST) is used as a certificate
provisioning protocol over HTTPS. Low-resource devices often use the provisioning protocol over HTTPS. Low-resource devices often use the
lightweight Constrained Application Protocol (CoAP) for message lightweight Constrained Application Protocol (CoAP) for message
exchanges. This document defines how to transport EST payloads over exchanges. This document defines how to transport EST payloads over
secure CoAP (EST-coaps), which allows low-resource constrained secure CoAP (EST-coaps), which allows low-resource constrained
devices to use existing EST functionality for provisioning devices to use existing EST functionality for provisioning
certificates. certificates.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 December 8, 2018. This Internet-Draft will expire on December 23, 2018.
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conformance to RFC7925 profiles . . . . . . . . . . . . . . . 3 3. Conformance to RFC7925 profiles . . . . . . . . . . . . . . . 3
4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Design . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Payload format . . . . . . . . . . . . . . . . . . . . . 5 4.1. Payload format . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Content Format application/multipart-core . . . . . . 6
4.2. Message Bindings . . . . . . . . . . . . . . . . . . . . 6 4.2. Message Bindings . . . . . . . . . . . . . . . . . . . . 6
4.3. CoAP response codes . . . . . . . . . . . . . . . . . . . 6 4.3. CoAP response codes . . . . . . . . . . . . . . . . . . . 6
4.4. Delayed Results . . . . . . . . . . . . . . . . . . . . . 6 4.4. Delayed Results . . . . . . . . . . . . . . . . . . . . . 7
4.5. Server-side Key Generation . . . . . . . . . . . . . . . 7 4.5. Server-side Key Generation . . . . . . . . . . . . . . . 8
4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 8 4.6. Message fragmentation . . . . . . . . . . . . . . . . . . 9
4.7. Deployment limits . . . . . . . . . . . . . . . . . . . . 9 4.7. Deployment limits . . . . . . . . . . . . . . . . . . . . 10
5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 9 5. Discovery and URI . . . . . . . . . . . . . . . . . . . . . . 10
6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 10 6. DTLS Transport Protocol . . . . . . . . . . . . . . . . . . . 11
7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 12 7. HTTPS-CoAPS Registrar . . . . . . . . . . . . . . . . . . . . 13
8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Parameters . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.1. Media-Type Registry . . . . . . . . . . . . . . . . . . . 14 9.1. Content-Format Registry . . . . . . . . . . . . . . . . . 16
9.2. Content-Format Registry . . . . . . . . . . . . . . . . . 15 9.2. Resource Type registry . . . . . . . . . . . . . . . . . 17
9.2.1. Content Format application/multict . . . . . . . . . 16
9.3. Resource Type registry . . . . . . . . . . . . . . . . . 17
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. EST server considerations . . . . . . . . . . . . . . . 17 10.1. EST server considerations . . . . . . . . . . . . . . . 17
10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 18 10.2. HTTPS-CoAPS Registrar considerations . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 22 Appendix A. EST messages to EST-coaps . . . . . . . . . . . . . 23
A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 23 A.1. cacerts . . . . . . . . . . . . . . . . . . . . . . . . . 23
A.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 26 A.2. csrattrs . . . . . . . . . . . . . . . . . . . . . . . . 28
A.3. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 27 A.3. enroll / reenroll . . . . . . . . . . . . . . . . . . . . 29
A.4. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 29 A.4. serverkeygen . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. EST-coaps Block message examples . . . . . . . . . . 31 Appendix B. EST-coaps Block message examples . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 B.1. cacerts block example . . . . . . . . . . . . . . . . . . 34
B.2. enroll block example . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
"Classical" Enrollment over Secure Transport (EST) [RFC7030] is used "Classical" Enrollment over Secure Transport (EST) [RFC7030] is used
for authenticated/authorized endpoint certificate enrollment (and for authenticated/authorized endpoint certificate enrollment (and
optionally key provisioning) through a Certificate Authority (CA) or optionally key provisioning) through a Certificate Authority (CA) or
Registration Authority (RA). EST messages run over HTTPS. Registration Authority (RA). EST messages run over HTTPS.
This document defines a new transport for EST based on the This document defines a new transport for EST based on the
Constrained Application Protocol (CoAP) since some Internet of Things Constrained Application Protocol (CoAP) since some Internet of Things
skipping to change at page 4, line 7 skipping to change at page 4, line 8
This section shows how EST-coaps fits into the profiles of low- This section shows how EST-coaps fits into the profiles of low-
resource devices described in [RFC7925]. resource devices described in [RFC7925].
EST-coaps can transport certificates and private keys. Certificates EST-coaps can transport certificates and private keys. Certificates
are responses to (re-)enrollment requests or request for a trusted are responses to (re-)enrollment requests or request for a trusted
certificate list. Private keys can be transported as responses to a certificate list. Private keys can be transported as responses to a
request to a server-side keygeneration as described in section 4.4 of request to a server-side keygeneration as described in section 4.4 of
[RFC7030] and discussed in Section 4.5 of this document. [RFC7030] and discussed in Section 4.5 of this document.
The mandatory cipher suite for DTLS in EST-coaps is As per [RFC7925] section 3.3 and section 4.4, the mandatory cipher
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 defined in [RFC7251] which is the suite for DTLS in EST-coaps is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
mandatory-to-implement cipher suite in CoAP. Additionally, the curve defined in [RFC7251], and the the curve secp256r1 MUST be supported
secp256r1 MUST be supported [RFC4492]; this curve is equivalent to [RFC4492]; this curve is equivalent to the NIST P-256 curve. Crypto
the NIST P-256 curve. [Q-EDNOTE: the NIST P-256 curve is a MUST- agility is important, and the recommendations in [RFC7925] section
according to the terminology of RFC8247, and Curve25519 is a 4.4 and any updates to RFC7925 concerning Curve25519 and other CFRG
SHOULD+]. curves also applies.
DTLS1.2 implementations MUST use the Supported Elliptic Curves and DTLS1.2 implementations MUST use the Supported Elliptic Curves and
Supported Point Formats Extensions [RFC4492]. Uncompressed point Supported Point Formats Extensions [RFC4492]. Uncompressed point
format MUST also be supported. [RFC6090] can be used as summary of format MUST also be supported. [RFC6090] can be used as summary of
the ECC algorithms. DTLS 1.3 implementations differ from DTLS 1.2 the ECC algorithms. DTLS 1.3 implementations differ from DTLS 1.2
because they do not support point format negotiation in favor of a because they do not support point format negotiation in favor of a
single point format for each curve and thus support for DTLS 1.3 does single point format for each curve and thus support for DTLS 1.3 does
not mandate point formation extensions and negotiation. not mandate point formation extensions and negotiation.
The EST-coaps client MUST be configured with at least an implicit TA The EST-coaps client MUST be configured with at least an implicit TA
skipping to change at page 5, line 48 skipping to change at page 5, line 48
of [RFC7030]) are in EST-coaps specified by the Content-Format Option of [RFC7030]) are in EST-coaps specified by the Content-Format Option
(12) of CoAP. The combination of URI path and content-format used (12) of CoAP. The combination of URI path and content-format used
for CoAP MUST map to an allowed combination of URI and media type as for CoAP MUST map to an allowed combination of URI and media type as
defined for EST. The required content-formats for these requests and defined for EST. The required content-formats for these requests and
response messages are defined in Section 9. The CoAP response codes response messages are defined in Section 9. The CoAP response codes
are defined in Section 4.3. are defined in Section 4.3.
EST-coaps is designed for use between low-resource devices and hence EST-coaps is designed for use between low-resource devices and hence
does not need to send base64-encoded data. Simple binary is more does not need to send base64-encoded data. Simple binary is more
efficient (30% smaller payload) and well supported by CoAP. efficient (30% smaller payload) and well supported by CoAP.
Therefore, the content formats specification in Section 9 specifies Therefore, the content formats specification in Section 4.1.1
that the binary payload is transported as a CBOR major type 2, a byte specifies that the binary payload is transported as a CBOR major type
string, for all EST-coaps Content-Formats. In the examples of 2, a byte string, for all EST-coaps Content-Formats. In the examples
Appendix A, the base16 diagnostic notation is used for CBOR major of Appendix A, the base16 diagnostic notation is used for CBOR major
type 2, where h'450aafbb' represents an example binary payload. type 2, where h'450aafbb' represents an example binary payload.
4.1.1. Content Format application/multipart-core
A representation with content format ID TBD8 contains a collection of
representations along with their respective content format. The
content-format identifies the media-type application/multipart-core
specified in [I-D.fossati-core-multipart-ct].
The collection is encoded as a CBOR array [RFC7049] with an even
number of elements. The second, fourth, sixth, etc. element is a
binary string containing a representation. The first, third, fifth,
etc. element is an unsigned integer specifying the content format ID
of the following representation.
For example, a collection containing two representations, one with
content format ID TBD5 and one with content format ID TBD2, looks
like this in diagnostic CBOR notation:
[TBD5,h'0123456789abcdef',TBD2,h'fedcba9876543210']. An example is
shown in Appendix A.4.
4.2. Message Bindings 4.2. Message Bindings
The general EST CoAP message characteristics are: The general EST CoAP message characteristics are:
o All EST-coaps messages expect a response from the server, thus the o All EST-coaps messages expect a response from the server, thus the
client MUST send the requests over confirmable CON COAP messages. client MUST send the requests over confirmable CON COAP messages.
o The Ver, TKL, Token, and Message ID values of the CoAP header are o The Ver, TKL, Token, and Message ID values of the CoAP header are
not affected by EST. not affected by EST.
skipping to change at page 6, line 43 skipping to change at page 7, line 13
is specified how EST requests over CoAP handle delayed messages. is specified how EST requests over CoAP handle delayed messages.
All other HTTP 2xx response codes are not used by EST. For the All other HTTP 2xx response codes are not used by EST. For the
following HTTP 4xx error codes that may occur: 400, 401, 403, 404, following HTTP 4xx error codes that may occur: 400, 401, 403, 404,
405, 406, 412, 413, 415; the equivalent CoAP response code for EST- 405, 406, 412, 413, 415; the equivalent CoAP response code for EST-
coaps is 4.xx. For the HTTP 5xx error codes: 500, 501, 502, 503, 504 coaps is 4.xx. For the HTTP 5xx error codes: 500, 501, 502, 503, 504
the equivalent CoAP response code is 5.xx. the equivalent CoAP response code is 5.xx.
4.4. Delayed Results 4.4. Delayed Results
It is possible that responses are not always directly available by If the server is slow providing the response, she can respond with an
the server, and may even require manual intervention to generate the empty ACK, sending the content later, according to [RFC7252], section
certificate for the server response. Delays of minutes to hours are 5.2.2. If the response will be more than one packet (requring block
possible. Therefore, each GET request MUST be accompanied by the mode) then the client needs to send an empty ACK with code 0.00 for
observe option. When the result is directly available, the client the first block and acknowledge the rest of the blocks accordingly.
receives the result and forgets about the observe as specified in To demonstrate this situation below we show a client sending an
section 3.6 of [RFC7641]. When a POST response is delayed, the POST enrollment request that will use more than one Block1 blocks to send
returns a 2.01 (Created) response code, having put a value in the the CSR to the server. The server on the other hand will need more
Location-Path option. After reception of 2.01 the client does a GET than one Block2 blocks to respond, but will need take some time to
request with the observe option to the newly returned location. Once provide the response. Thus the server will use a 0.00 ACK for the
the delayed result is notified by the server, the client forgets response which will be provided when ready by using 2.04 messages and
Block2 options. Readers should note that the client asks for a
decrease in the block size when acknowledging the first Block2.
CON | POST 1:0/1/256 (enroll request with CSR) -->
<-- ACK | 2.31 1:0/1/256
CON | POST 1:1/1/256 (enroll request with CSR)
<-- ACK | 2.31 1:1/1/256
CON | POST 1:2/0/256 (enroll request with CSR)
<-- ACK (code 0.00, no payload,
to signal delay in the response.
When ready, the server transfers
the response in Block2 blocks.)
CON | 2.04 1:2/0/256 & 2:0/1/128 (Certificate) -->
<-- ACK (code 0.00, no payload)
<-- CON | POST 2:1/0/128
ACK | 2.04 2:1/1/128 (Certificate) -->
<-- CON | POST 2:2/0/128
ACK | 2.04 2:2/0/128 (Certificate) -->
[EDNOTE: To update this. HTTP 202 Retry-After in EST needs an
equivalent mechanism in EST-coaps. Observe seems like a candidate
but after the HTTP 202 the client needs to do a new POST, not a GET,
so Observe is not the best option. We could use 2.04 or a new 2.0x
with Max-Age to convey the EST Retry-After. ] It is possible that
responses are not always directly available by the server, and may
even require manual intervention to generate the certificate for the
server response. Delays of minutes to hours are possible. EST
requires the use of an HTTP 202 message with a Retry-After header by
the server which signals to the client to attempt the request in a
certain amount of time. In EST, each GET request MUST be accompanied
by the observe option. When the result is directly available, the
client receives the result and forgets about the observe as specified
in section 3.6 of [RFC7641]. When a POST response is delayed, the
POST returns a 2.01 (Created) response code, having put a value in
the Location-Path option. After reception of 2.01 the client does a
GET request with the observe option to the newly returned location.
Once the delayed result is notified by the server, the client forgets
about the observe. about the observe.
Next to the observe option the server MUST specify the Max-Age option Next to the observe option the server MUST specify the Max-Age option
that indicates the maximum waiting time in minutes. that indicates the maximum waiting time in minutes.
4.5. Server-side Key Generation 4.5. Server-side Key Generation
Constrained devices sometimes do not have the necessary hardware to Constrained devices sometimes do not have the necessary hardware to
generate statistically random numbers for private keys and DTLS generate statistically random numbers for private keys and DTLS
ephemeral keys. Past experience has shown that low-resource ephemeral keys. Past experience has shown that low-resource
skipping to change at page 7, line 41 skipping to change at page 8, line 49
[RFC7030] recommends for the private key returned by the server to be [RFC7030] recommends for the private key returned by the server to be
encrypted. The specification provides two methods to encrypt the encrypted. The specification provides two methods to encrypt the
generated key, symmetric and asymmetric. The methods are signalled generated key, symmetric and asymmetric. The methods are signalled
by the client by using the relevant attributes (SMIMECapabilities and by the client by using the relevant attributes (SMIMECapabilities and
DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier) in the CSR DecryptKeyIdentifier or AsymmetricDecryptKeyIdentifier) in the CSR
request. In the symmetric key case, the key can be established out- request. In the symmetric key case, the key can be established out-
of-band or alternatively derived by the established TLS connection as of-band or alternatively derived by the established TLS connection as
described in [RFC5705]. described in [RFC5705].
The sever-side key generation response is returned using a CBOR array The sever-side key generation response is returned using a CBOR array
Section 9.2.1. The certificate part exactly matches the response Section 4.1.1. The certificate part exactly matches the response
from a enrollment response. The private key is placed inside of a from a enrollment response. The private key is placed inside of a
CMS SignedData. The SignedData is signed by the party that generated CMS SignedData. The SignedData is signed by the party that generated
the private key, which may or may not be the EST server or the EST the private key, which may or may not be the EST server or the EST
CA. The SignedData is further protected by placing it inside of a CA. The SignedData is further protected by placing it inside of a
CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030]. CMS EnvelopedData as explained in Section 4.4.2 of [RFC7030].
4.6. Message fragmentation 4.6. Message fragmentation
DTLS defines fragmentation only for the handshake part and not for DTLS defines fragmentation only for the handshake part and not for
secure data exchange (DTLS records). [RFC6347] states that to avoid secure data exchange (DTLS records). [RFC6347] states that to avoid
skipping to change at page 14, line 19 skipping to change at page 15, line 24
the private key down to the client with one symmetric key and decrypt the private key down to the client with one symmetric key and decrypt
it from the server with another. If no private key encryption takes it from the server with another. If no private key encryption takes
place the Registrar will be able to see the key as it establishes a place the Registrar will be able to see the key as it establishes a
separate connection to the server. In the case of asymmetrically separate connection to the server. In the case of asymmetrically
encrypted private key, the Registrar may not be able to decrypt it if encrypted private key, the Registrar may not be able to decrypt it if
the server encrypted it with a public key that corresponds to a the server encrypted it with a public key that corresponds to a
private key that belongs to the client. private key that belongs to the client.
8. Parameters 8. Parameters
[EDNOTE: This section to be populated. It will address transmission THis section addresses transmission parameters described in sections
parameters described in sections 4.7 and 4.8 of the CoAP draft. EST 4.7 and 4.8 of the CoAP document [RFC7252].
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 EST. For example, the processing delay of CAs could be
less then 2s, but in this case they should send a CoAP ACK every 2s
while processing.]
9. IANA Considerations ACK_TIMEOUT | 2 seconds |
ACK_RANDOM_FACTOR | 1.5 |
MAX_RETRANSMIT | 4 |
NSTART | 1 |
DEFAULT_LEISURE | 5 seconds |
PROBING_RATE | 1 byte/second |
9.1. Media-Type Registry Figure 2: EST-COAP protocol parameters
This section registers the 'application/multict' media type in the EST does not impose any unique parameters that affect the CoAP
"Media Types" registry. This media type is used to indicate that the parameters in Table 2 and 3 in the CoAP draft but the ones in CoAP
payload is composed of multiple content formats. could be affecting EST. For example, the processing delay of CAs
could be less then 2s, but in this case they should send a CoAP ACK
every 2s while processing.
Type name: application The main recommendation, based on experiments using Nexus Certificate
Subtype name: multict Manager with Californium for CoAP support, communicating with a
Required parameters: none ContikiOS and tinyDTLS based client, from RISE SICS, is to start with
Optional parameters: none the default CoAP configuration parameters.
Encoding considerations: CBOR array of content-format.
Security considerations: See Security Considerations Section
Interoperability considerations: The format is designed to be
broadly interoperable.
Published specification: THIS RFC <xref target="cborpair"/>.
Applications that use this media type: ACE, ANIMA, 6tisch,
and other low-resource EST applications.
Additional information:
Magic number(s): None
File extension(s): .cbor
Macintosh file type code(s): none
Person & email address to contact for further information: IETF
ACE WG
Intended usage: LIMITED
Restrictions on usage: NONE
Author: ACE WG
Change controller: IETF
Provisional registration? (standards tree only): NO
9.2. Content-Format Registry However, depending on the implementation scenario, resending and
timeouts can also occur on other networking layers, governed by other
configuration parameters.
Additions to the sub-registry "CoAP Content-Formats", within the Some further comments about some specific parameters, mainly from
"CoRE Parameters" registry are specified in Table 2. These can be Table 2 in [RFC7252]:
registered either in the Expert Review range (0-255) or IETF Review
range (256-9999).
+---------------------------------+----------+------+---------------+ o DEFAULT_LEISURE: This setting is only relevant in multicast
| Media type | Encoding | ID | Reference | scenarios, outside the scope of the EST-coaps draft.
+---------------------------------+----------+------+---------------+
| application/pkcs7-mime; smime- | - | TBD1 | [RFC5751] |
| type=server-generated-key | | | [RFC7030] |
| application/pkcs7-mime; smime- | - | TBD2 | [RFC5751] |
| type=certs-only | | | |
| application/pkcs7-mime; smime- | - | TBD3 | [RFC5751] |
| type=CMC-request | | | [RFC5273] |
| application/pkcs7-mime; smime- | - | TBD4 | [RFC5751] |
| type=CMC-response | | | [RFC5273] |
| application/pkcs8 | - | TBD5 | [RFC5751] |
| | | | [RFC5958] |
| application/csrattrs | - | TBD6 | [RFC7030] |
| | | | [RFC7231] |
| application/pkcs10 | - | TBD7 | [RFC5751] |
| | | | [RFC5967] |
| application/multict | - | TBD8 | Section 9.2.1 |
+---------------------------------+----------+------+---------------+
Table 2: New CoAP Content-Formats o NSTART: Limit the number of simultaneous outstanding interactions
that a client maintains to a given server. The default is one,
hence is the risk of congestion or out-of-order messages already
limited.
9.2.1. Content Format application/multict o PROBING_RATE: A parameter which specifies the rate of re-sending
non-confirmable messages. The EST messages are defined to be sent
as CoAP confirmable messages, hence the PROBING_RATE setting is
not applicable.
A representation with content format ID TBD8 contains a collection of Finally, the Table 3 parameters are mainly derived from the more
representations along with their respective content format. basic Table 2 parameters. If the CoAP implementation allows setting
them directly, they might need to be updated if the table 2
parameters are changed.
The collection is encoded as a CBOR array [RFC7049] with an even 9. IANA Considerations
number of elements. The second, fourth, sixth, etc. element is a
binary string containing a representation. The first, third, fifth,
etc. element is an unsigned integer specifying the content format ID
of the following representation.
For example, a collection containing two representations, one with 9.1. Content-Format Registry
content format ID TBD5 and one with content format ID TBD2, looks
like this in diagnostic CBOR notation:
[TBD5,h'0123456789abcdef',TBD2,h'fedcba9876543210']. An example is
shown in Appendix A.4.
[EDNOTE: the intention is that this text is replaced by draft- Additions to the sub-registry "CoAP Content-Formats", within the
fossati-core-multipart-ct, which has yet to be adopted. The above "CoRE Parameters" registry are specified in Table 2. These can be
text is a copy of the critical text, in the event that the CORE WG registered either in the Expert Review range (0-255) or IETF Review
does not adopt the document] range (256-9999).
9.3. Resource Type registry +-------------------------+--------+-----+--------------------------+
| Media type | Encodi | ID | Reference |
| | ng | | |
+-------------------------+--------+-----+--------------------------+
| application/pkcs7-mime; | - | TBD | [RFC5751] [RFC7030] |
| smime-type=server- | | 1 | |
| generated-key | | | |
| application/pkcs7-mime; | - | TBD | [RFC5751] |
| smime-type=certs-only | | 2 | |
| application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] |
| smime-type=CMC-request | | 3 | |
| application/pkcs7-mime; | - | TBD | [RFC5751] [RFC5273] |
| smime-type=CMC-response | | 4 | |
| application/pkcs8 | - | TBD | [RFC5751] [RFC5958] |
| | | 5 | |
| application/csrattrs | - | TBD | [RFC7030] [RFC7231] |
| | | 6 | |
| application/pkcs10 | - | TBD | [RFC5751] [RFC5967] |
| | | 7 | |
| application/multict | - | TBD | [I-D.fossati-core-multip |
| | | 8 | art-ct] |
+-------------------------+--------+-----+--------------------------+
Table 2: New CoAP Content-Formats
9.2. Resource Type registry
Additions to the sub-registry "CoAP Resource Type", within the "CoRE Additions to the sub-registry "CoAP Resource Type", within the "CoRE
Parameters" registry are needed for a new resource type. Parameters" registry are needed for a new resource type.
o rt="ace.est" needs registration with IANA. o rt="ace.est" needs registration with IANA.
10. Security Considerations 10. Security Considerations
10.1. EST server considerations 10.1. EST server considerations
skipping to change at page 19, line 5 skipping to change at page 19, line 30
registrar doing the right thing if it is generating they private registrar doing the right thing if it is generating they private
keys. keys.
11. Acknowledgements 11. Acknowledgements
The authors are very grateful to Klaus Hartke for his detailed The authors are very grateful to Klaus Hartke for his detailed
explanations on the use of Block with DTLS and his support for the explanations on the use of Block with DTLS and his support for the
content-format specification. The authors would like to thank Esko content-format specification. The authors would like to thank Esko
Dijk and Michael Verschoor for the valuable discussions that helped Dijk and Michael Verschoor for the valuable discussions that helped
in shaping the solution. They would also like to thank Peter in shaping the solution. They would also like to thank Peter
Panburana from Cisco for his feedback on technical details of the Panburana for his feedback on technical details of the solution.
solution. Constructive comments were received from Benjamin Kaduk, Constructive comments were received from Benjamin Kaduk, Eliot Lear,
Eliot Lear, Jim Schaad, Hannes Tschofenig, and Julien Vermillard. Jim Schaad, Hannes Tschofenig, Julien Vermillard, and John Manuel.
12. Change Log 12. Change Log
-02:
Added paremeter discussion in section 8
Concluded content-format specification using multipart-ct draft
examples updated
-01: -01:
Editorials done. Editorials done.
Redefinition of proxy to Registrar in Section 7. Explained better Redefinition of proxy to Registrar in Section 7. Explained better
the role of https-coaps Registrar, instead of "proxy" the role of https-coaps Registrar, instead of "proxy"
Provide "observe" option examples Provide "observe" option examples
extended block message example.
inserted new server key generation text in Section 4.5 and inserted new server key generation text in Section 4.5 and
motivated server key generation. motivated server key generation.
Broke down details for DTLS 1.3 Broke down details for DTLS 1.3
New media type uses CBOR array for multiple content-format New media type uses CBOR array for multiple content-format
payloads payloads
provided new content format tables provided new content format tables
skipping to change at page 19, line 40 skipping to change at page 20, line 26
new media format for IANA new media format for IANA
-00 -00
copied from vanderstok-ace-coap-04 copied from vanderstok-ace-coap-04
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.fossati-core-multipart-ct]
Bormann, C., "Multipart Content-Format for CoAP", draft-
fossati-core-multipart-ct-05 (work in progress), June
2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 26, line 37 skipping to change at page 26, line 43
6c37de0f55033f192a5ad21f9a2a71c20301000130b040300f0603551d130101f10 6c37de0f55033f192a5ad21f9a2a71c20301000130b040300f0603551d130101f10
530030101fc1d0603551d0e04160414112966e304761732fbfe6a2c823c300e0603 530030101fc1d0603551d0e04160414112966e304761732fbfe6a2c823c300e0603
551d0f0101f10403020106300d06092a620673410105050003204100423f06d4b76 551d0f0101f10403020106300d06092a620673410105050003204100423f06d4b76
0f4b42744a279035571696f272a0060f1325a40898509601ad14004f652db6312a1 0f4b42744a279035571696f272a0060f1325a40898509601ad14004f652db6312a1
475c4d7cd50f4b269035585d7856c5337765a66b38462d5bdaa7778aab24bbe2815 475c4d7cd50f4b269035585d7856c5337765a66b38462d5bdaa7778aab24bbe2815
e37722cd10e7166c50e75ab75a1271324460211991e7445a2960f47351a1a629253 e37722cd10e7166c50e75ab75a1271324460211991e7445a2960f47351a1a629253
34119794b90e320bc730d6c1bee496e7ac125ce9a1eca595a3a4c54a865e6b623c9 34119794b90e320bc730d6c1bee496e7ac125ce9a1eca595a3a4c54a865e6b623c9
247bfd0a7c19b56077392555c955e233642bec643ae37c166c5e221d797aea3748f 247bfd0a7c19b56077392555c955e233642bec643ae37c166c5e221d797aea3748f
0391c8d692a5cf9bb71f6d0e37984d6fa673a30d0c006343116f58403100' 0391c8d692a5cf9bb71f6d0e37984d6fa673a30d0c006343116f58403100'
The hexadecimal dump of the CBOR payload looks like:
59 09CD # bytes(2509)
30233906092A6206734107028C2A3023260201013100300B06092A62067341070
18C0C3020BB302063C20102020900A61E75193B7ACC0D06092A62067341010505
00301B31193017060355040313106573744578616D706C654341204F774F301E1
70D3133303530393033353333315A170D3134303530393033353333315A301B31
193017060355040313106573744578616D706C654341204F774F302062300D060
92A620673410101050003204F0030204A022041003A923A2968BAE4AAE136CA4E
2512C5200680358482AC39D6F640E4574E654EA35F48B1E054C5DA3372872F7A1
E429F4EDF3958432EFB2106591D3EB783C1034709F251FC86566BDA2D541C7923
89EAC4EC9E181F4B9F596E5EF2679CC321542B11337F90A44DF3C85F1516561FA
968A1914F265BC0B8276EBE3106A790D97D34C8C37C74FE1C30B396424664AC42
6284A9F6022E026938436880ADFCD95C98CA1DFC2E6D75319B85D0458DE28A9D1
3FB16D620FFF7541F6A25D7DAF004355020301000130B040300F0603551D13010
1F10530030101FC1D0603551D0E04160414084D321CA0135E77217A486B686B33
4B00E0603551D0F0101F10403020106300D06092A620673410105050003204100
23703B965746A0C2C978666D787A94F89B495A11F0D369B28936EC2475C0F0855
C8E83F823F2B871A1D92282F323C45904BA008579216CF5223B8B1BC425A06772
62047F7700240631C17F3035D1C3780B2385241CBA1F4A6E98E6BE6820306B3A7
86DE5A557795D1893822347B5F825D34A7AD2876F8FEBA4D525B31066F6505796
F71530003431A3E6BBFE788B4565029A7E20A51107677552586152D051E8EEBF3
83E92288983421D5C5652A4870C3AF74B9BDBED6B462E2263D30F6D3020C33020
6BC20102020101300D06092A6206734101050500301B311930170603550403131
06573744578616D706C654341204F774F301E170D313330353039303335333332
5A170D3134303530393033353333325A301B31193017060355040313106573744
578616D706C654341204E774F302062300D06092A620673410101050003204F00
30204A02204100EF6B677A3247C1FC03D2B9BAF113E5E7E11F49E0421120E6B83
84160F2BF02630EF544D5FD0D5623B35713C79A7229283A7908751A634AA420A3
E2A4B1F10519D046F02F5A5DD6D760C2A842356E067B7BD94338D1FAA3B3DDD48
13060A207B0A097067007E45B052B60FDBAE4656E11562C4F5ABB7B0CF87A79D2
21F1127313C53371CE1245D63DB45A1203A23340BA08042C768D03B8076A028D3
A51D87D2EF107BBD6F2305CE5E67668724002FB726DF9C14476C37DE0F55033F1
92A5AD21F9A2A71C20301000134B050300E0603551D0F0101F104030204C1D060
3551D0E04160414112966E304761732FBFE6A2C823C301F0603551D2304183016
5084D321CA0135E77217A486B686B334B00D06092A62067341010505000320410
0B382BA3355A50E287BAE15758B3BEFF63D34D3E357B90031495D018868E49589
B9FAF46A4AD49B1D35B06EF380106677440934663C2CC111C183655F4DC41C0B3
401123D35387389DB91F1E1B4131B16C291D35730B3F9B33C7475124851555FE5
FC647E8FD029605367C7E01281BF6617110021B0D10847DCE0E9F0CA6C764B633
4784055172C3983D1E3A3A82301A54FCC9B0670C543A1C747164619101FF23B24
0B2A26394C1F7D38D0E2F4747928ECE5C34627A075A8B3122011E9D9158055C28
F020C330206BC20102020102300D06092A6206734101050500301B31193017060
355040313106573744578616D706C654341204E774E301E170D31333035303930
33353333325A170D3134303530393033353333325A301B3119301706035504031
3106573744578616D706C654341204F774E302062300D06092A62067341010105
0003204F0030204A022041003A923A2968BAE4AAE136CA4E2512C520068035848
2AC39D6F640E4574E654EA35F48B1E054C5DA3372872F7A1E429F4EDF3958432E
FB2106591D3EB783C1034709F251FC86566BDA2D541C792389EAC4EC9E181F4B9
F596E5EF2679CC321542B11337F90A44DF3C85F1516561FA968A1914F265BC0B8
276EBE3106A790D97D34C8C37C74FE1C30B396424664AC426284A9F6022E02693
8436880ADFCD95C98CA1DFC2E6D75319B85D0458DE28A9D13FB16D620FFF7541F
6A25D7DAF004355020301000134B050300E0603551D0F0101F104030204C1D060
3551D0E04160414084D321CA0135E77217A486B686B334B01F0603551D2304183
01653112966E304761732FBFE6A2C823C300D06092A6206734101050500032041
002E106933A443070ACF5594A3A584D08AF7E06C295059370A06639EFF9BD418D
13BC25A298223164A6CF1856B11A81617282E4A410D82EF086839C6E235690322
763065455351E4C596ACC7C016B225DEC094706C2A10608F403B10821984C7C15
2343B18A768C2AD30238DC45DD653EE6092B0D5CD4C2F7D236043269357F76D13
F95FB5F00D0E19263C6833948E1BA612CE8197AF650E25D882C12F4B6B9B67252
C608EF064ACA3F9BC867D71172349D510BB7651CD43883773D927DEB41C467302
0BB302063C201020209009B9DDA3324700D06092A6206734101050500301B3119
3017060355040313106573744578616D706C654341204E774E301E170D3133303
530393033353333325A170D3134303530393033353333325A301B311930170603
55040313106573744578616D706C654341204E774E302062300D06092A6206734
10101050003204F0030204A02204100EF6B677A3247C1FC03D2B9BAF113E5E7E1
1F49E0421120E6B8384160F2BF02630EF544D5FD0D5623B35713C79A7229283A7
908751A634AA420A3E2A4B1F10519D046F02F5A5DD6D760C2A842356E067B7BD9
4338D1FAA3B3DDD4813060A207B0A097067007E45B052B60FDBAE4656E11562C4
F5ABB7B0CF87A79D221F1127313C53371CE1245D63DB45A1203A23340BA08042C
768D03B8076A028D3A51D87D2EF107BBD6F2305CE5E67668724002FB726DF9C14
476C37DE0F55033F192A5AD21F9A2A71C20301000130B040300F0603551D13010
1F10530030101FC1D0603551D0E04160414112966E304761732FBFE6A2C823C30
0E0603551D0F0101F10403020106300D06092A620673410105050003204100423
F06D4B760F4B42744A279035571696F272A0060F1325A40898509601AD14004F6
52DB6312A1475C4D7CD50F4B269035585D7856C5337765A66B38462D5BDAA7778
AAB24BBE2815E37722CD10E7166C50E75AB75A1271324460211991E7445A2960F
47351A1A62925334119794B90E320BC730D6C1BEE496E7AC125CE9A1ECA595A3A
4C54A865E6B623C9247BFD0A7C19B56077392555C955E233642BEC643AE37C166
C5E221D797AEA3748F0391C8D692A5CF9BB71F6D0E37984D6FA673A30D0C00634
3116F58403100
After reception of the 2.05 response, the client can forget the After reception of the 2.05 response, the client can forget the
observe. observe.
A.2. csrattrs A.2. csrattrs
In the following valid /csrattrs exchange, the EST-coaps client In the following valid /csrattrs exchange, the EST-coaps client
authenticates itself with a certificate issued by the connected CA. authenticates itself with a certificate issued by the connected CA.
The initial DTLS handshake is identical to the enrollment example. The initial DTLS handshake is identical to the enrollment example.
The IPv6 CoAP GET request looks like: The IPv6 CoAP GET request looks like:
skipping to change at page 31, line 45 skipping to change at page 33, line 45
Without the DecryptKeyIdentifier attribute, the response has no Without the DecryptKeyIdentifier attribute, the response has no
additional encryption beyond DTLS. additional encryption beyond DTLS.
The response contains first a preamble that can be ignored. The EST- The response contains first a preamble that can be ignored. The EST-
coaps server can use the preamble to include additional explanations, coaps server can use the preamble to include additional explanations,
like ownership or support information like ownership or support information
Appendix B. EST-coaps Block message examples Appendix B. EST-coaps Block message examples
Two examples are presented: (1) a cacerts exchange shows the use of
Block2 and the block headers, and (2) a enroll exchange shows the
Block1 and Block2 size negotiation for request and response payloads.
B.1. cacerts block example
This section provides a detailed example of the messages using DTLS This section provides a detailed example of the messages using DTLS
and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is and BLOCK option Block2. The minimum PMTU is 1280 bytes, which is
the example value assumed for the DTLS datagram size. The example the example value assumed for the DTLS datagram size. The example
block length is taken as 64 which gives an SZX value of 2. block length is taken as 64 which gives an SZX value of 2.
The following is an example of a valid /cacerts exchange over DTLS. The following is an example of a valid /cacerts exchange over DTLS.
The content length of the cacerts response in appendix A.1 of The content length of the cacerts response in appendix A.1 of
[RFC7030] is 4246 bytes using base64. This leads to a length of 2509 [RFC7030] is 4246 bytes using base64. This leads to a length of 2509
bytes in binary. The CoAP message adds around 10 bytes, the DTLS bytes in binary. The CoAP message adds around 10 bytes, the DTLS
record 29 bytes. To avoid IP fragmentation, the CoAP block option is record 29 bytes. To avoid IP fragmentation, the CoAP block option is
used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 used and an MTU of 127 is assumed to stay within one IEEE 802.15.4
packet. To stay below the MTU of 127, the payload is split in 39 packet. To stay below the MTU of 127, the payload is split in 39
packets with a payload of 64 bytes each, followed by a packet of 13 packets with a payload of 64 bytes each, followed by a packet of 13
bytes. The client sends an IPv6 packet containing the UDP datagram bytes. The client sends an IPv6 packet containing the UDP datagram
with the DTLS record that encapsulates the CoAP Request 40 times. with the DTLS record that encapsulates the CoAP Request 40 times.
The server returns an IPv6 packet containing the UDP datagram with The server returns an IPv6 packet containing the UDP datagram with
the DTLS record that encapsulates the CoAP response. The CoAP the DTLS record that encapsulates the CoAP response. The CoAP
skipping to change at page 32, line 16 skipping to change at page 34, line 25
bytes in binary. The CoAP message adds around 10 bytes, the DTLS bytes in binary. The CoAP message adds around 10 bytes, the DTLS
record 29 bytes. To avoid IP fragmentation, the CoAP block option is record 29 bytes. To avoid IP fragmentation, the CoAP block option is
used and an MTU of 127 is assumed to stay within one IEEE 802.15.4 used and an MTU of 127 is assumed to stay within one IEEE 802.15.4
packet. To stay below the MTU of 127, the payload is split in 39 packet. To stay below the MTU of 127, the payload is split in 39
packets with a payload of 64 bytes each, followed by a packet of 13 packets with a payload of 64 bytes each, followed by a packet of 13
bytes. The client sends an IPv6 packet containing the UDP datagram bytes. The client sends an IPv6 packet containing the UDP datagram
with the DTLS record that encapsulates the CoAP Request 40 times. with the DTLS record that encapsulates the CoAP Request 40 times.
The server returns an IPv6 packet containing the UDP datagram with The server returns an IPv6 packet containing the UDP datagram with
the DTLS record that encapsulates the CoAP response. The CoAP the DTLS record that encapsulates the CoAP response. The CoAP
request-response exchange with block option is shown below. Block request-response exchange with block option is shown below. Block
option is shown in a decomposed way indicating the kind of Block option is shown in a decomposed way (block-option:NUM/M/size)
option (2 in this case because used in the response) followed by a indicating the kind of Block option (2 in this case because used in
colon, and then the block number (NUM), the more bit (M = 0 means the response) followed by a colon, and then the block number (NUM),
last block), and block size exponent (2**(SZX+4)) separated by the more bit (M = 0 in lock2 response means last block), and block
slashes. The Length 64 is used with SZX= 2 to avoid IP size with exponent (2**(SZX+4)) separated by slashes. The Length 64
fragmentation. The CoAP Request is sent with confirmable (CON) is used with SZX= 2 to avoid IP fragmentation. The CoAP Request is
option and the content format of the Response is /application/ sent with confirmable (CON) option and the content format of the
cacerts. Response is /application/cacerts.
GET /192.0.2.1:8085/est/crts --> GET /192.0.2.1:8085/est/crts (2:0/0/64) -->
<-- (2:0/1/39) 2.05 Content <-- (2:0/1/64) 2.05 Content
GET URI (2:1/1/39) --> GET /192.0.2.1:8085/est/crts (2:1/0/64) -->
<-- (2:1/1/39) 2.05 Content <-- (2:1/1/64) 2.05 Content
| |
| |
| |
GET URI (2:65/1/39) --> GET /192.0.2.1:8085/est/crts (2:39/0/64) -->
<-- (2:65/0/39) 2.05 Content <-- (2:39/0/64) 2.05 Content
For further detailing the CoAP headers of the first two blocks are 40 blocks have been sent with partially filled block NUM=39 as last
block.
For further detailing the CoAP headers, the first two blocks are
written out. written out.
The header of the first GET looks like: The header of the first GET looks like:
Ver = 1 Ver = 1
T = 0 (CON) T = 0 (CON)
Code = 0x01 (0.1 GET) Code = 0x01 (0.1 GET)
Token = 0x9a (client generated) Token = 0x9a (client generated)
Options Options
Option1 (Uri-Host) [optional] Option1 (Uri-Host) [optional]
skipping to change at page 35, line 24 skipping to change at page 37, line 24
Option2 (Content-Format) Option2 (Content-Format)
Option Delta = 0xC (option nr =6+6=12) Option Delta = 0xC (option nr =6+6=12)
Option Length = 0x2 Option Length = 0x2
Option Value = TBD2 Option Value = TBD2
Option2 (Block2) Option2 (Block2)
Option Delta = 0xB (option 23 = 12 + 11) Option Delta = 0xB (option 23 = 12 + 11)
Option Length = 0x2 Option Length = 0x2
Option Value = 0x272 (block number = 39, M=0, SZX=2) Option Value = 0x272 (block number = 39, M=0, SZX=2)
Payload = h'73a30d0c006343116f58403100' Payload = h'73a30d0c006343116f58403100'
B.2. enroll block example
In this example the requested block2 size of 256 bytes, required by
the client, is transferred to the server in the very first request
message. The request/response consists of two parts: part1
containing the CSR transferred to the server, and part2 contains the
certificate transferred back to the client. The block size
256=(2**(SZX+4)) which gives SZX=4. The notation for block numbering
is the same as in Appendix B.1. It is assumed that CSR takes N1+1
blocks and Cert response takes N2+1 blocks. The header fields and
the payload are omitted to show the block exchange. The type of
payload is shown within curly brackets.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:0/1/256) {CSR req} -->
<-- (ACK) (1:0/1/256) (2.31 Continue)
POST [2001:db8::2:1]:61616/est/sen (CON)(1:1/1/256) {CSR req} -->
<-- (ACK) (1:1/1/256) (2.31 Continue)
.
.
.
POST [2001:db8::2:1]:61616/est/sen (CON)(1:N1/0/256){CSR req} -->
<-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed)(Cert resp}
POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/256) -->
<-- (ACK) (2:1/1/256) (2.04 Changed) (Cert resp}
.
.
.
POST [2001:db8::2:1]:61616/est/sen (CON)(2:N2/0/256) -->
<-- (ACK) (2:N2/0/256) (2.04 Changed) (Cert resp}
N1+1 blocks have been transferred from client to server and N2+1
blocks have been transferred from server to client.
Authors' Addresses Authors' Addresses
Peter van der Stok Peter van der Stok
Consultant Consultant
Email: consultancy@vanderstok.org Email: consultancy@vanderstok.org
Panos Kampanakis Panos Kampanakis
Cisco Systems Cisco Systems
 End of changes. 41 change blocks. 
148 lines changed or deleted 334 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/