draft-ietf-core-object-security-08.txt   draft-ietf-core-object-security-09.txt 
CoRE Working Group G. Selander CoRE Working Group G. Selander
Internet-Draft J. Mattsson Internet-Draft J. Mattsson
Intended status: Standards Track F. Palombini Intended status: Standards Track F. Palombini
Expires: July 26, 2018 Ericsson AB Expires: September 6, 2018 Ericsson AB
L. Seitz L. Seitz
RISE SICS RISE SICS
January 22, 2018 March 05, 2018
Object Security for Constrained RESTful Environments (OSCORE) Object Security for Constrained RESTful Environments (OSCORE)
draft-ietf-core-object-security-08 draft-ietf-core-object-security-09
Abstract Abstract
This document defines Object Security for Constrained RESTful This document defines Object Security for Constrained RESTful
Environments (OSCORE), a method for application-layer protection of Environments (OSCORE), a method for application-layer protection of
the Constrained Application Protocol (CoAP), using CBOR Object the Constrained Application Protocol (CoAP), using CBOR Object
Signing and Encryption (COSE). OSCORE provides end-to-end protection Signing and Encryption (COSE). OSCORE provides end-to-end protection
between endpoints communicating using CoAP or CoAP-mappable HTTP. between endpoints communicating using CoAP or CoAP-mappable HTTP.
OSCORE is designed for constrained nodes and networks supporting a OSCORE is designed for constrained nodes and networks supporting a
range of proxy operations, including translation between different range of proxy operations, including translation between different
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 July 26, 2018. This Internet-Draft will expire on September 6, 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 30 skipping to change at page 2, line 30
4. Protected Message Fields . . . . . . . . . . . . . . . . . . 12 4. Protected Message Fields . . . . . . . . . . . . . . . . . . 12
4.1. CoAP Payload . . . . . . . . . . . . . . . . . . . . . . 13 4.1. CoAP Payload . . . . . . . . . . . . . . . . . . . . . . 13
4.2. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14 4.2. CoAP Options . . . . . . . . . . . . . . . . . . . . . . 14
4.3. CoAP Header . . . . . . . . . . . . . . . . . . . . . . . 20 4.3. CoAP Header . . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Signaling Messages . . . . . . . . . . . . . . . . . . . 21 4.4. Signaling Messages . . . . . . . . . . . . . . . . . . . 21
5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 22 5. The COSE Object . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 23 5.1. Kid Context . . . . . . . . . . . . . . . . . . . . . . . 23
5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Nonce . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3. Plaintext . . . . . . . . . . . . . . . . . . . . . . . . 24
5.4. Additional Authenticated Data . . . . . . . . . . . . . . 25 5.4. Additional Authenticated Data . . . . . . . . . . . . . . 25
6. OSCORE Compression . . . . . . . . . . . . . . . . . . . . . 26 6. OSCORE Header Compression . . . . . . . . . . . . . . . . . . 26
6.1. Encoding of the Object-Security Value . . . . . . . . . . 26 6.1. Encoding of the Object-Security Value . . . . . . . . . . 26
6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 27 6.2. Encoding of the OSCORE Payload . . . . . . . . . . . . . 27
6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 28 6.3. Examples of Compressed COSE Objects . . . . . . . . . . . 28
7. Sequence Numbers, Replay, Message Binding, and Freshness . . 29 7. Sequence Numbers, Replay, Message Binding, and Freshness . . 29
7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 29 7.1. Message Binding . . . . . . . . . . . . . . . . . . . . . 29
7.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 29 7.2. AEAD Nonce Uniqueness . . . . . . . . . . . . . . . . . . 29
7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 30 7.3. Freshness . . . . . . . . . . . . . . . . . . . . . . . . 30
7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30 7.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 30
7.5. Losing Part of the Context State . . . . . . . . . . . . 31 7.5. Losing Part of the Context State . . . . . . . . . . . . 31
8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Processing . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Protecting the Request . . . . . . . . . . . . . . . . . 32 8.1. Protecting the Request . . . . . . . . . . . . . . . . . 32
8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 33 8.2. Verifying the Request . . . . . . . . . . . . . . . . . . 33
8.3. Protecting the Response . . . . . . . . . . . . . . . . . 34 8.3. Protecting the Response . . . . . . . . . . . . . . . . . 34
8.4. Verifying the Response . . . . . . . . . . . . . . . . . 35 8.4. Verifying the Response . . . . . . . . . . . . . . . . . 35
9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 36 9. Web Linking . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Proxy and HTTP Operations . . . . . . . . . . . . . . . . . . 36 10. Proxy and HTTP Operations . . . . . . . . . . . . . . . . . . 37
10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 37 10.1. CoAP-to-CoAP Forwarding Proxy . . . . . . . . . . . . . 37
10.2. HTTP Processing . . . . . . . . . . . . . . . . . . . . 37 10.2. HTTP Processing . . . . . . . . . . . . . . . . . . . . 37
10.3. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 38 10.3. HTTP-to-CoAP Translation Proxy . . . . . . . . . . . . . 39
10.4. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 40 10.4. CoAP-to-HTTP Translation Proxy . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
11.1. End-to-end protection . . . . . . . . . . . . . . . . . 41 11.1. End-to-end protection . . . . . . . . . . . . . . . . . 42
11.2. Security Context Establishment . . . . . . . . . . . . . 42 11.2. Security Context Establishment . . . . . . . . . . . . . 42
11.3. Replay Protection . . . . . . . . . . . . . . . . . . . 42 11.3. Replay Protection . . . . . . . . . . . . . . . . . . . 43
11.4. Cryptographic Considerations . . . . . . . . . . . . . . 42 11.4. Cryptographic Considerations . . . . . . . . . . . . . . 43
11.5. Message Fragmentation . . . . . . . . . . . . . . . . . 43 11.5. Message Fragmentation . . . . . . . . . . . . . . . . . 43
11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 43 11.6. Privacy Considerations . . . . . . . . . . . . . . . . . 44
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
12.1. COSE Header Parameters Registry . . . . . . . . . . . . 44 12.1. COSE Header Parameters Registry . . . . . . . . . . . . 45
12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 44 12.2. CoAP Option Numbers Registry . . . . . . . . . . . . . . 45
12.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 45 12.3. CoAP Signaling Option Numbers Registry . . . . . . . . . 45
12.4. Header Field Registrations . . . . . . . . . . . . . . . 45 12.4. Header Field Registrations . . . . . . . . . . . . . . . 46
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 12.5. Media Type Registrations . . . . . . . . . . . . . . . . 46
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 48
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.1. Normative References . . . . . . . . . . . . . . . . . . 48
Appendix A. Scenario examples . . . . . . . . . . . . . . . . . 48 13.2. Informative References . . . . . . . . . . . . . . . . . 49
A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 48 Appendix A. Scenario examples . . . . . . . . . . . . . . . . . 51
A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 49 A.1. Secure Access to Sensor . . . . . . . . . . . . . . . . . 51
Appendix B. Deployment examples . . . . . . . . . . . . . . . . 51 A.2. Secure Subscribe to Sensor . . . . . . . . . . . . . . . 52
B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 51 Appendix B. Deployment examples . . . . . . . . . . . . . . . . 54
B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 51 B.1. Master Secret Used Once . . . . . . . . . . . . . . . . . 54
B.3. Client Aliveness . . . . . . . . . . . . . . . . . . . . 51 B.2. Master Secret Used Multiple Times . . . . . . . . . . . . 54
Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 52 B.3. Client Aliveness . . . . . . . . . . . . . . . . . . . . 55
C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 52 Appendix C. Test Vectors . . . . . . . . . . . . . . . . . . . . 56
C.2. Test Vector 2: Key Derivation without Master Salt . . . . 53 C.1. Test Vector 1: Key Derivation with Master Salt . . . . . 56
C.3. Test Vector 3: OSCORE Request, Client . . . . . . . . . . 54 C.2. Test Vector 2: Key Derivation without Master Salt . . . . 57
C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 55 C.3. Test Vector 3: OSCORE Request, Client . . . . . . . . . . 58
C.5. Test Vector 5: OSCORE Response, Server . . . . . . . . . 57 C.4. Test Vector 4: OSCORE Request, Client . . . . . . . . . . 59
C.6. Test Vector 6: OSCORE Response with Partial IV, Server . 58 C.5. Test Vector 5: OSCORE Response, Server . . . . . . . . . 60
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 59 C.6. Test Vector 6: OSCORE Response with Partial IV, Server . 61
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Appendix D. CDDL Summary . . . . . . . . . . . . . . . . . . . . 63
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a web The Constrained Application Protocol (CoAP) [RFC7252] is a web
application protocol, designed for constrained nodes and networks application protocol, designed for constrained nodes and networks
[RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the [RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the
use of proxies for scalability and efficiency and references DTLS use of proxies for scalability and efficiency and references DTLS
([RFC6347]) for security. CoAP and HTTP proxies require (D)TLS to be ([RFC6347]) for security. CoAP and HTTP proxies require (D)TLS to be
terminated at the proxy. The proxy therefore not only has access to terminated at the proxy. The proxy therefore not only has access to
the data required for performing the intended proxy functionality, the data required for performing the intended proxy functionality,
skipping to change at page 4, line 17 skipping to change at page 4, line 21
[RFC7641], Blockwise [RFC7959], No-Response [RFC7967], and PATCH and [RFC7641], Blockwise [RFC7959], No-Response [RFC7967], and PATCH and
FETCH [RFC8132]. An analysis of end-to-end security for CoAP FETCH [RFC8132]. An analysis of end-to-end security for CoAP
messages through some types of intermediary nodes is performed in messages through some types of intermediary nodes is performed in
[I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the [I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the
RESTful interactions; the request method, the requested resource, the RESTful interactions; the request method, the requested resource, the
message payload, etc. (see Section 4). OSCORE does neither protect message payload, etc. (see Section 4). OSCORE does neither protect
the CoAP Messaging Layer nor the CoAP Token which may change between the CoAP Messaging Layer nor the CoAP Token which may change between
the endpoints, and those are therefore processed as defined in the endpoints, and those are therefore processed as defined in
[RFC7252]. Additionally, since the message formats for CoAP over [RFC7252]. Additionally, since the message formats for CoAP over
unreliable transport [RFC7252] and for CoAP over reliable transport unreliable transport [RFC7252] and for CoAP over reliable transport
[I-D.ietf-core-coap-tcp-tls] differ only in terms of CoAP Messaging [RFC8323] differ only in terms of CoAP Messaging Layer, OSCORE can be
Layer, OSCORE can be applied to both unreliable and reliable applied to both unreliable and reliable transports (see Figure 1).
transports (see Figure 1).
+-----------------------------------+ +-----------------------------------+
| Application | | Application |
+-----------------------------------+ +-----------------------------------+
+-----------------------------------+ \ +-----------------------------------+ \
| Requests / Responses / Signaling | | | Requests / Responses / Signaling | |
|-----------------------------------| | |-----------------------------------| |
| OSCORE | | CoAP | OSCORE | | CoAP
|-----------------------------------| | |-----------------------------------| |
| Messaging Layer / Message Framing | | | Messaging Layer / Message Framing | |
skipping to change at page 6, line 15 skipping to change at page 6, line 15
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. These document are to be interpreted as described in [RFC2119]. These
words may also appear in this document in lowercase, absent their words may also appear in this document in lowercase, absent their
normative meanings. normative meanings.
Readers are expected to be familiar with the terms and concepts Readers are expected to be familiar with the terms and concepts
described in CoAP [RFC7252], Observe [RFC7641], Blockwise [RFC7959], described in CoAP [RFC7252], Observe [RFC7641], Blockwise [RFC7959],
COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl], and COSE [RFC8152], CBOR [RFC7049], CDDL [I-D.ietf-cbor-cddl] as
constrained environments [RFC7228]. summarized in Appendix D, and constrained environments [RFC7228].
The term "hop" is used to denote a particular leg in the end-to-end The term "hop" is used to denote a particular leg in the end-to-end
path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or path. The concept "hop-by-hop" (as in "hop-by-hop encryption" or
"hop-by-hop fragmentation") opposed to "end-to-end", is used in this "hop-by-hop fragmentation") opposed to "end-to-end", is used in this
document to indicate that the messages are processed accordingly in document to indicate that the messages are processed accordingly in
the intermediaries, rather than just forwarded to the next node. the intermediaries, rather than just forwarded to the next node.
The term "stop processing" is used throughout the document to denote The term "stop processing" is used throughout the document to denote
that the message is not passed up to the CoAP Request/Response layer that the message is not passed up to the CoAP Request/Response layer
(see Figure 1). (see Figure 1).
skipping to change at page 7, line 24 skipping to change at page 7, line 24
Security option, since the response is only applicable to the Security option, since the response is only applicable to the
original request (see Section 10.1). As the compressed COSE Object original request (see Section 10.1). As the compressed COSE Object
is included in the cache key, messages with the Object-Security is included in the cache key, messages with the Object-Security
option will never generate cache hits. For Max-Age processing (see option will never generate cache hits. For Max-Age processing (see
Section 4.2.3.1). Section 4.2.3.1).
3. The Security Context 3. The Security Context
OSCORE requires that client and server establish a shared security OSCORE requires that client and server establish a shared security
context used to process the COSE objects. OSCORE uses COSE with an context used to process the COSE objects. OSCORE uses COSE with an
Authenticated Encryption with Additional Data (AEAD) algorithm for Authenticated Encryption with Additional Data (AEAD, [RFC5116])
protecting message data between a client and a server. In this algorithm for protecting message data between a client and a server.
section, we define the security context and how it is derived in In this section, we define the security context and how it is derived
client and server based on a shared secret and a key derivation in client and server based on a shared secret and a key derivation
function (KDF). function (KDF).
3.1. Security Context Definition 3.1. Security Context Definition
The security context is the set of information elements necessary to The security context is the set of information elements necessary to
carry out the cryptographic operations in OSCORE. For each endpoint, carry out the cryptographic operations in OSCORE. For each endpoint,
the security context is composed of a "Common Context", a "Sender the security context is composed of a "Common Context", a "Sender
Context", and a "Recipient Context". Context", and a "Recipient Context".
The endpoints protect messages to send using the Sender Context and The endpoints protect messages to send using the Sender Context and
skipping to change at page 10, line 38 skipping to change at page 10, line 38
* Default is DTLS-type replay protection with a window size of 32 * Default is DTLS-type replay protection with a window size of 32
([RFC6347]) ([RFC6347])
All input parameters need to be known to and agreed on by both All input parameters need to be known to and agreed on by both
endpoints, but the replay window may be different in the two endpoints, but the replay window may be different in the two
endpoints. How the input parameters are pre-established, is endpoints. How the input parameters are pre-established, is
application specific. The OSCORE profile of the ACE framework may be application specific. The OSCORE profile of the ACE framework may be
used to establish the necessary input parameters used to establish the necessary input parameters
([I-D.ietf-ace-oscore-profile]), or a key exchange protocol such as ([I-D.ietf-ace-oscore-profile]), or a key exchange protocol such as
the TLS/DTLS handshake ([I-D.mattsson-ace-tls-oscore]) providing the TLS/DTLS handshake ([I-D.mattsson-ace-tls-oscore]) or EDHOC
forward secrecy. Other examples of deploying OSCORE are given in ([I-D.selander-ace-cose-ecdhe]) providing forward secrecy. Other
Appendix B. examples of deploying OSCORE are given in Appendix B.
3.2.1. Derivation of Sender Key, Recipient Key, and Common IV 3.2.1. Derivation of Sender Key, Recipient Key, and Common IV
The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms
defined in COSE. HKDF SHA-256 is mandatory to implement. The defined in COSE. HKDF SHA-256 is mandatory to implement. The
security context parameters Sender Key, Recipient Key, and Common IV security context parameters Sender Key, Recipient Key, and Common IV
SHALL be derived from the input parameters using the HKDF, which SHALL be derived from the input parameters using the HKDF, which
consists of the composition of the HKDF-Extract and HKDF-Expand steps consists of the composition of the HKDF-Extract and HKDF-Expand steps
([RFC5869]): ([RFC5869]):
skipping to change at page 12, line 14 skipping to change at page 12, line 14
Sender IDs can be very short. The maximum length of Sender ID in Sender IDs can be very short. The maximum length of Sender ID in
bytes equals the length of AEAD nonce minus 6. For AES-CCM-16-64-128 bytes equals the length of AEAD nonce minus 6. For AES-CCM-16-64-128
the maximum length of Sender ID is 7 bytes. Sender IDs MAY be the maximum length of Sender ID is 7 bytes. Sender IDs MAY be
uniformly random distributed byte strings if the probability of uniformly random distributed byte strings if the probability of
collisions is negligible. collisions is negligible.
If Sender ID uniqueness cannot be guaranteed by construction, Sender If Sender ID uniqueness cannot be guaranteed by construction, Sender
IDs MUST be long uniformly random distributed byte strings such that IDs MUST be long uniformly random distributed byte strings such that
the probability of collisions is negligible. the probability of collisions is negligible.
To enable retrieval of the right Recipient Context, the Recipient ID To simplify retrieval of the right Recipient Context, the Recipient
SHOULD be unique in the sets of all Recipient Contexts used by an ID SHOULD be unique in the sets of all Recipient Contexts used by an
endpoint. The Client MAY provide a 'kid context' parameter endpoint. If an endpoint has the same Recipient ID with different
Recipient Contexts, i.e. the Recipient Contexts are derived from
different keying material, then the endpoint may need to try multiple
times before finding the right security context associated to the
Recipient ID. The Client MAY provide a 'kid context' parameter
(Section 5.1) to help the Server find the right context. (Section 5.1) to help the Server find the right context.
While the triple (Master Secret, Master Salt, Sender ID) MUST be While the triple (Master Secret, Master Salt, Sender ID) MUST be
unique, the same Master Salt MAY be used with several Master Secrets unique, the same Master Salt MAY be used with several Master Secrets
and the same Master Secret MAY be used with several Master Salts. and the same Master Secret MAY be used with several Master Salts.
4. Protected Message Fields 4. Protected Message Fields
OSCORE transforms a CoAP message (which may have been generated from OSCORE transforms a CoAP message (which may have been generated from
an HTTP message) into an OSCORE message, and vice versa. OSCORE an HTTP message) into an OSCORE message, and vice versa. OSCORE
skipping to change at page 12, line 42 skipping to change at page 12, line 46
The remainder of this section and later sections discuss the behavior The remainder of this section and later sections discuss the behavior
in terms of CoAP messages. If HTTP is used for a particular hop in in terms of CoAP messages. If HTTP is used for a particular hop in
the end-to-end path, then this section applies to the conceptual CoAP the end-to-end path, then this section applies to the conceptual CoAP
message that is mappable to/from the original HTTP message as message that is mappable to/from the original HTTP message as
discussed in Section 10. That is, an HTTP message is conceptually discussed in Section 10. That is, an HTTP message is conceptually
transformed to a CoAP message and then to an OSCORE message, and transformed to a CoAP message and then to an OSCORE message, and
similarly in the reverse direction. An actual implementation might similarly in the reverse direction. An actual implementation might
translate directly from HTTP to OSCORE without the intervening CoAP translate directly from HTTP to OSCORE without the intervening CoAP
representation. representation.
Protection of Signaling messages (Section 5 of Protection of Signaling messages (Section 5 of [RFC8323]) is
[I-D.ietf-core-coap-tcp-tls]) is specified in Section 4.4. The other specified in Section 4.4. The other parts of this section target
parts of this section target Request/Response messages. Request/Response messages.
Message fields of the CoAP message may be protected end-to-end Message fields of the CoAP message may be protected end-to-end
between CoAP client and CoAP server in different ways: between CoAP client and CoAP server in different ways:
o Class E: encrypted and integrity protected, o Class E: encrypted and integrity protected,
o Class I: integrity protected only, or o Class I: integrity protected only, or
o Class U: unprotected. o Class U: unprotected.
The sending endpoint SHALL transfer Class E message fields in the The sending endpoint SHALL transfer Class E message fields in the
ciphertext of the COSE object in the OSCORE message. The sending ciphertext of the COSE object in the OSCORE message. The sending
endpoint SHALL include Class I message fields in the Additional endpoint SHALL include Class I message fields in the Additional
Authenticated Data (AAD) of the AEAD algorithm, allowing the Authenticated Data (AAD) of the AEAD algorithm, allowing the
receiving endpoint to detect if the value has changed in transfer. receiving endpoint to detect if the value has changed in transfer.
Class U message fields SHALL NOT be protected in transfer. Class I Class U message fields SHALL NOT be protected in transfer. Class I
and Class U message field values are transferred in the header or and Class U message field values are transferred in the header or
options part of the OSCORE message, which is visible to proxies. options part of the OSCORE message, which is visible to proxies.
skipping to change at page 21, line 28 skipping to change at page 21, line 28
The other CoAP Header fields are Unprotected (Class U). The sending The other CoAP Header fields are Unprotected (Class U). The sending
endpoint SHALL write all other header fields of the original message endpoint SHALL write all other header fields of the original message
into the header of the OSCORE message. The receiving endpoint SHALL into the header of the OSCORE message. The receiving endpoint SHALL
write the header fields from the received OSCORE message into the write the header fields from the received OSCORE message into the
header of the decrypted CoAP message. header of the decrypted CoAP message.
4.4. Signaling Messages 4.4. Signaling Messages
Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange Signaling messages (CoAP Code 7.00-7.31) were introduced to exchange
information related to an underlying transport connection in the information related to an underlying transport connection in the
specific case of CoAP over reliable transports specific case of CoAP over reliable transports ([RFC8323]). The use
([I-D.ietf-core-coap-tcp-tls]). The use of OSCORE for protecting of OSCORE for protecting Signaling is application dependent.
Signaling is application dependent.
OSCORE MAY be used to protect Signaling if the endpoints for OSCORE OSCORE MAY be used to protect Signaling if the endpoints for OSCORE
coincide with the endpoints for the connection. If OSCORE is used to coincide with the endpoints for the connection. If OSCORE is used to
protect Signaling then: protect Signaling then:
o Signaling messages SHALL be protected as CoAP Request messages, o Signaling messages SHALL be protected as CoAP Request messages,
except in the case the Signaling message is a response to a except in the case the Signaling message is a response to a
previous Signaling message, in which case it SHALL be protected as previous Signaling message, in which case it SHALL be protected as
a CoAP Response message. For example, 7.02 (Ping) is protected as a CoAP Response message. For example, 7.02 (Ping) is protected as
a CoAP Request and 7.03 (Pong) as a CoAP response. a CoAP Request and 7.03 (Pong) as a CoAP response.
o The Outer Code for Signaling messages SHALL be set to 0.02 (POST), o The Outer Code for Signaling messages SHALL be set to 0.02 (POST),
unless it is a response to a previous Signaling message, in which unless it is a response to a previous Signaling message, in which
case it SHALL be set to 2.04 (Changed). case it SHALL be set to 2.04 (Changed).
o All Signaling options, except the Object-Security option, SHALL be o All Signaling options, except the Object-Security option, SHALL be
Inner (Class E). Inner (Class E).
NOTE: Option numbers for Signaling messages are specific to the CoAP NOTE: Option numbers for Signaling messages are specific to the CoAP
Code (see Section 5.2 of [I-D.ietf-core-coap-tcp-tls]). Code (see Section 5.2 of [RFC8323]).
If OSCORE is not used to protect Signaling, Signaling messages SHALL If OSCORE is not used to protect Signaling, Signaling messages SHALL
be unaltered by OSCORE. be unaltered by OSCORE.
5. The COSE Object 5. The COSE Object
This section defines how to use COSE [RFC8152] to wrap and protect This section defines how to use COSE [RFC8152] to wrap and protect
data in the original message. OSCORE uses the untagged COSE_Encrypt0 data in the original message. OSCORE uses the untagged COSE_Encrypt0
structure with an Authenticated Encryption with Additional Data structure with an Authenticated Encryption with Additional Data
(AEAD) algorithm. The key lengths, IV length, nonce length, and (AEAD) algorithm. The key lengths, IV length, nonce length, and
skipping to change at page 23, line 14 skipping to change at page 23, line 11
o The 'ciphertext' field is computed from the secret key (Sender Key o The 'ciphertext' field is computed from the secret key (Sender Key
or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see or Recipient Key), AEAD nonce (see Section 5.2), plaintext (see
Section 5.3), and the Additional Authenticated Data (AAD) (see Section 5.3), and the Additional Authenticated Data (AAD) (see
Section 5.4) following Section 5.2 of [RFC8152]. Section 5.4) following Section 5.2 of [RFC8152].
The encryption process is described in Section 5.3 of [RFC8152]. The encryption process is described in Section 5.3 of [RFC8152].
5.1. Kid Context 5.1. Kid Context
For certain use cases, e.g. deployments where the same 'kid' is used For certain use cases, e.g. deployments where the same kid is used
with multiple contexts, it is necessary or favorable for the sender with multiple contexts, it is necessary or favorable for the sender
to provide an additional identifier of the security material to use, to provide an additional identifier of the security material to use,
in order for the receiver to retrieve or establish the correct key. in order for the receiver to retrieve or establish the correct key.
The 'kid context' parameter is used to provide such additional input. The kid context parameter is used to provide such additional input.
The 'kid context' is implicitly integrity protected, as manipulation The kid context and kid are used to determine the security context,
or to establish the necessary input parameters to derive the security
context (see Section 3.2). The application defines how this is done.
The kid context is implicitly integrity protected, as manipulation
that leads to the wrong key (or no key) being retrieved which results that leads to the wrong key (or no key) being retrieved which results
in an error, as described in Section 8.2. in an error, as described in Section 8.2.
A summary of the COSE header parameter 'kid context' defined above A summary of the COSE header parameter kid context defined above can
can be found in Figure 8. be found in Figure 8.
Some examples of relevant uses of kid context are the following: Some examples of relevant uses of kid context are the following:
o If the client has an identifier in some other namespace which can o If the client has an identifier in some other namespace which can
be used by the server to retrieve or establish the security be used by the server to retrieve or establish the security
context, then that identifier can be used as kid context. The kid context, then that identifier can be used as kid context. The kid
context may be used as Master Salt (Section 3.1) for additional context may be used as Master Salt (Section 3.1) for additional
entropy of the security contexts (see for example entropy of the security contexts (see for example Appendix B.2 or
[I-D.ietf-6tisch-minimal-security]). [I-D.ietf-6tisch-minimal-security]).
o In case of a group communication scenario o In case of a group communication scenario
[I-D.tiloca-core-multicast-oscoap], if the server belongs to [I-D.tiloca-core-multicast-oscoap], if the server belongs to
multiple groups, then a group identifier can be used as kid multiple groups, then a group identifier can be used as kid
context to enable the server to find the right security context. context to enable the server to find the right security context.
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
| name | label | value type | value registry | description | | name | label | value type | value registry | description |
+----------+--------+------------+----------------+-----------------+ +----------+--------+------------+----------------+-----------------+
skipping to change at page 25, line 34 skipping to change at page 25, line 34
NOTE: The plaintext contains all CoAP data that needs to be encrypted NOTE: The plaintext contains all CoAP data that needs to be encrypted
end-to-end between the endpoints. end-to-end between the endpoints.
5.4. Additional Authenticated Data 5.4. Additional Authenticated Data
The external_aad SHALL be a CBOR array as defined below: The external_aad SHALL be a CBOR array as defined below:
external_aad = [ external_aad = [
oscore_version : uint, oscore_version : uint,
[alg_aead : int / tstr], algorithms : [ alg_aead : int / tstr ],
request_kid : bstr, request_kid : bstr,
request_piv : bstr, request_piv : bstr,
options : bstr options : bstr
] ]
where: where:
o oscore_version: contains the OSCORE version number. o oscore_version: contains the OSCORE version number.
Implementations of this specification MUST set this field to 1. Implementations of this specification MUST set this field to 1.
Other values are reserved for future versions. Other values are reserved for future versions.
skipping to change at page 26, line 17 skipping to change at page 26, line 17
o options: contains the Class I options (see Section 4.2.2) present o options: contains the Class I options (see Section 4.2.2) present
in the original CoAP message encoded as described in Section 3.1 in the original CoAP message encoded as described in Section 3.1
of [RFC7252], where the delta is the difference to the previously of [RFC7252], where the delta is the difference to the previously
included class I option. included class I option.
NOTE: The format of the external_aad is for simplicity the same for NOTE: The format of the external_aad is for simplicity the same for
requests and responses, although some parameters, e.g. request_kid requests and responses, although some parameters, e.g. request_kid
need not be integrity protected in the requests. need not be integrity protected in the requests.
6. OSCORE Compression 6. OSCORE Header Compression
The Concise Binary Object Representation (CBOR) [RFC7049] combines The Concise Binary Object Representation (CBOR) [RFC7049] combines
very small message sizes with extensibility. The CBOR Object Signing very small message sizes with extensibility. The CBOR Object Signing
and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding and Encryption (COSE) [RFC8152] uses CBOR to create compact encoding
of signed and encrypted data. COSE is however constructed to support of signed and encrypted data. COSE is however constructed to support
a large number of different stateless use cases, and is not fully a large number of different stateless use cases, and is not fully
optimized for use as a stateful security protocol, leading to a optimized for use as a stateful security protocol, leading to a
larger than necessary message expansion. In this section, we define larger than necessary message expansion. In this section, we define
a stateless compression mechanism, simply removing redundant a stateless header compression mechanism, simply removing redundant
information from the COSE objects, which significantly reduces the information from the COSE objects, which significantly reduces the
per-packet overhead. The result of applying this mechanism to a COSE per-packet overhead. The result of applying this mechanism to a COSE
object is called the "compressed COSE object". object is called the "compressed COSE object".
The COSE_Encrypt0 object used in OSCORE is transported in the Object-
Security option and in the Payload. The Payload contains the
Ciphertext and the headers of the COSE object are compactly encoded
as described in the next section.
6.1. Encoding of the Object-Security Value 6.1. Encoding of the Object-Security Value
The value of the Object-Security option SHALL contain the OSCORE flag The value of the Object-Security option SHALL contain the OSCORE flag
bits, the Partial IV parameter, the kid context parameter (length and bits, the Partial IV parameter, the kid context parameter (length and
value), and the kid parameter as follows: value), and the kid parameter as follows:
0 1 2 3 4 5 6 7 <--------- n bytes -------------> 0 1 2 3 4 5 6 7 <--------- n bytes ------------->
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
|0 0 0|h|k| n | Partial IV (if any) ... |0 0 0|h|k| n | Partial IV (if any) ...
+-+-+-+-+-+-+-+-+--------------------------------- +-+-+-+-+-+-+-+-+---------------------------------
skipping to change at page 34, line 8 skipping to change at page 34, line 8
4. Verify the 'Partial IV' parameter using the Replay Window, as 4. Verify the 'Partial IV' parameter using the Replay Window, as
described in Section 7.4. described in Section 7.4.
5. Compose the Additional Authenticated Data, as described in 5. Compose the Additional Authenticated Data, as described in
Section 5.4. Section 5.4.
6. Compute the AEAD nonce from the Recipient ID, Common IV, and the 6. Compute the AEAD nonce from the Recipient ID, Common IV, and the
'Partial IV' parameter, received in the COSE Object. 'Partial IV' parameter, received in the COSE Object.
7. Decrypt the COSE object using the Recipient Key. 7. Decrypt the COSE object using the Recipient Key, as per
[RFC8152] Section 5.3. (The decrypt operation includes the
verification of the integrity.)
* If decryption fails, the server MUST stop processing the * If decryption fails, the server MUST stop processing the
request and MAY respond with a 4.00 Bad Request error request and MAY respond with a 4.00 Bad Request error
message. The server MAY set an Outer Max-Age option with message. The server MAY set an Outer Max-Age option with
value zero. The diagnostic payload SHOULD contain the value zero. The diagnostic payload SHOULD contain the
"Decryption failed" string. "Decryption failed" string.
* If decryption succeeds, update the Replay Window, as * If decryption succeeds, update the Replay Window, as
described in Section 7. described in Section 7.
skipping to change at page 35, line 6 skipping to change at page 35, line 6
described in Section 5.4 and Section 5.3. described in Section 5.4 and Section 5.3.
3. Compute the AEAD nonce 3. Compute the AEAD nonce
* If Observe is used, compute the nonce from the Sender ID, * If Observe is used, compute the nonce from the Sender ID,
Common IV, and Partial IV (Sender Sequence Number in network Common IV, and Partial IV (Sender Sequence Number in network
byte order). Then (in one atomic operation, see Section 7.2) byte order). Then (in one atomic operation, see Section 7.2)
increment the Sender Sequence Number by one. increment the Sender Sequence Number by one.
* If Observe is not used, either the nonce from the request is * If Observe is not used, either the nonce from the request is
used or a new Partial IV is used. used or a new Partial IV is used (see bullet on 'Partial IV'
in Section 5).
4. Encrypt the COSE object using the Sender Key. Compress the COSE 4. Encrypt the COSE object using the Sender Key. Compress the COSE
Object as specified in Section 6. If the AEAD nonce was Object as specified in Section 6. If the AEAD nonce was
constructed from a new Partial IV, this Partial IV MUST be constructed from a new Partial IV, this Partial IV MUST be
included in the message. If the AEAD nonce from the request was included in the message. If the AEAD nonce from the request was
used, the Partial IV MUST NOT be included in the message. used, the Partial IV MUST NOT be included in the message.
5. Format the OSCORE message according to Section 4. The Object- 5. Format the OSCORE message according to Section 4. The Object-
Security option is added (see Section 4.2.2). Security option is added (see Section 4.2.2).
skipping to change at page 36, line 9 skipping to change at page 36, line 9
1. If the Observe option and the Partial IV are not present in 1. If the Observe option and the Partial IV are not present in
the response, the nonce from the request is used. the response, the nonce from the request is used.
2. If the Observe option is present in the response, and the 2. If the Observe option is present in the response, and the
Partial IV is not present in the response, then go to 11. Partial IV is not present in the response, then go to 11.
3. If the Partial IV is present in the response, compute the 3. If the Partial IV is present in the response, compute the
nonce from the Recipient ID, Common IV, and the 'Partial IV' nonce from the Recipient ID, Common IV, and the 'Partial IV'
parameter, received in the COSE Object. parameter, received in the COSE Object.
7. Decrypt the COSE object using the Recipient Key. 7. Decrypt the COSE object using the Recipient Key, as per
[RFC8152] Section 5.3. (The decrypt operation includes the
verification of the integrity.)
* If decryption fails, then go to 11. * If decryption fails, then go to 11.
* If decryption succeeds and Observe is used, update the * If decryption succeeds and Observe is used, update the
corresponding Notification Number, as described in Section 7. corresponding Notification Number, as described in Section 7.
8. For each decrypted option, check if the option is also present 8. For each decrypted option, check if the option is also present
as an Outer option: if it is, discard the Outer. For example: as an Outer option: if it is, discard the Outer. For example:
the message contains a Max-Age Inner and a Max-Age Outer option. the message contains a Max-Age Inner and a Max-Age Outer option.
The Outer Max-Age is discarded. The Outer Max-Age is discarded.
skipping to change at page 37, line 26 skipping to change at page 37, line 32
and CoAP-mappable HTTP. In particular caching is disabled since the and CoAP-mappable HTTP. In particular caching is disabled since the
CoAP response is only applicable to the original CoAP request. An CoAP response is only applicable to the original CoAP request. An
OSCORE-aware proxy SHALL NOT cache a response to a request with an OSCORE-aware proxy SHALL NOT cache a response to a request with an
Object-Security option. As a consequence, the search for cache hits Object-Security option. As a consequence, the search for cache hits
and CoAP freshness/Max-Age processing can be omitted. and CoAP freshness/Max-Age processing can be omitted.
Proxy processing of the (Outer) Proxy-Uri option is as defined in Proxy processing of the (Outer) Proxy-Uri option is as defined in
[RFC7252]. [RFC7252].
Proxy processing of the (Outer) Block options is as defined in Proxy processing of the (Outer) Block options is as defined in
[RFC7959] and [I-D.ietf-core-echo-request-tag]. [RFC7959].
Proxy processing of the (Outer) Observe option is as defined in Proxy processing of the (Outer) Observe option is as defined in
[RFC7641]. OSCORE-aware proxies MAY look at the Partial IV value [RFC7641]. OSCORE-aware proxies MAY look at the Partial IV value
instead of the Outer Observe option. instead of the Outer Observe option.
10.2. HTTP Processing 10.2. HTTP Processing
In order to use OSCORE with HTTP, an endpoint needs to be able to map In order to use OSCORE with HTTP, an endpoint needs to be able to map
HTTP messages to CoAP messages (see [RFC8075]), and to apply OSCORE HTTP messages to CoAP messages (see [RFC8075]), and to apply OSCORE
to CoAP messages (as defined in this document). to CoAP messages (as defined in this document).
For this purpose, this specification defines a new HTTP header field
named CoAP-Object-Security, see Section 12.4. The CoAP-Object-
Security header field is only used in POST requests and 200 (OK)
responses. All field semantics is given within the CoAP-Object-
Security header field. The header field is neither appropriate to
list in the Connection header field (see Section 6.1 of [RFC7230]),
nor in a Vary response header field (see Section 7.1.4 of [RFC7231]),
nor allowed in trailers (see Section 4.1 of [RFC7230]).
Intermediaries are not allowed to insert, delete, or modify the
field's value. The header field is not preserved across redirects.
A sending endpoint uses [RFC8075] to translate an HTTP message into a A sending endpoint uses [RFC8075] to translate an HTTP message into a
CoAP message. It then protects the message with OSCORE processing, CoAP message. It then protects the message with OSCORE processing,
and add the Object-Security option (as defined in this document). and add the Object-Security option (as defined in this document).
Then, the endpoint maps the resulting CoAP message to an HTTP message Then, the endpoint maps the resulting CoAP message to an HTTP message
that includes an HTTP header field named Object-Security, whose value that includes the HTTP header field CoAP-Object-Security, whose value
is: is:
o "" (empty string) if the CoAP Object-Security option is empty, or o "" (empty string) if the CoAP Object-Security option is empty, or
o the value of the CoAP Object-Security option (Section 6.1) in o the value of the CoAP Object-Security option (Section 6.1) in
base64url encoding (Section 5 of [RFC4648]) without padding (see base64url encoding (Section 5 of [RFC4648]) without padding (see
[RFC7515] Appendix C for implementation notes for this encoding). [RFC7515] Appendix C for implementation notes for this encoding).
Note that the value of the HTTP body is the CoAP payload, i.e. the Note that the value of the HTTP body is the CoAP payload, i.e. the
OSCORE payload (Section 6.2). OSCORE payload (Section 6.2).
The HTTP header field Content-Type is set to 'application/oscore'
(see Section 12.5).
The resulting message is an OSCORE message that uses HTTP. The resulting message is an OSCORE message that uses HTTP.
A receiving endpoint uses [RFC8075] to translate an HTTP message into A receiving endpoint uses [RFC8075] to translate an HTTP message into
a CoAP message, with the following addition. The HTTP message a CoAP message, with the following addition. The HTTP message
includes the Object-Security header field, which is mapped to the includes the CoAP-Object-Security header field, which is mapped to
CoAP Object-Security option in the following way. The CoAP Object- the CoAP Object-Security option in the following way. The CoAP
Security option value is: Object-Security option value is:
o empty if the value of the HTTP Object-Security header field is "" o empty if the value of the HTTP CoAP-Object-Security header field
(empty string) is "" (empty string)
o the value of the HTTP Object-Security header field decoded from o the value of the HTTP CoAP-Object-Security header field decoded
base64url (Section 5 of [RFC4648]) without padding (see [RFC7515] from base64url (Section 5 of [RFC4648]) without padding (see
Appendix C for implementation notes for this decoding). [RFC7515] Appendix C for implementation notes for this decoding).
Note that the value of the CoAP payload is the HTTP body, i.e. the Note that the value of the CoAP payload is the HTTP body, i.e. the
OSCORE payload (Section 6.2). OSCORE payload (Section 6.2).
The resulting message is an OSCORE message that uses CoAP. The resulting message is an OSCORE message that uses CoAP.
The endpoint can then verify the message according to the OSCORE The endpoint can then verify the message according to the OSCORE
processing and get a verified CoAP message. It can then translate processing and get a verified CoAP message. It can then translate
the verified CoAP message into a verified HTTP message. the verified CoAP message into a verified HTTP message.
10.3. HTTP-to-CoAP Translation Proxy 10.3. HTTP-to-CoAP Translation Proxy
Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an Section 10.2 of [RFC7252] and [RFC8075] specify the behavior of an
HTTP-to-CoAP proxy. As requested in Section 1 of [RFC8075], this HTTP-to-CoAP proxy. As requested in Section 1 of [RFC8075], this
section describes the HTTP mapping for the OSCORE protocol extension section describes the HTTP mapping for the OSCORE protocol extension
of CoAP. of CoAP.
The presence of the Object-Security option, both in requests and The presence of the Object-Security option, both in requests and
responses, is expressed in an HTTP header field named Object-Security responses, is expressed in an HTTP header field named CoAP-Object-
in the mapped request or response. The value of the field is: Security in the mapped request or response. The value of the field
is:
o "" (empty string) if the CoAP Object-Security option is empty, or o "" (empty string) if the CoAP Object-Security option is empty, or
o the value of the CoAP Object-Security option (Section 6.1) in o the value of the CoAP Object-Security option (Section 6.1) in
base64url encoding (Section 5 of [RFC4648]) without padding (see base64url encoding (Section 5 of [RFC4648]) without padding (see
[RFC7515] Appendix C for implementation notes for this encoding). [RFC7515] Appendix C for implementation notes for this encoding).
The header field Content-Type 'application/oscore' (see Section 12.5)
is used for OSCORE messages transported in HTTP. The CoAP Content-
Format option is omitted for OSCORE messages transported in CoAP.
The value of the body is the OSCORE payload (Section 6.2). The value of the body is the OSCORE payload (Section 6.2).
Example: Example:
Mapping and notation here is based on "Simple Form" (Section 5.4.1.1 Mapping and notation here is based on "Simple Form" (Section 5.4.1.1
of [RFC8075]). of [RFC8075]).
[HTTP request -- Before client object security processing] [HTTP request -- Before client object security processing]
GET http://proxy.url/hc/?target_uri=coap://server.url/orders HTTP/1.1 GET http://proxy.url/hc/?target_uri=coap://server.url/orders HTTP/1.1
[HTTP request -- HTTP Client to Proxy] [HTTP request -- HTTP Client to Proxy]
POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1 POST http://proxy.url/hc/?target_uri=coap://server.url/ HTTP/1.1
Object-Security: 09 25 Content-Type: application/oscore
CoAP-Object-Security: 09 25
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- Proxy to CoAP Server] [CoAP request -- Proxy to CoAP Server]
POST coap://server.url/ POST coap://server.url/
Object-Security: 09 25 Object-Security: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[CoAP request -- After server object security processing] [CoAP request -- After server object security processing]
skipping to change at page 39, line 43 skipping to change at page 40, line 24
[CoAP response -- CoAP Server to Proxy] [CoAP response -- CoAP Server to Proxy]
2.04 Changed 2.04 Changed
Object-Security: [empty] Object-Security: [empty]
Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- Proxy to HTTP Client] [HTTP response -- Proxy to HTTP Client]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Object-Security: "" (empty string) Content-Type: application/oscore
CoAP-Object-Security: "" (empty string)
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[HTTP response -- After client object security processing] [HTTP response -- After client object security processing]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/plain Content-Type: text/plain
Body: Exterminate! Exterminate! Body: Exterminate! Exterminate!
Note that the HTTP Status Code 200 in the next-to-last message is the Note that the HTTP Status Code 200 in the next-to-last message is the
mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200 mapping of CoAP Code 2.04 (Changed), whereas the HTTP Status Code 200
skipping to change at page 40, line 35 skipping to change at page 41, line 15
[CoAP request -- CoAP Client to Proxy] [CoAP request -- CoAP Client to Proxy]
POST coap://proxy.url/ POST coap://proxy.url/
Proxy-Uri=http://server.url/ Proxy-Uri=http://server.url/
Object-Security: 09 25 Object-Security: 09 25
Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Payload: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- Proxy to HTTP Server] [HTTP request -- Proxy to HTTP Server]
POST http://server.url/ HTTP/1.1 POST http://server.url/ HTTP/1.1
Object-Security: 09 25 Content-Type: application/oscore
CoAP-Object-Security: 09 25
Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary] Body: 09 07 01 13 61 f7 0f d2 97 b1 [binary]
[HTTP request -- After server object security processing] [HTTP request -- After server object security processing]
GET http://server.url/orders HTTP/1.1 GET http://server.url/orders HTTP/1.1
[HTTP response -- Before server object security processing] [HTTP response -- Before server object security processing]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/plain Content-Type: text/plain
Body: Exterminate! Exterminate! Body: Exterminate! Exterminate!
[HTTP response -- HTTP Server to Proxy] [HTTP response -- HTTP Server to Proxy]
HTTP/1.1 200 OK HTTP/1.1 200 OK
Object-Security: "" (empty string) Content-Type: application/oscore
CoAP-Object-Security: "" (empty string)
Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Body: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response - Proxy to CoAP Client] [CoAP response - Proxy to CoAP Client]
2.04 Changed 2.04 Changed
Object-Security: [empty] Object-Security: [empty]
Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary] Payload: 00 31 d1 fc f6 70 fb 0c 1d d5 ... [binary]
[CoAP response -- After client object security processing] [CoAP response -- After client object security processing]
skipping to change at page 43, line 35 skipping to change at page 44, line 20
reduced by means of OSCORE. End-to-end integrity protection and reduced by means of OSCORE. End-to-end integrity protection and
encryption of the message payload and all options that are not used encryption of the message payload and all options that are not used
for proxy operations, provide mitigation against attacks on sensor for proxy operations, provide mitigation against attacks on sensor
and actuator communication, which may have a direct impact on the and actuator communication, which may have a direct impact on the
personal sphere. personal sphere.
The unprotected options (Figure 6) may reveal privacy sensitive The unprotected options (Figure 6) may reveal privacy sensitive
information. In particular Uri-Host SHOULD NOT contain privacy information. In particular Uri-Host SHOULD NOT contain privacy
sensitive information. CoAP headers sent in plaintext allow, for sensitive information. CoAP headers sent in plaintext allow, for
example, matching of CON and ACK (CoAP Message Identifier), matching example, matching of CON and ACK (CoAP Message Identifier), matching
of request and responses (Token) and traffic analysis. of request and responses (Token) and traffic analysis. OSCORE does
not provide protection for HTTP header fields which are not CoAP-
mappable.
Unprotected error messages reveal information about the security Unprotected error messages reveal information about the security
state in the communication between the endpoints. Unprotected state in the communication between the endpoints. Unprotected
signalling messages reveal information about the reliable transport signalling messages reveal information about the reliable transport
used on a leg of the path. Using the mechanisms described in used on a leg of the path. Using the mechanisms described in
Section 7.5 may reveal when a device goes through a reboot. This can Section 7.5 may reveal when a device goes through a reboot. This can
be mitigated by the device storing the precise state of sender be mitigated by the device storing the precise state of sender
sequence number and replay window on a clean shutdown. sequence number and replay window on a clean shutdown.
The length of message fields can reveal information about the The length of message fields can reveal information about the
skipping to change at page 45, line 18 skipping to change at page 46, line 7
Numbers registry: Numbers registry:
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
| 7.xx | TBD | Object-Security | [[this document]] | | 7.xx | TBD | Object-Security | [[this document]] |
+------------+--------+---------------------+-------------------+ +------------+--------+---------------------+-------------------+
12.4. Header Field Registrations 12.4. Header Field Registrations
The HTTP header field Object-Security is added to the Message Headers The HTTP header field CoAP-Object-Security is added to the Message
registry: Headers registry:
+-------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
| Object-Security | http | standard | [[this document]] | | CoAP-Object-Security | http | standard | [[this document]] |
+-------------------+----------+----------+-------------------+ +----------------------+----------+----------+-------------------+
12.5. Media Type Registrations
This section registers the 'application/oscore' media type in the
"Media Types" registry.
These media types are used to indicate that the content is an OSCORE
message.
Type name: application
Subtype name: oscore
Required parameters: N/A
Optional parameters: N/A
Encoding considerations: binary
Security considerations: See the Security Considerations section
of [[This document]].
Interoperability considerations: N/A
Published specification: [[This document]]
Applications that use this media type: IoT applications sending
security content over HTTP(S) transports.
Fragment identifier considerations: N/A
Additional information:
* Deprecated alias names for this type: N/A
* Magic number(s): N/A
* File extension(s): N/A
* Macintosh file type code(s): N/A
Person & email address to contact for further information:
iesg@ietf.org
Intended usage: COMMON
Restrictions on usage: N/A
Author: Goeran Selander, goran.selander@ericsson.com
Change Controller: IESG
Provisional registration? No
13. References 13. References
13.1. Normative References 13.1. Normative References
[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 45, line 48 skipping to change at page 48, line 26
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
skipping to change at page 46, line 34 skipping to change at page 49, line 24
<https://www.rfc-editor.org/info/rfc8132>. <https://www.rfc-editor.org/info/rfc8132>.
[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>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/info/rfc8323>.
13.2. Informative References 13.2. Informative References
[I-D.bormann-6lo-coap-802-15-ie] [I-D.bormann-6lo-coap-802-15-ie]
Bormann, C., "Constrained Application Protocol (CoAP) over Bormann, C., "Constrained Application Protocol (CoAP) over
IEEE 802.15.4 Information Element for IETF", draft- IEEE 802.15.4 Information Element for IETF", draft-
bormann-6lo-coap-802-15-ie-00 (work in progress), April bormann-6lo-coap-802-15-ie-00 (work in progress), April
2016. 2016.
[I-D.hartke-core-e2e-security-reqs] [I-D.hartke-core-e2e-security-reqs]
Selander, G., Palombini, F., and K. Hartke, "Requirements Selander, G., Palombini, F., and K. Hartke, "Requirements
skipping to change at page 47, line 9 skipping to change at page 50, line 9
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-04 (work in progress), October 6tisch-minimal-security-04 (work in progress), October
2017. 2017.
[I-D.ietf-ace-oauth-authz] [I-D.ietf-ace-oauth-authz]
Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and
H. Tschofenig, "Authentication and Authorization for H. Tschofenig, "Authentication and Authorization for
Constrained Environments (ACE)", draft-ietf-ace-oauth- Constrained Environments (ACE)", draft-ietf-ace-oauth-
authz-09 (work in progress), November 2017. authz-10 (work in progress), February 2018.
[I-D.ietf-ace-oscore-profile] [I-D.ietf-ace-oscore-profile]
Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE Seitz, L., Palombini, F., and M. Gunnarsson, "OSCORE
profile of the Authentication and Authorization for profile of the Authentication and Authorization for
Constrained Environments Framework", draft-ietf-ace- Constrained Environments Framework", draft-ietf-ace-
oscore-profile-00 (work in progress), December 2017. oscore-profile-00 (work in progress), December 2017.
[I-D.ietf-cbor-cddl] [I-D.ietf-cbor-cddl]
Birkholz, H., Vigano, C., and C. Bormann, "Concise data Birkholz, H., Vigano, C., and C. Bormann, "Concise data
definition language (CDDL): a notational convention to definition language (CDDL): a notational convention to
express CBOR data structures", draft-ietf-cbor-cddl-00 express CBOR data structures", draft-ietf-cbor-cddl-02
(work in progress), July 2017. (work in progress), February 2018.
[I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-11 (work in progress),
December 2017.
[I-D.ietf-core-echo-request-tag] [I-D.ietf-core-echo-request-tag]
Amsuess, C., Mattsson, J., and G. Selander, "Echo and Amsuess, C., Mattsson, J., and G. Selander, "Echo and
Request-Tag", draft-ietf-core-echo-request-tag-00 (work in Request-Tag", draft-ietf-core-echo-request-tag-00 (work in
progress), October 2017. progress), October 2017.
[I-D.mattsson-ace-tls-oscore] [I-D.mattsson-ace-tls-oscore]
Mattsson, J., "Using Transport Layer Security (TLS) to Mattsson, J., "Using Transport Layer Security (TLS) to
Secure OSCORE", draft-mattsson-ace-tls-oscore-00 (work in Secure OSCORE", draft-mattsson-ace-tls-oscore-00 (work in
progress), October 2017. progress), October 2017.
[I-D.mattsson-core-coap-actuators] [I-D.mattsson-core-coap-actuators]
Mattsson, J., Fornehed, J., Selander, G., Palombini, F., Mattsson, J., Fornehed, J., Selander, G., Palombini, F.,
and C. Amsuess, "Controlling Actuators with CoAP", draft- and C. Amsuess, "Controlling Actuators with CoAP", draft-
mattsson-core-coap-actuators-03 (work in progress), mattsson-core-coap-actuators-03 (work in progress),
October 2017. October 2017.
[I-D.selander-ace-cose-ecdhe]
Selander, G., Mattsson, J., and F. Palombini, "Ephemeral
Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace-
cose-ecdhe-07 (work in progress), July 2017.
[I-D.tiloca-core-multicast-oscoap] [I-D.tiloca-core-multicast-oscoap]
Tiloca, M., Selander, G., Palombini, F., and J. Park, Tiloca, M., Selander, G., Palombini, F., and J. Park,
"Secure group communication for CoAP", draft-tiloca-core- "Secure group communication for CoAP", draft-tiloca-core-
multicast-oscoap-04 (work in progress), October 2017. multicast-oscoap-04 (work in progress), October 2017.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
skipping to change at page 51, line 36 skipping to change at page 54, line 36
For settings where the Master Secret is only used during deployment, For settings where the Master Secret is only used during deployment,
the uniqueness of AEAD nonce may be assured by persistent storage of the uniqueness of AEAD nonce may be assured by persistent storage of
the security context as described in this specification (see the security context as described in this specification (see
Section 7.5). For many IoT deployments, a 128 bit uniformly random Section 7.5). For many IoT deployments, a 128 bit uniformly random
Master Key is sufficient for encrypting all data exchanged with the Master Key is sufficient for encrypting all data exchanged with the
IoT device throughout its lifetime. IoT device throughout its lifetime.
B.2. Master Secret Used Multiple Times B.2. Master Secret Used Multiple Times
In cases where the Master Secret is used to derive security context In cases where the Master Secret needs to be used to derive multiple
multiple times, e.g. during recommissioning or where the security security contexts, e.g. due to recommissioning or where the security
context is not persistently stored, the reuse of AEAD nonce may be context is not persistently stored, a stochastically unique Master
prevented by providing a sufficiently long uniformly random byte Salt prevents the reuse of AEAD nonce and key. The Master Salt may
string as Master Salt, such that the probability of Master Salt re- be transported between client and server in the kid context parameter
use is negligible. The Master Salt may be transported in the Kid (see Section 5.1) of the request.
Context parameter of the request (see Section 5.1)
In this section we give an example of a procedure which may be
implemented in client and server to establish the OSCORE security
context based on pre-established input parameters (see Section 3.2)
except for the Master Salt which is transported in kid context.
1. In order to establish a security context with a server for the
first time, or a new security context replacing an old security
context, the client generates a (pseudo-)random uniformly
distributed 64-bit Master Salt and derives the security context
as specified in Section 3.2. The client protects a request with
the new Sender Context and sends the message with kid context set
to the Master Salt.
2. The server, receiving an OSCORE request with a non-empty kid
context derives the new security context using the received kid
context as Master Salt. The server processes the request as
specified in this document using the new Recipient Context. If
the processing of the request completes without error, the server
responds with an Echo option as specified in
[I-D.ietf-core-echo-request-tag]. The response is protected with
the new Sender Context.
3. The client, receiving a response with an Echo option to a request
which used a new security context, verifies the response using
the new Recipient Context, and if valid repeats the request with
the Echo option (see [I-D.ietf-core-echo-request-tag]) using the
new Sender Context. Subsequent message exchanges (unless
superseded) are processed using the new security context without
including the Master Salt in the kid context.
4. The server, receiving a request with a kid context and a valid
Echo option (see [I-D.ietf-core-echo-request-tag]), repeats the
processing described in step 2. If it completes without error,
then the new security context is established, and the request is
valid. If the server already had an old security context with
this client that is now replaced by the new security context.
If the server receives a request without kid context from a client
with which no security context is established, then the server
responds with a 4.01 Unauthorized error message with diagnostic
payload containing the string "Security context not found". This
could be the result of the server having lost its security context or
that a new security context has not been successfully established,
which may be a trigger for the client to run this procedure.
B.3. Client Aliveness B.3. Client Aliveness
The use of a single OSCORE request and response enables the client to The use of a single OSCORE request and response enables the client to
verify that the server's identity and aliveness through actual verify that the server's identity and aliveness through actual
communications. While a verified OSCORE request enables the server communications. While a verified OSCORE request enables the server
to verify the identity of the entity who generated the message, it to verify the identity of the entity who generated the message, it
does not verify that the client is currently involved in the does not verify that the client is currently involved in the
communication, since the message may be a delayed delivery of a communication, since the message may be a delayed delivery of a
previously generated request which now reaches the server. To verify previously generated request which now reaches the server. To verify
skipping to change at page 59, line 4 skipping to change at page 62, line 41
o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes) o plaintext: 0x45ff48656c6c6f20576f726c6421 (14 bytes)
o encryption key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes) o encryption key: 0xd904cb101f7341c3f4c56c300fa69941 (16 bytes)
o nonce: 0xd0a1949aa253278e34c528d2cc (13 bytes) o nonce: 0xd0a1949aa253278e34c528d2cc (13 bytes)
From the previous parameter, the following is derived: From the previous parameter, the following is derived:
o Object-Security value: 0x0100 (2 bytes) o Object-Security value: 0x0100 (2 bytes)
o ciphertext: 0xa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (22 o ciphertext: 0xa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (22
bytes) bytes)
From there: From there:
o Protected CoAP response (OSCORE message): 0x64442b130000b29ed20801 o Protected CoAP response (OSCORE message): 0x64442b130000b29ed20801
00ffa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (35 bytes) 00ffa7e3ca27f221f453c0ba68c350bf652ea096b328a1bf (35 bytes)
Appendix D. CDDL Summary
Data structure definitions in the present specification employ the
CDDL language for conciseness and precision. CDDL is defined in
[I-D.ietf-cbor-cddl], which at the time of writing this appendix is
in the process of completion. As the document is not yet available
for a normative reference, the present appendix defines the small
subset of CDDL that is being used in the present specification.
Within the subset being used here, a CDDL rule is of the form "name =
type", where "name" is the name given to the "type". A "type" can be
one of:
o a reference to another named type, by giving its name. The
predefined named types used in the present specification are:
"uint", an unsigned integer (as represented in CBOR by major type
0); "int", an unsigned or negative integer (as represented in CBOR
by major type 0 or 1); "bstr", a byte string (as represented in
CBOR by major type 2); "tstr", a text string (as represented in
CBOR by major type 3);
o a choice between two types, by giving both types separated by a
"/";
o an array type (as represented in CBOR by major type 4), where the
sequence of elements of the array is described by giving a
sequence of entries separated by commas ",", and this sequence is
enclosed by square brackets "[" and "]". Arrays described by an
array description contain elements that correspond one-to-one to
the sequence of entries given. Each entry of an array description
is of the form "name : type", where "name" is the name given to
the entry and "type" is the type of the array element
corresponding to this entry.
Acknowledgments Acknowledgments
The following individuals provided input to this document: Christian The following individuals provided input to this document: Christian
Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Esko Amsuess, Tobias Andersson, Carsten Bormann, Joakim Brorsson, Esko
Dijk, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Jim Schaad, Dijk, Thomas Fossati, Martin Gunnarsson, Klaus Hartke, Jim Schaad,
Peter van der Stok, Dave Thaler, Marco Tiloca, and Malisa Vucinic. Peter van der Stok, Dave Thaler, Marco Tiloca, and Malisa Vucinic.
Ludwig Seitz and Goeran Selander worked on this document as part of Ludwig Seitz and Goeran Selander worked on this document as part of
the CelticPlus project CyberWI, with funding from Vinnova. the CelticPlus project CyberWI, with funding from Vinnova.
 End of changes. 55 change blocks. 
110 lines changed or deleted 300 lines changed or added

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