|
Hi Goran, Thank you for your feed backs. I believe all my concerns have been addressed. You can see inline the specific response. <mglt2></mglt2> Yours, Daniel -----Original Message----- >Hello Daniel, > >Thanks for your review. Please find responses inline. Göran > >On 2018-07-31, 00:10, "Daniel Migault" <daniel.migault@xxxxxxxxxxxx> >wrote: > >>Reviewer: Daniel Migault >>Review result: Has Issues >> >>Hi, >> >>Reviewer: Daniel Migault >>Review result: Has Issues >> >>I have reviewed this document as part of the security directorate's >>ongoing >>effort to review all IETF documents being processed by the IESG. These >>comments were written primarily for the benefit of the security area >>directors. >> Document editors and WG chairs should treat these comments just like >>any >>other last call comments. >> >>The summary of the review is Has (small) Issues. >> >>I am not an expert in CoAP. The document is well written, and I believe >>securing objects is important. I had comments regarding the description >>of >>security contexts. I hesitated between Nits and Issues. I do not believe >>these >>are major design issues, and some clarifications may be sufficient. Other >>comments are mostly editorial nits. Please find above my comments. I am >>happy >>to follow up the updates. >> >> Object Security for Constrained RESTful Environments (OSCORE) >> draft-ietf-core-object-security-14 >> >>1. Introduction >> >> The Constrained Application Protocol (CoAP) [RFC7252] is a web >> transfer protocol, designed for constrained nodes and networks >> [RFC7228], and may be mapped from HTTP [RFC8075]. CoAP specifies the >> use of proxies for scalability and efficiency and references DTLS >> [RFC6347] for security. CoAP-to-CoAP, HTTP-to-CoAP, and CoAP-to-HTTP >> proxies require DTLS or TLS [RFC5246] to be terminated at the proxy. >> The proxy therefore not only has access to the data required for >> performing the intended proxy functionality, but is also able to >> eavesdrop on, or manipulate any part of, the message payload and >> metadata in transit between the endpoints. The proxy can also >> inject, delete, or reorder packets since they are no longer protected >> by (D)TLS. >><mglt> >>The proxy can almost do whatever it wants as mentioned in the second >>sentence. >>Accessing the data enables it to passively monitor the communication. I >>would >>thus propose some text around these lines: >> >>OLD: >>The proxy therefore not only has access to the data required for >> performing the intended proxy functionality, but is also able to >> eavesdrop on, or manipulate any part of, the message payload and >> metadata in transit between the endpoints. The proxy can also >> inject, delete, or reorder packets since they are no longer protected >> by (D)TLS. >> >>NEW: >>The proxy therefore has access to the data required for >> performing the intended proxy functionality, and so can passively >>monitor >> the communications. In addition, the proxy can also inject, delete, or >> reorder packets since they are no longer protected by (D)TLS. >></mglt> > > >[GS:] I didn’t really understand this comment. The point we tried to make >is that since (D)TLS protects everything or nothing, in order for e.g. a >forward proxy to read and change selected CoAP options to perform its >intended function, the entire CoAP message needs to be decrypted, which >enables a range of attacks. I think your proposed sentence does not >explain that accurately: "The proxy therefore has access to the data >required for performing the intended proxy functionality, and so can >passively monitor the communications.” because it is not the data required >for performing the intended proxy functionality that is interesting here, >it >is the other data that also becomes available to the proxy as the entire >message needs to be decrypted. The term “eavesdropping” is used in the old >text, would not that cover “passively monitor”? Perhaps you could further >elaborate >on what you think is incorrect or missing in the current text? > <mglt2> My intention was to clarify what could be performed without DTLS decryption and with the DTLS decryption performed by the proxy. That said I am fine with the text you proposed as well.
</mglt2> >> >> This document defines the Object Security for Constrained RESTful >> Environments (OSCORE) security protocol, protecting CoAP and CoAP- >> mappable HTTP requests and responses end-to-end across intermediary >> nodes such as CoAP forward proxies and cross-protocol translators >> incuding HTTP-to-CoAP proxies [RFC8075]. In addition to the core >> CoAP features defined in [RFC7252], OSCORE supports Observe >> [RFC7641], Block-wise [RFC7959], No-Response [RFC7967], and PATCH and >> FETCH [RFC8132]. >><mglt> >>Maybe too many "and". >></mglt> > >[GS:] I see what you mean. The title of RFC 8132 is "PATCH and FETCH >methods for CoAP”. Perhaps we just change the order of the examples in the >last sentence: NEW >"In addition to the core CoAP features defined in >[RFC7252], OSCORE supports Observe [RFC7641], Block-wise [RFC7959], PATCH >and FETCH [RFC8132], and No-Response [RFC7967].”? > > <mglt2> I am fine either ways. I think the problem is that we a have a list of different nature, unless we are considering the documents themselves. I would propose: OSCORE supports the BlockWise Transfert Signaling Option [RFC7959], the Observed [RFC7641] and No-Response Option, [RFC7967], as well as the PATCH and FETCH Methods [RFC8132].
</mglt2> > >> >>An analysis of end-to-end security for CoAP >> messages through some types of intermediary nodes is performed in >> [I-D.hartke-core-e2e-security-reqs]. OSCORE essentially protects the >> RESTful interactions; the request method, the requested resource, the >> message payload, etc. (see Section 4). OSCORE protects neither the >> CoAP Messaging Layer nor the CoAP Token which may change between the >> endpoints, and those are therefore processed as defined in [RFC7252]. >> Additionally, since the message formats for CoAP over unreliable >> transport [RFC7252] and for CoAP over reliable transport [RFC8323] >> differ only in terms of CoAP Messaging Layer, OSCORE can be applied >> to both unreliable and reliable transports (see Figure 1). >> >>Selander, et al. Expires January 27, 2019 [Page 4] >> >>Internet-Draft OSCORE July 2018 >> >> +-----------------------------------+ >> | Application | >> +-----------------------------------+ >> +-----------------------------------+ \ >> | Requests / Responses / Signaling | | >> |-----------------------------------| | >> | OSCORE | | CoAP >> |-----------------------------------| | >> | Messaging Layer / Message Framing | | >> +-----------------------------------+ / >> +-----------------------------------+ >> | UDP / TCP / ... | >> +-----------------------------------+ >> >> Figure 1: Abstract Layering of CoAP with OSCORE >> >> OSCORE works in very constrained nodes and networks, thanks to its >> small message size and the restricted code and memory requirements in >> addition to what is required by CoAP. Examples of the use of OSCORE >> are given in Appendix A. OSCORE does not depend on underlying >> layers, and can be used with non-IP transports (e.g., >> [I-D.bormann-6lo-coap-802-15-ie]). OSCORE may also be used in >> different ways with HTTP. OSCORE messages may be transported in >> HTTP, and OSCORE may also be used to protect CoAP-mappable HTTP >> messages, as described below. >> >><mglt> >>I believe that "underlying layers" should be specified. My understanding >>is >>that OSCORE requires CoAP or HTTP. If that is correct, I believe that >>should be >>clarified in the paragraph above. </mglt> > >[GS:] No, the underlying layers in this context are not CoAP or HTTP, but >the layers below OSCORE, e.g. UDP or TCP. The fact that OSCORE can be >deployed with CoAP-mappable HTTP is a different property which is the >reason for “also” in the next to last sentence. Would the following >clarification be sufficient? >OLD >OSCORE does not depend on underlying layers, and can be used with non-IP >transports (e.g., [I-D.bormann-6lo-coap-802-15-ie) >NEW >OSCORE does not depend on underlying layers such as e.g. UDP or TCP, and >can even be used with non-IP transports (e.g., >[I-D.bormann-6lo-coap-802-15-ie]) > > <mglt2> This is clarifying, Thanks for the explanation. </mglt2> > >> >> OSCORE is designed to protect as much information as possible whie >> still allowing CoAP proxy operations (Section 10). It works with >> existing CoAP-to-CoAP forward proies [RFC7252], but an OSCORE-aware >> proxy will be more efficient. HTTP-to-CoAP proxies [RFC8075] and >> CoAP-to-HTTP proxies can also be used with OSCORE, as specified in >> Section 11. OSCORE may be used together with TLS or DTLS over one or >> more hops in the end-to-end path, e.g. transported with HTTPS in one >> hop and with plain CoAP in another hop. The use of OSCORE does not >> affect the URI scheme and OSCORE can therefore be used with any URI >> scheme defined for CoAP or HTTP. The application decides the >> conditions for which OSCORE is required. >> >> OSCORE uses pre-shared keys which may have been established out-of- >> band or with a key establishment protocol (see Section 3.2). The >> technical solution builds on CBOR Object Signing and Encryption >> (COSE) [RFC8152], providing end-to-end encryption, integrity, replay >> protection, and binding of response to request. A compressed version >> of COSE is used, as specified in Section 6. The use of OSCORE is >> signaled in CoP with a new option (Section 2), and in HTTP with a >> new header field (Sction 11.1) and content type (Section 13.5). The >> solution transforms a CoAP/HTTP message into an "OSCORE message" >> before sending, and vice versa ater receiving. The OSCORE message >> >>Selander, et al. Expires January 27, 2019 [Page 5] >> >>Internet-Draft OSCORE July 2018 >> >> is a CoAP/HTTP message related to the origial message in the >> following way: the original CoAP/HTTP message is translated to CoAP >> (if not already i CoAP) and protected in a COSE object. The >> encrypted message fields of this COSE object are transported in the >> CoAP payload/HTTP body of the OSCORE message, and the OSCORE option/ >> header field is included in the message. A sketch of an exchange of >> OSCORE messages, in the case of the original message being CoAP, is >> provided in Figure 2. >> >> Client Server >> | OSCORE request - POST example.com: | >> | Header, Token, | >> | Options: {OSCORE, ...}, | >> | Payload: COSE ciphertext | >> +--------------------------------------------->| >> | | >> |<---------------------------------------------+ >> | OSCORE response - 2.04 (Changed): | >> | Header, Token, | >> | Options:{OSCORE, ...}, | >> | Payload: COSE ciphertext | >> | | >> >> Figure 2: Sketch of CoAP with OSCORE >> >><mglt> >>Options are mentioned in {}. How these "{}" should be interpreted may be >>specified in the figure. > >[GS:] The curly brackets have no special meaning here so we can remove >them altogether: >OLD >Options: {OSCORE, ...}, >NEW >Options: OSCORE, ... , > <mglt2> Thanks for the clarification. Maybe those brakes could be used to indicate what is encrypted. I also noticed potential typos - CoP , (if not already i CoAP) if not introduced by myself. </mglt2 > >> >>The paragraph above mentions that OSCORE can be used both with CoAP or >>HTTP. It >>might be helpful to split Figure 2 in to two sub figures Figure 2a) that >>illustrates the use of OCSORE with CoAP and figure 2b) that illustrates >>the use >>of OSCORE with HTTP. > >[GS:] Section 11.5 provides a detailed example, I propose to add a >reference to section 11 above the figure. <mglt2> Works for me. </mglt2> > > >>My understanding is that CoAP and HTTP can easily be translated. As such >>it >>might also be able to consider OSCORE only with CoAP and having a >>specific >>section that deals with HTTP. Such split may avoid to deal in parallel >>with >>HTTP and CoAP. </mglt> > >[GS:] Section 11 is a specific section that deals with HTTP. Would the >reference mentioned above be sufficient? > > <mglt> Yes. </mglt2> >> >> An implementation supporting this specification MAY implement only >> the client part, MAY implement only the server part, or MAY implement >> only one of the proxy parts. >> >>1.1. Terminology >> >>2. The OSCORE Option >> >> The OSCORE option (see Figure 3, which extends Table 4 of [RFC7252]) >> indicates that the CoAP message is an OSCORE message and that it >> contains a compressed COSE object (see Sections 5 and 6). The OSCORE >> option is critical, safe to forward, part of the cache key, and not >> repeatable. >> >><mglt> >>I believe it would be clearer to specify that this section defines the >>OSCORE >>option which is a new CoAP option. Similarly Table 4 may also be >>designated by >>CoAP Options or something similar. </mglt> > > >[GS:] I didn’t understand the second sentence: Table 4 is in RFC 7252, >what does it mean for this draft that this table should be "designated by >CoAP Options”? If there is a need to explain the content of >a referenced table in another document, then perhaps better remove the >reference altogether - this table is anyway well known to anyone >familiar with CoAP. Here is a proposed replacement of the first sentence >of section 2: >NEW >The OSCORE option defined in this section (see Figure 3) >indicates that the CoAP message is an OSCORE message and that it >contains a compressed COSE object (see Sections 5 and 6). > > <mglt2> I only mentioned a nit. I am fine with both alternative but prefer the second.
</mglt2> > > > >The use of OSCORE is signaled in CoAP with a new option (Section 2), and >in HTTP with a new header field (Section 11.1) and content type (Section >13.5). > >> >> +------+---+---+---+---+----------------+--------+--------+---------+ >> | No. | C | U | N | R | Name | Format | Length | Default | >> +------+---+---+---+---+----------------+--------+--------+---------+ >> | TBD1 | x | | | | OSCORE | (*) | 0-255 | (none) | >> +------+---+---+---+---+----------------+--------+--------+---------+ >> C = Critical, U = Unsafe, N = NoCacheKey, R = Repeatable >> (*) See below. >> >> Figure 3: The OSCORE Option >> >> The OSCORE option includes the OSCORE flag bits (Section 6), the >> Sender Sequence Number, the Sender ID, and the ID Context when these >> fields are present (Section 3). The detailed format and length is >> specified in Section 6. If the OSCORE flag bits are all zero (0x00) >> the Option value SHALL be empty (Option Length = 0). An endpoint >> receiving a CoAP message without payload, that also contains an >> OSCORE option SHALL treat it as malformed and reject it. >> >><mglt> >>I believe the logic for the OSCORE option is the other way around, that >>is: an >>CoAP message with an OSCORE option with an empty CoAP payload MUST be >>rejected >>as malformed and reject it. </mglt> > >[GS:] Both statements are correct. Perhaps it is even more clear if “and” >is used: >NEW >An endpoint receiving a CoAP message with the OSCORE option and without >payload SHALL treat it as malformed and reject it. > > <mglt2> Sounds good to me. </mglt2> >> >> A successful response to a request with the OSCORE option SHALL >> contain the OSCORE option. Whether error responses contain the >> OSCORE option depends on the error type (see Section 8). >> >> For CoAP proxy operations, see Section 10. >> >>3. The Security Context >> >> OSCORE requires that client and server establish a shared security >> context used to process the COSE objects. OSCORE uses COSE with an >> Authenticated ncryption with Additional Data (AEAD, [RFC5116]) >> algorithm for protecting essage data between a client and a server. >> In this section, we define the security context and how it is derived >> >>Selander, et al. Exires January 27, 2019 [Page 7] >> >>Internet-Draft OSCORE July 2018 >> >> in client and server based on a shared secret and a key derivation >> function (KDF). >> >>3.1. Security Context Definition >> >> The security context is the set of information elements necessary to >> carry out the cryptographic operations in OSCORE. For each endpoint, >> the security context is composed of a "Common Context", a "Sender >> Context", and a "Recipient Context". >> >> The endpoints protect messages to send using the Sender Context and >> verify messages received using the Recipient Context, both contexts >> being derived from the Common Context and other data. Clients and >> servers need to be able to retrieve the correct security context to >> use. >> >><mglt> >>I believe it might be clarifying to specify that CoAP endpoints have >>always >>bidirectional communications. >[GS:] This is not correct for all applications of OSCORE. For group >communications there is the concept of a "silent server” which is just >listening to multicast messages: >https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-02 >There is also the “No-Response” option which inhibits certain responses. > >>If that is correct, then for each communication >>each end point is both a "Sender" and a "Recipient" for its respective >>outbound >>and ibound traffic. The 4 context are derived from a Common Context. >> >>As securitycontext are established to secure unidirectional >>communications, >>maybe that would be easier to base the description on the unidirectional >>commuications rather than the end points. </mglt> > >[GS:] I’m not sure how I should address this comment, but one reason why >the security context is described from the point of view of endpoints s >that an endpoint uses the security context in the same way indepenent of >being client or server. E.g. the Sender Context is used by an endoint in >the role of client sending requests and in the role of servr sending >responses. > > > >> >> An endpoint uses its Sender ID (SD) to derive its Sender Context, >> and the other endpoint uses the sameID, now called Recipient ID >> (RID), to derive its Recipient Context. In communication between two >> endpoints, the Sender Context of one endoint matches the Recipient >> Context of the other endpoint, and vice versa. Thus, the two >> security contexts identified by the same IDs in the two endpoints are >> not the same, but they are partly mirrored. Retrieval and use of the >> security context are shown in Figure 4. >> <mglt2> OK. Thanks for the clarification. I believe I was out of the track because I was reading it with ipsec eyes. I think the figure 4 seems to illustrate better what the text says – at least to me. </mglt2> >><mglt> >>"An endpoint uses its Sender ID (SID) to derive its Sender Context," >> >>I see the ID as mostly useful to the recipient in order to retrieve the >>appropriated security context and decrypt the message. In other words, >>the >>sender should know who it sends the message to and does not really need >>the SID>>to match the security context. >> >>I believe this should be clarified as the current text prevents Sender ID >>collision, while collision should only be avoided on the receiver's side. >></mglt> > >[GS:] Section 3.3 states the following: "To ensure unique Sender Keys, the >quartet (Master Secret, Master Salt, ID Context, Sender ID) MUST be >unique” and that this means that "Sender ID SHALL be unique in the set of >all security contexts using the same Master Secret, Master Salt, and ID >Context; such a requirement guarantees unique (key, nonce) pairs, which >avoids nonce reuse.” The proof for (key,nonce) uniqueness is in Appendix >D.3 and critically uses the uniqueness of Sender IDs, so that is indeed >required. >As a consequence, the Recipient IDs within one security context are also >unique. >Coincidence of Recipient IDs between different security contexts is not a >security issue, section 3.3 also states: "To simplify retrieval of the >right Recipient Context, the Recipient ID SHOULD be unique in the sets of >all Recipient Contexts used by an endpoint. If an endpoint has the same >Recipient ID with different Recipient Contexts, i.e. the Recipient >Contexts are derived from different Common Contexts, then the endpoint may >need to try multiple times before verifying the right security context >associated to the Recipient ID.” Is there something missing from this >description? <mglt2> I agree this is a strong SHOULD++. The Recipient ID SHOULD be unique.
</mglt2> > > > >> >> .-------------. .-------------. >> | Common, | | Common, | >> | Sender, | | Recipient, | >> | Recipient | | Sender | >> '-------------' '-------------' >> Client Server >> | | >> Retrieve context for | OSCORE request: | >> target resource | Token = Token1, | >> Protect request with | kid = SID, ... | >> Sender Context +---------------------->| Retrieve context with >> | | RID = kid >> | | Verify request with >> | | Recipient Context >> | OSCORE response: | Protect response with >> | Token = Token1, ... | Sender Context >> Retrieve context with |<----------------------+ >> Token = Token1 | | >> Verify request with | | >> Recipient Context | | >> >> Figure 4: Retrieval and Use of the Security Context >> >><mglt> >>I might be helpful to clarify that Sender Context on both sides are not >>the >>same context. > > > >[GS:] Is this better? >OLD >The endpoints protect messages to send using the Sender Context and >verify messages received using the Recipient Context, both contexts >being derived from the Common Context and other data. >NEW >An endpoint protects messages to send using its Sender Context and >verifies messages received using its Recipient Context, both contexts >being derived from the Common Context and other data. > > > <mglt2> This is fine to me. </mglt2> > > >>Security Context seems to be missing in the box. > >[GS:] Figure 4 contains some abbreviations to avoid becoming overloaded >with text: In the first box “Common, Sender, Recipient” is an abbreviation >of “Common Context, Sender Context, Recipient Context” - which in fact is >the the topic of this section. Do you think this is unclear? Maybe I >misunderstood the comment. > <mglt2> I am fine either ways. I was perhaps suggesting to mention Context (once).
</mglt2> >> >>It would also help to have in the figure, the relation between the Common >>Security Context, the Sender Context and Recipient Context on both sides. >></mglt> > >[GS:] The figure is already trying to illustrate this by the orders of the >contexts in the boxes for client and server: showing that the Common >Context is common for both Client and Server whereas the Sender Context of >the Client corresponds to the Recipient Context of the Server and vice >versa. I don’t know how to make this more clear without overloading the >figure. > <mglt2> This looks much clearer to me. Common Context is common and “=” is very helpful ( to me). </mglt2> > >> >>Selander, et al. Expires January 27, 2019 [Page 8] >> >>Internet-Draft OSCORE July 2018 >> >> The Common Context contains the following parameters: >> >> o AEAD Algorithm. The COSE AEAD algorithm to use for encryption. >> >> o Key Derivation Function. The HMAC based HKDF [RFC5869] used to >> derive Sender Key, Recipient Key, and Common IV. >><mglt> >>This is confusing to have a generic term such as KDF defined by a sup set >>of it >>(HKDF). I believe that either the KDF is defined generic enough and later >>the >>default value is set to HKDF with a specific hash function. Another >>alternative >>could be to limited the scope of this parameter to HKDF Hash Function. >></mglt> > > >[GS:] How about this? >NEW > o The HMAC based key derivation function HKDF [RFC5869] used to > derive Sender Key, Recipient Key, and Common IV. > > <mglt2> This is fine to me. </mglt2> >> >> o Master Secret. Variable length, random byte string (see >> Section 12.3) used to derive traffic keys and IVs. >><mglt> >>I believe that IVs is the Common IV. >></mglt> > >[GS:] Correct, will change that. > <mglt2> Good </mglt2> > >> o Master Salt. Optional variable length byte string containing the >> salt used to derive traffic keys and IVs. >><mglt> >>I believe that IVs is the Common IV. >></mglt> > >[GS:] Correct, will change that. > <mglt2> Good </mglt2> > >> o ID Context. Optional variable length byte string providing >> additional information to identify the Common Context and to >> derive traffic keys and IVs. >> >> o Common IV. Byte string derived from Master Secret, Master Salt, >> and ID Context. Length is determined by the AEAD Algorithm. >><mglt> >>RFC8152 uses context IV. It is not clear to me how these two differ. I >>believe >>some text should be added to explain how Common IV differs from the >>context IV. >> <mglt2> As discussed, nonce construction is different for COSE, so Context IV should not be used here.
</mglt2> >>It is unclear to me whether the Common Context is used for the two >>bidirectional communications. If that is the case, I am reading that >>Common IV >>and Sequence Number in the two directions will end up in IV collision. So >>Keys >>needs to be unidirectional and different. </mglt> > >[GS:] As mentioned above: when sending, each endpoint uses its Sender Key, >and the nonce is specified in Section 5.2. The proof for (key,nonce) >uniqueness is in Appendix D.3. > > <mglt2> ok </mglt2> >> The Sender Context contains the following parameters: >> >> o Sender ID. Byte string used to identify the Sender Context, to >> derive traffic keys and IVs, and to assure unique nonces. Maximum >> length is determined by the AEAD Algorithm. >> >> o Sender Key. Byte string containing the symmetric key to protect >> messages to send. Derived from Common Context and Sender ID. >> Length is determined by the AEAD Algorithm. >> >> o Sender Sequence Number. Non-negative integer used by the sender >> to protect requests and certain responses, e.g. Observe >> notifications. Used as 'Partial IV' [RFC8152] to generate unique >> nonces for the AEAD. Maximum value is determined by the AEAD >> Algorithm. >> >> The Recipient Context contains the following parameters: >> >> o Recipient ID. Byte string used to identify the Recipient Context, >> to derive traffic keys and IVs, and to assure unique nonces. >> Maximum length is determined by the AEAD Algorithm. >> >> o Recipient Key. Byte string containing the symmetric key to verify >> messages received. Derived from Common Context and Recipient ID. >> Length is determined by the AEAD Algorithm. >> >> o Replay Window (Server only). The replay window to verify requests >> received. >> >><mglt> >>Looking at the different contexts, maybe some text should be added to >>specify >>that Sender ID and Recipient ID are equal for a given unidirectional >>communication. The same occurs for Sender Key and Recipient Key. > >[GS:] The intention with Section 3.1 and Figure 4, which you quoted above, >is exactly to explain this: >"An endpoint uses its Sender ID (SID) to derive its Sender Context, and >the other endpoint uses the same ID, now called Recipient ID (RID), to >derive its Recipient Context.” >Excerpt of Figure 4: >Protect request with | kid = SID, . . . | > Sender Context +---------------------->| Retrieve context with > | | RID = kid >Is that still unclear? >Since this is symmetric crypto, it should hopefully be clear to anyone >that the keys used for encryption and decryption are the same, don’t you >think? > <mglt2> I think this has been solved earlier than. That is fine to me and I do not believe we should go any further regarding the key and asymmetric crypto.
</mglt2> >> >>I believe that Sender Sequence Number also needs to be present in the >>Recipient >>Context in order to implement anti replay mechanism. > >[GS:] The replay window is already part of the Recipient Context. Perhaps >a reference to Section 7.4 would be sufficient to make the connection >between replay window and sequence number? > <mglt2> Good, then yes a reference would be usefull </mglt2> >> >>Sequence Number May be interpreted differently. I believe that >>interpretation >>should also be part of the Common Security Context. > >[GS:] I didn’t understand this comment. <mglt2> Sequence Number are not always incremented. This interpretation may impact the session, so that may need to be specify in the future when considering other interpretation of the SSN. </mglt2> > >> >>As mentioned above the contexts may probably be refactored with one >>Context per >>unidirectional communication. </mglt> > >[GS:] IMHO the current text describes how to derive the security >context needed by endpoints to process messages to send and messages >received independent of being client or server. This may alternatively be >structured in a number of different cases but I don’t see how that >simplifies specification, implementation or security analysis. > > >> >>Selander, et al. Expires January 27, 2019 [Page 9] >> >>Internet-Draft OSCORE July 2018 >> >> All parameters except Sender Sequence Number and Replay Window are >> immutable once the security context is established. An endpoint may >> free up memory by not storing the Common IV, Sender Key, and >> Recipient Key, deriving them when needed. Alternatively, an endpoint >> may free up memory by not storing the Master Secret and Master Salt >> after the other parameters have been derived. >> >> Endpoints MAY operate as both client and server and use the same >> security context for those roles. Independent of being client or >> server, the endpoint protects messages to send using its Sender >> Context, and verifies messages received using its Recipient Context. >> The endpoints MUST NOT change the Sender/Recipient ID when changing >> roles. In other words, changing the roles does not change the set of >> keys to be used. >> >>3.2. Establishment of Security Context Parameters >> >> The parameters in the security context are derived from a small set >> of input parameters. The following input parameters SHALL be pre- >> established: >> >> o Master Secret >> >> o Sender ID >> >> o Recipient ID >> >><mglt> >>I believe that Sender ID and Recipient ID could be the same value for a >>given >>unidirectional communication. I believe that what is required her is the >>two >>IDs used by the sessions. </mglt> > >[GS:] Perhaps it wasn’t clear that this text is in the context of a given >endpoint? By section 3.3, in one endpoint, the Sender ID and Recipient ID >are different. Possible clarification: >OLD >The parameters in the security context are derived from a small set > of input parameters. >NEW >Each endpoint derives the parameters in the security context from a small >set of input parameters. > > <mglt2> This is better, and it also benefits from clarifications aboves. </mglt2> >> >> The following input parameters MAY be pre-established. In case any >> of these parameters is not pre-established, the default value >> indicated below is used: >> >> o AEAD Algorithm >> >> * Default is AES-CCM-16-64-128 (COSE algorithm encoding: 10) >> >> o Master Salt >> >> * Default is the empty byte string >><mglt> >>I believe explicitly providing the string could help. There is always the >>confusion with "\0" versus "". </mglt> > >[GS:] Note that the Master Salt is never sent and only used as salt in >HKDF (section 2.2 of RFC 5869). Section 3.2.1 describes how the empty >string should be interpreted: >"Note that [RFC5869] specifies that if the salt is not provided, it is set >to a string of >zeros. For implementation purposes, not providing the salt is the same >as setting the salt to the empty byte string. OSCORE sets the salt >default value to empty byte string, which in [RFC5869] is converted to a >string of zeroes (see Section 2.2 of [RFC5869])." >Is that sufficiently clear? > > <mglt2> This is fine. It seems to me that empty string is “” here. I usually like to cite explicitly the string to avoid confusion between “” or “\0”. I agree that saying zero length does not help much The latest sentence has two reference to RFC5869, maybe one would be sufficient. If possible, it might be better to specify the length of the strings of zeros (HashLen in our case)
</mglt2> > > > which defines how to > >> >> o Key Derivation Function (KDF) >> >> * Default is HKDF SHA-256 >> >> o Replay Window Type and Size >> >> * Default is DTLS-type replay protection with a window size of 32 >> [RFC6347] >><mglt> >>This section specifies Type and windows for the anti replay mechanism. >>This was >>described as Replay Windows in the context description. </mglt> > >[GS:] I didn’t understand this comment. Do you mean: >OLD >Replay Window Type and Size >NEW >Replay Window > > <mglt2> If different mechanism could be used, I meant: * Replay Window Type : default to DTLS 1.2 * Replay Window Size (Parameters):
</mglt> > > >>Selander, et al. Expires January 27, 2019 [Page 10] >> >>Internet-Draft OSCORE July 2018 >> >> 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. The way the input parameters are pre-established, is >> application specific. Considerations of security context >> establishment are given in Section 12.2 and examples of deploying >> OSCORE in Appendix B. >> >>3.2.1. Derivation of Sender Key, Recipient Key, and Common IV >> >> The KDF MUST be one of the HMAC based HKDF [RFC5869] algorithms >> defined for COSE [RFC8152]. >><mglt> >>It might be better to consider HKDF instead of KDF and then just specify
>>the >>Hash function </mglt> >[GS:] Is this better: >NEW > The HKDF MUST be one of the HMAC based HKDF [RFC5869] algorithms > defined for COSE [RFC8152]. > > <mglt2> I think that is better. </mglt2> > > >> >> HKDF SHA-256 is mandatory to implement. >> The security context parameters Sender Key, Recipient Key, and Common >> IV SHALL be derived from the input parameters using the HKDF, which >> consists of the composition of the HKDF-Extract and HKDF-Expand steps >> [RFC5869]: >> >> output parameter = HKDF(salt, IKM, info, L) >> >> where: >> >> o salt is the Master Salt as defined above >> >> o IKM is the Master Secret as defined above >> >> o info is the serialization of a CBOR array consisting of: >> >> info = [ >> id : bstr, >> id_context : bstr / nil, >> alg_aead : int / tstr, >> type : tstr, >> L : uint >> ] >><mglt> >>bstr, nil, tstr are used for the first time here. Maybe a reference to
>>8152 may >>be clarifying. </mglt> > >[GS:] OK, will do that and in the terminology section. <mglt2> Thanks. </mglt2> >> >> where: >> >> o id is the Sender ID or Recipient ID when deriving keys and the >> empty byte string when deriving the Common IV. The encoding is >> described in Section 5. >> >> o id_context is the ID Context, or nil if ID Context is not >> provided. >> >> o alg_aead is the AEAD Algorithm, encoded as defined in [RFC8152]. >> >> o type is "Key" or "IV". The label is an ASCII string, and does not >> include a trailing NUL byte. >> >>Selander, et al. Expires January 27, 2019 [Page 11] >> >>Internet-Draft OSCORE July 2018 >> >> o L is the size of the key/IV for the AEAD algorithm used, in bytes. >> >> For example, if the algorithm AES-CCM-16-64-128 (see Section 10.2 in >> [RFC8152]) is used, the integer value for alg_aead is 10, the value >> for L is 16 for keys and 13 for the Common IV. >> >> Note that [RFC5869] specifies that if the salt is not provided, it is >> set to a string of zeros. For implementation purposes, not providing >> the salt is the same as setting the salt to the empty byte string. >> OSCORE sets the salt default value to empty byte string, which in >> [RFC5869] is converted to a string of zeroes (see Section 2.2 of >> [RFC5869]). >> >><mglt> >>I believe that how Sender Key, Recipient Key, and Common IV are derived
>>from >>the output_parameters should be described as well. > >[GS:] This section is intended to describe just that. Is this more clear: >OLD >id is the Sender ID or Recipient ID when deriving keys and the empty byte
>string when deriving the Common IV. >NEW >id is the Sender ID or Recipient ID when deriving the Sender Key and
>Recipient Key, respectively, and the empty byte string when deriving the
>Common IV. > <mglt2> I believe that is clearer. </mglt2> > >>Note that in this case I believe that Sender Key and Recipient Key are
>>used for >>the two unidirectional communications. In other words, the same key
>>should be >>used by the sender and the recipient of the same communication. The same
>>Common >>IV is used in both communications. </mglt> > >[GS:] As discussed above, Section 3.1 describes how Sender ID and
>Recipient ID relate to each other. As proposed above, we emphasise in
>Section 3.2 that the derivations are with reference to one endpoint. Is
>that sufficiently clear now? As for the Common IV, its use is described >in Section 5.2. > > <mglt2> Yes, I believe this has been clarified earlier.
</mglt2> >>3.2.2. Initial Sequence Numbers and >>Replay Window >> >> The Sender Sequence Number is initialized to 0. The supported types >> of replay protection and replay window length is application specific >> and depends on how OSCORE is transported, see Section 7.4. The >> default is DTLS-type replay protection with a window size of 32 >> initiated as described in Section 4.1.2.6 of [RFC6347]. >> >><mglt> >>This should be specified the same in the Context. >></mglt> > >[GS:] We can make a reference to this section from Section 3. <mglt2> I think that would be clarifying.
</mglt2> >> >>3.3. Requirements on the Security Context Parameters >> >> To ensure unique Sender Keys, the quartet (Master Secret, Master >> Salt, ID Context, Sender ID) MUST be unique, i.e. the pair (ID >> Context, Sender ID) SHALL be unique in the set of all security >> contexts using the same Master Secret and Master Salt. This means >> that Sender ID SHALL be unique in the set of all security contexts >> using the same Master Secret, Master Salt, and ID Context; such a >> requirement guarantees unique (key, nonce) pairs, which avoids nonce >> reuse. >> >><mglt> >>I understand the use of SHALL and MUST as similar. If that is correct,
>>It >>may >>be better to use the same term throughout the document. > >[GS:] I’m open to guidance here but I’d rather not make these changes
>throughout the document unless there is an agreed convention about this.
>I >have learned about one distinction between actor (SHALL) and passive
>entity (MUST) but I don’t see that consequentially used in other RFCs. I
>don’t see any risk for errors resulting from interchangeably using SHALL
>or MUST. > <mglt2> I think that wise. Putting your shoes on, I would have been reluctant in changing them at that time. Thanks for the explanation between MUST and SHALL.
</mglt2> >> >>I believe that we would like to avoid that the same IV is being reused
>>with the >>same key. Any change in the inputs of the HMAC based KDF will result in a >>different output. As such any change in the output will result in that >>property. I suspect we would like to some parameters to remain wit the
>>same >>value, while some could be changed, and for that reason, we chose the
>>Sender >>ID. I believe the text could be clarified either on the reasoning behind
>>or how >>this should be operated. </mglt> > >[GS:] As mentioned above, the generation of that nonce used with the AEAD
>is described in Section 5.2. The reasoning why this is secure is in
>Appendix D.3. Is there anything missing? <mglt2> No. I guess that is fine </mglt2> > >> >> Different methods can be used to assign Sender IDs: a protocol that >> allows the parties to negotiate locally unique identifiers, a trusted >> third party (e.g., [I-D.ietf-ace-oauth-authz]), or the identifiers >> can be assigned out-of-band. The Sender IDs can be very short (note >> that the empty string is a legitimate value). The maximum length of >> Sender ID in bytes equals the length of AEAD nonce minus 6. For AES- >> CCM-16-64-128 the maximum length of Sender ID is 7 bytes. >> >><mglt> >>I suspect those restriction coming from the COSE specification. If that
>>is >>correct, I believe it would be helpful to have a reference to that
>>document. >></mglt> > > >[GS:] No, the restriction comes from the nonce construction, I will add a
>reference to Section 5.2. <mglt2> Thanks, I believe that would be useful. </mglt2> > >> >> To simplify retrieval of the right Recipient Context, the Recipient >> ID SHOULD be unique in the sets of all Recipient Contexts used by an >> endpoint. If an endpoint has the same Recipient ID with different >> Recipient Contexts, i.e. the Recipient Contexts are derived from >> different Common Contexts, then the endpoint may need to try multiple >> times before verifying the right security context associated to the >> Recipient ID. >> >><mglt> >>Such collision could represent an attack where the attacker could in
>>case >>a >>collision is observed craft a packet that costs two time more
>>computation >>than >>a regular packet. > >[GS:] This section describes unnecessary processing due to collision of
>identifiers. Note that an attacker can spoof a message and use an
>existing >identifier even if there is only single context with this identifier, and
>such attacks are already mentioned in the security considerations. > >> >>I might be wrong, but it seems that the ID is more important for the
>>recipient. >>Typically the sender can easily address Sender ID collision. On the
>>other >>hand the cryptographic properties are based on the uniqueness of the
>>Sender ID. >>Maybe these could be considered with the Recipient ID in mind. </mglt> > >[GS:] See discussion about requirements on security context above. > > <mglt2> OK </mglt2> >> >>Selander, et al. Expires January 27, 2019 [Page 12] >> >>Internet-Draft OSCORE July 2018 >> >> The ID Context is used to distinguish between security contexts. The >> methods used for assigning Sender ID can also be used for assigning >> the ID Context. Additionally, the ID Context can be generated by the >> client (see Appendix B.2). ID Context can be arbitrarily long. >> >>4. Protected Message Fields >> >>4.1. CoAP Options >> >>4.1.1. Inner Options >>4.1.2. Outer Options >>4.1.3. Special Options >>4.1.3.1. Max-Age >>4.1.3.2. Uri-Host and Uri-Port >>4.1.3.3. Proxy-Uri >>4.1.3.4. The Block Options >>4.1.3.4.1. Inner Block Options >>4.1.3.4.2. Outer Block Options >>4.1.3.5. Observe >>4.1.3.5.1. Registrations and Cancellations >>4.1.3.5.2. Notifications >> >> If the server accepts an Observe registration, a Partial IV MUST be >> included in all notifications (both successful and error), except for >> the first one where Partial IV MAY be omitted. To protect against >> replay, the client SHALL maintain a Notification Number for each >> Observation it registers. The Notification Number is a non-negative >> integer containing the largest Partial IV of the received >> notifications for the associated Observe registration. Further >> details of replay protection of notifications are specified in >> Section 7.4.1. >> >> For notifications, the Inner Observe value MUST be empty (see >> Section 3.2 of [RFC7252]). The Outer Observe in a notification is >> >>Selander, et al. Expires January 27, 2019 [Page 20] >> >>Internet-Draft OSCORE July 2018 >> >> needed for intermediary nodes to allow multiple responses to one >> request, and may be set to the value of Observe in the original CoAP >> message. The client performs ordering of notifications and replay >> protection by comparing their Partial IVs and SHALL ignore the outer >> Observe value. >> >> If the client receives a response to an Observe request without an >> Inner Observe option, then it verifies the response as a non-Observe >> response, as specified in Section 8.4. If the client receives a >> response to a non-Observe request with an Inner Observe option, then >> it stops processing the message, as specified in Section 8.4. >> >> A client MUST consider the notification with the highest Partial IV >> as the freshest, regardless of the order of arrival. In order to >> support existing Observe implementations the OSCORE client >> implementation MAY set the Observe value to the three least >> significant bytes of the Partial IV; such an implementation needs to >> make sure that the Observe value for an observe notification without >> Partial IV is smaller than a notification with Partial IV. >> >><mglt> >>This section discuss the behavior regarding the sequence number. While
>>the >>sequence number and the partial IV have the same value, I am wondering
>>if >>it >>would not be more appropriated to mention the sequence number value is
>>provided >>by the partial IV, and then use the sequence number variable to describe
>>anti >>replay. </mglt> > > >[GS:] We intended to use the term “partial IV” when referring to the
>number being transported and “SSN" when referring to the number stored in
>the endpoint. I will go through the document and see that this convention
>is kept. >> <mglt2> Maybe that would be useful to mention this convention </mglt2> >>4.1.3.6. No-Response >>4.1.3.7. OSCORE >>4.2. CoAP Header Fields and Payload >>4.3. Signaling Messages >>5. The COSE Object >>5.1. Kid Context >>5.2. Nonce >>5.3. Plaintext >>5.4. Additional Authenticated Data >>6. OSCORE Header Compression >>6.1. Encoding of the OSCORE Option Value >>6.2. Encoding of the OSCORE Payload >>6.3. Examples of Compressed COSE Objects >>7.2. Sequence Numbers >>7.2.1. Maximum Sequence Number >>7.3. Freshness >>7.4. Replay Protection >> >> In order to protect from replay of requests, the server's Recipient >> Context includes a Replay Window. A server SHALL verify that a >> Partial IV received in the COSE object has not been received before. >> If this verification fails the server SHALL stop processing the >> message, and MAY optionally respond with a 4.01 Unauthorized error >> message. Also, the server MAY set an Outer Max-Age option with value >> zero, to inform any intermediary that the response is not to be >> cached. The diagnostic payload MAY contain the "Replay detected" >> string. The size and type of the Replay Window depends on the use >> case and the protocol with which the OSCORE message is transported. >> In case of reliable and ordered transport from endpoint to endpoint, >> e.g. TCP, the server MAY just store the last received Partial IV and >> require that newly received Partial IVs equals the last received >> Partial IV + 1. However, in case of mixed reliable and unreliable >> transports and where messages may be lost, such a replay mechanism >> >>Selander, et al. Expires January 27, 2019 [Page 33] >> >>Internet-Draft OSCORE July 2018 >> >> may be too restrictive and the default replay window be more suitable >> (see Section 3.2.2). >><mglt> >>I am reading the anti replay mechanism used as very specific.
>>Incrementing >>Partial IV is one way to perform anti-replay protection. It could be the
>>way >>OSCORE performs anti replay protection but this is not the only way to
>>do. In >>addition, incrementing the Partial IV result in the IV being
>>predictible. >>This >>condition may not be sufficient as some algorithm may require the IV
>>being >>unpredictable. I believe Anti-Replay Type shoudl be configurable, and
>>some note >>shoudl be added to comply with the encryption being used. </mglt> > >[GS:] We are mainly concerned about encryption algorithms and replay
>mechanisms that are suitable for IoT deployments in general and
>constrained environments in particular. Please give an example of a
>relevant algorithm where you think the current specification is too
>restrictive. <mglt2> IPsec typically does not necessarily increment the SSN, but here you are following mcgrew-iv-gen. I appreciated this has been clearly added. I believe that is clearer – at least to me.
AES-CBC requires the IV to be unpredictable. I appreciated you added in the security consideration that unpredictable IV are not supported by this draft.</mglt2> >> >> Responses (with or without Partial IV) are protected against replay >> as they are bound to the request and the fact that only a single >> response is accepted. Note that the Partial IV is not used for >> replay protection in this case. >> >> The operation of validating the Partial IV and updating the replay >> protection MUST be atomic. >> >>7.4.1. Replay Protection of Notifications >>7.5. Losing Part of the Context State >> >> To prevent reuse of an AEAD nonce with the same key, or from >> accepting replayed messages, an endpoint needs to handle the >> situation of losing rapidly changing parts of the context, such as >> the request Token, Sender Sequence Number, Replay Window, and >> Notification Numbers. These are typically stored in RAM and >> therefore lost in the case of an unplanned reboot. >> >> After boot, an endpoint can either use a persistently stored complete >> or partial security context, or establish a new security context with >> each endpoint it communicates with. However, establishing a fresh >> security context may have a non-negligible cost in terms of, e.g., >> power consumption. >> >> If the endpoint uses a persistently stored partial security context, >> it MUST NOT reuse a previous Sender Sequence Number and MUST NOT >> >>Selander, et al. Expires January 27, 2019 [Page 34] >> >>Internet-Draft OSCORE July 2018 >> >> accept previously received messages. Some ways to achieve this are >> described in the following sections. >> >>7.5.1. Sequence Number >> >> To prevent reuse of Sender Sequence Numbers, an endpoint may perform >> the following procedure during normal operations: >> >> o Before using a Sender Sequence Number that is evenly divisible by >> K, where K is a positive integer, store the Sender Sequence Number >> in persistent memory. After boot, the endpoint initiates the >> Sender Sequence Number to the value stored in persistent memory + >> K. Storing to persistent memory can be costly. The value K gives >> a trade-off between the number of storage operations and efficient >> use of Sender Sequence Numbers. >> >><mglt> >>I have hard time reading the section above. I guess K is a parameter
>>known by >>OSCORE. My understanding is that SSN=0 ... K-1 are stored in persistent
>>memory. >>After boot SSN = SSN + K. >> >>I might be wrong but as storage in persistent memory is costly. Given K a >>parameter defined by the implementation. I would rather store F =
>>floor(SSN / K >>). SSN = F.K + ssn with ssn = 0... K-1, so a storage operation happens
>>every K. >>In case of reboot, SSN = (F + 1).K + ssn. >> >>This ends in a jump of maximum K and anti replay must be able to handle
>>this. >></mglt> > >[GS:] K is a the parameter determining how often you need to store to
>persistent memory, and how many sequence numbers you may “lose” in case
>of >reboot. Only one SSN is stored in persistent memory, and that number is
>being overwritten when a new multiple of K is reached. After reboot, the
>sequence number is set to SSN + K to prevent use of any number between
>the >last stored SSN and the next multiple of K. Is this more clear: >OLD > o Before using a Sender Sequence Number that is evenly divisible by > K, where K is a positive integer, store the Sender Sequence Number > in persistent memory. >NEW > o Before using a Sender Sequence Number that is evenly divisible by > K, where K is a positive integer, store/overwrite the Sender
>Sequence Number > in persistent memory. > <mglt2> OK I got it. </mglt2> > > > >> >>7.5.2. Replay Window >>7.5.3. Replay of Notifications >>8. Processing >> >> This section describes the OSCORE message processing. Additional >> processing for Observe or Block-wise are described in subsections. >> >> Note that, analogously to [RFC7252] where the Token and source/ >> destination pair are used to match a response with a request, both >> endpoints MUST keep the association (Token, {Security Context, >> >>Selander, et al. Expires January 27, 2019 [Page 35] >> >>Internet-Draft OSCORE July 2018 >> >> Partial IV of the request}), in order to be able to find the Security >> Context and compute the AAD to protect or verify the response. The >> association MAY be forgotten after it has been used to successfully >> protect or verify the response, with the exception of Observe >> processing, where the association MUST be kept as long as the >> Observation is active. >> >>8.1. Protecting the Request >> >> Given a CoAP request, the client SHALL perform the following steps to >> create an OSCORE request: >> >> 1. Retrieve the Sender Context associated with the target resource. >> >> 2. Compose the Additional Authenticated Data and the plaintext, as >> described in Sections 5.3 and 5.4. >> >> 3. Encode the Partial IV (Sender Sequence Number in network byte >> order) and increment the Sender Sequence Number by one. >><mglt> >>I believe this depends on the Anti-replay type. >></mglt> > >[GS:] As mentioned above, until it is demonstrated to be a too
>restrictive >assumption I would like to assume that the sequential increment of
>Partial IV/SSN is >sufficient for the relevant encryption algorithm and replay protection
>mechanism in use. <mglt2> I believe that is fine. Maybe when I read the draft I had the impression we were willing to be able to extend this. I do not think that is necessary.
</mglt2> > >> Compute >> the AEAD nonce from the Sender ID, Common IV, and Partial IV as >> described in Section 5.2. >> >> 4. Encrypt the COSE object using the Sender Key. Compress the COSE >> Object as specified in Section 6. >> >> 5. Format the OSCORE message according to Section 4. The OSCORE >> option is added (see Section 4.1.2). >> >>8.2. Verifying the Request >> >> A server receiving a request containing the OSCORE option SHALL >> perform the following steps: >> >> 1. Discard Code and all class E options (marked in Figure 5 with 'x' >> in column E) present in the received message. For example, an >> If-Match Outer option is discarded, but an Uri-Host Outer option >> is not discarded. >> >> 2. Decompress the COSE Object (Section 6) and retrieve the Recipient >> Context associated with the Recipient ID in the 'kid' parameter, >> additionally using the 'kid context', if present. If either the >> decompression or the COSE message fails to decode, or the server >> fails to retrieve a Recipient Context with Recipient ID >> corresponding to the 'kid' parameter received, then the server >> SHALL stop processing the request. >> >> * If either the decompression or the COSE message fails to >> decode, the server MAY respond with a 4.02 Bad Option error >> >>Selander, et al. Expires January 27, 2019 [Page 36] >> >>Internet-Draft OSCORE July 2018 >> >> message. The server MAY set an Outer Max-Age option with >> value zero. The diagnostic payload SHOULD contain the string >> "Failed to decode COSE". >> >> * If the server fails to retrieve a Recipient Context with >> Recipient ID corresponding to the 'kid' parameter received, >> the server MAY respond with a 4.01 Unauthorized error message. >> The server MAY set an Outer Max-Age option with value zero. >> The diagnostic payload SHOULD contain the string "Security >> context not found". >> >> 3. Verify the 'Partial IV' parameter using the Replay Window, as >> described in Section 7.4. >><mglt> >>My understanding is that the Partial IV value has not been
>>authenticated. >>Thus >>I believe this step mostly consists in discarding packets with irrelevant >>Partial IV values. Here irrelevant are limited to repeated sequence
>>numbers >>that is too say known replayed packets. <mglt> > >[GS:] The term “verify” refers to the text in >section 7.4 "verify that a Partial IV received in the COSE object has not
>been received before.” We can copy over that text to avoid
>misunderstanding: >OLD >3. Verify the 'Partial IV' parameter using the Replay Window, as >described in Section 7.4. >NEW >3. Verify that the 'Partial IV’ has not been received before using the
>Replay Window, as described in Section 7.4. > > <mglt2> OK thanks. </mglt2> >> >> 4. Compose the Additional Authenticated Data, as described in >> Section 5.4. >> >> 5. Compute the AEAD nonce from the Recipient ID, Common IV, and the >> 'Partial IV' parameter, received in the COSE Object. >> >> 6. 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 >> request and MAY respond with a 4.00 Bad Request error message. >> The server MAY set an Outer Max-Age option with value zero. >> The diagnostic payload MAY contain the "Decryption failed" >> string. >> >> * If decryption succeeds, update the Replay Window, as described >> in Section 7. >> >> 7. Add decrypted Code, options, and payload to the decrypted >> request. The OSCORE option is removed. >> >> 8. The decrypted CoAP request is processed according to [RFC7252]. >> >>8.2.1. Supporting Block-wise >>8.3. Protecting the Response >> >> If a CoAP response is generated in response to an OSCORE request, the >> server SHALL perform the following steps to create an OSCORE >> response. Note that CoAP error responses derived from CoAP >> processing (step 8 in Section 8.2) are protected, as well as >> successful CoAP responses, while the OSCORE errors (steps 2, 3, and 6 >> in Section 8.2) do not follow the processing below, but are sent as >> simple CoAP responses, without OSCORE processing. >> >> 1. Retrieve the Sender Context in the Security Context associated >> with the Token. >> >> 2. Compose the Additional Authenticated Data and the plaintext, as >> described in Sections 5.3 and 5.4. >> >> 3. Compute the AEAD nonce as described in Section 5.2: >> >> * Either use the nonce from the request, or >> >> * Encode the Partial IV (Sender Sequence Number in network byte >> order) and increment the Sender Sequence Number by one. >><mglt> >>Again this is very specific. >> >>I am reading that SSN is incremented after the Partial IV is generated.
>>It >>seems to me that the Partial IV should reflect the SSN, and as such being >>encoded after the incrementation of the SSN. </mglt> > >[GS:] The Partial IV does reflect the SSN. As the procedure is currently
>described (initialised to zero etc.) the SSN needs to be incremented
>after >use, not before. Please show by example where you think this goes wrong. > <mglt2> I was reading it the wrong way, but wit your convention that is clearer. I also believe that incrementation can be done before or after sending the packet.
</mglt2> > > >> Compute the AEAD nonce from the Sender ID, Common IV, and >> Partial IV. >> >> 4. Encrypt the COSE object using the Sender Key. Compress the COSE >> Object as specified in Section 6. If the AEAD nonce was >> constructed from a new Partial IV, this Partial IV MUST be >> included in the message. If the AEAD nonce from the request was >> used, the Partial IV MUST NOT be included in the message. >> >> 5. Format the OSCORE message according to Section 4. The OSCORE >> option is added (see Section 4.1.2). >> >>8.3.1. Supporting Observe >>8.4. Verifying the Response >>9. Web Linking >>10. CoAP-to-CoAP Forwarding Proxy >>11. HTTP Operations >>11.2. CoAP-to-HTTP Mapping >>11.3. HTTP-to-CoAP Mapping >>11.4. HTTP Endpoints >>11.5. Example: HTTP Client and CoAP Server >>11.6. Example: CoAP Client and HTTP Server >>12. Security Considerations >> >> An overview of the security properties is given in Appendix D. >> >>12.1. End-to-end Protection >> >> In scenarios with intermediary nodes such as proxies or gateways, >> transport layer security such as (D)TLS only protects data hop-by- >> hop. As a consequence, the intermediary nodes can read and modify >> any information. The trust model where all intermediary nodes are >> considered trustworthy is problematic, not only from a privacy >> perspective, but also from a security perspective, as the >> intermediaries are free to delete resources on sensors and falsify >> commands to actuators (such as "unlock door", "start fire alarm", >> "raise bridge"). Even in the rare cases where all the owners of the >> intermediary nodes are fully trusted, attacks and data breaches make >> such an architecture brittle. >> >> (D)TLS protects hop-by-hop the entire message. OSCORE protects end- >> to-end all information that is not required for proxy operations (see >> Section 4). (D)TLS and OSCORE can be combined, thereby enabling end- >> to-end security of the message payload, in combination with hop-by- >> hop protection of the entire message, during transport between end- >> point and intermediary node. In particular when OSCORE is used with >> >>Selander, et al. Expires January 27, 2019 [Page 47] >> >>Internet-Draft OSCORE July 2018 >> >> HTTP, the additional TLS protection of HTTP hops is recommended, e.g. >> between an HTTP endpoint and a proxy translating between HTTP and >> CoAP. >> >><mglt> >>I see that (D)TLS provides privacy to OSCORE communication, while OSCORE >>protects the data. </mglt> > > >[GS:] I didn’t understand this comment. The difference in protection
>between (D)TLS and OSCORE is certain CoAP header fields. This has
>implications both on privacy and "protection of data" as is described in
>Sections 12.8 and Appendix D.2. Similarly, if proxy functionality
>requires >DTLS to be terminated in a middlebox it neither provides privacy nor data
>protection in that node. > > <mglt2> Agree this was only a comment. </mglt2> >> >> Applications need to consider that certain message fields and >> messages types are not protected end-to-end and may be spoofed or >> manipulated. The consequences of unprotected message fields are >> analyzed in Appendix D.4. >> >>12.2. Security Context Establishment >> >><mglt> >>Wouldn't agreement preferred to established ? >></mglt> > >[GS:] I don’t know if there is a right word here. IMHO “agreement" seems
>to indicate some sort of negotiation, but in practice this could just be
>a >provisioning step which makes that term less appropriate. > > <mglt2> I am fine either ways 😉 </mglt2> > The use of COSE_Encrypt0 and AEAD to protect messages as specified in > this document requires an established security context. The method > to establish the security context described in Section 3.2 is based > on a common Master Secret and unique Sender IDs. The necessary input > parameters may be pre-established or obtained using a key > establishment protocol augmented with establishment of Sender/ > Recipient ID such as the OSCORE profile of the ACE framework > [I-D.ietf-ace-oscore-profile]. Such a procedure must ensure that the > requirements of the security context parameters for the intended use > are complied with (see Section 3.3) and also in error situations. It > is recommended to use a key establishment protocol which provides > forward secrecy whenever possible. Considerations for deploying > OSCORE with a fixed Master Secret are given in Appendix B. > >12.3. Master Secret > > OSCORE uses HKDF [RFC5869] and the established input parameters to > derive the security context. The required properties of the security > context parameters are discussed in Section 3.3, in this section we > focus on the Master Secret. HKDF denotes in this specification the > composition of the expand and extract functions as defined in > [RFC5869] and the Master Secret is used as Input Key Material (IKM). > > Informally, HKDF takes as source an IKM containing some good amount > of randomness but not necessarily distributed uniformly (or for which > an attacker has some partial knowledge) and derive from it one or > more cryptographically strong secret keys [RFC5869]. ><mglt> >rfc4086 may be a usefull reference. ></mglt> > >[GS:] Sure, I add that reference to the end of the section. > <mglt2> Thanks. </mglt2> > > Therefore, the main requirement for the OSCORE Master Secret, in > addition to being secret, is that it is has a good amount of > randomness. The selected key establishment schemes must ensure that > the necessary properties for the Master Secret are fulfilled. For > pre-shared key deployments and key transport solutions such as > [I-D.ietf-ace-oscore-profile], the Master Secret can be generated > offline using a good random number generator. > >Selander, et al. Expires January 27, 2019 [Page 48] > >Internet-Draft OSCORE July 2018 > >12.4. Replay Protection > > Replay attacks need to be considered in different parts of the > implementation. Most AEAD algorithms require a unique nonce for each > message, for which the sender sequence numbers in the COSE message > field 'Partial IV' is used. If the recipient accepts any sequence > number larger than the one previously received, then the problem of > sequence number synchronization is avoided. ><mglt> >Do we have cases where the Partial IV represents the LSB of the SSN ? If
>that >is the case, if more then len(Partial IV) packet have been dropped. The
>two >peers may have hard time to resynchronize their SSN. This may happen in a >communication with a lot of notifications. In a query-response paradigm,
>the >sender may have some hints when the packet has been receieved or not.
></mglt> > > >[GS:] I didn’t really understand the issue. Section 5 states that the
>partial IV "is set to >the Sender Sequence Number. All leading bytes of value zero >SHALL be removed when encoding the Partial IV, except in the case of
>Partial IV of value 0 which is encoded to the byte string 0x00.” >So the only thing truncated is potentially the leading zeros, but not in
>all cases. Does that answer the question? Is the issue still relevant? > <mglt2> If SSN == Partial IV, my comment is irrelevant, then.
</mglt2> > > > >With reliable transport, > it may be defined that only messages with sequence number which are > equal to previous sequence number + 1 are accepted. An adversary may > try to induce a device reboot for the purpose of replaying a message > (see Section 7.5). > > Note that sharing a security context between servers may open up for > replay attacks, for example if the replay windows are not > synchronized. > >12.5. Client Aliveness > > A verified OSCORE request enables the server to verify the identity > of the entity who generated the message. However, it does not verify > that the client is currently involved in the communication, since the > message may be a delayed delivery of a previously generated request > which now reaches the server. To verify the aliveness of the client > the server may use the Echo option in the response to a request from > the client (see [I-D.ietf-core-echo-request-tag]). > >12.6. Cryptographic Considerations > > The maximum sender sequence number is dependent on the AEAD > algorithm. The maximum sender sequence number is 2^40 - 1, or any > algorithm specific lower limit, after which a new security context > must be generated. The mechanism to build the nonce (Section 5.2) > assumes that the nonce is at least 56 bits, and the Partial IV is at > most 40 bits. The mandatory-to-implement AEAD algorithm AES-CCM- > 16-64-128 is selected for compatibility with CCM*. > > In order to prevent cryptanalysis when the same plaintext is > repeatedly encrypted by many different users with distinct keys, the > nonce is formed by mixing the sequence number with a secret per- > context initialization vector (Common IV) derived along with the keys > (see Section 3.1 of [RFC8152]), and by using a Master Salt in the key > derivation (see [MF00] for an overview). The Master Secret, Sender > Key, Recipient Key, and Common IV must be secret, the rest of the > parameters may be public. The Master Secret must have a good amount > of randomness (see Section 12.3). > >Selander, et al. Expires January 27, 2019 [Page 49] > >Internet-Draft OSCORE July 2018 > >12.7. Message Segmentation > > The Inner Block options enable the sender to split large messages > into OSCORE-protected blocks such that the receiving endpoint can > verify blocks before having received the complete message. The Outer > Block options allow for arbitrary proxy fragmentation operations that > cannot be verified by the endpoints, but can by policy be restricted > in size since the Inner Block options allow for secure fragmentation > of very large messages. A maximum message size (above which the > sending endpoint fragments the message and the receiving endpoint > discards the message, if complying to the policy) may be obtained as > part of normal resource discovery. > >12.8. Privacy Considerations > > Privacy threats executed through intermediary nodes are considerably > reduced by means of OSCORE. End-to-end integrity protection and > encryption of the message payload and all options that are not used > for proxy operations, provide mitigation against attacks on sensor > and actuator communication, which may have a direct impact on the > personal sphere. > > The unprotected options (Figure 5) may reveal privacy sensitive > information, see Appendix D.4. CoAP headers sent in plaintext allow, > for example, matching of CON and ACK (CoAP Message Identifier), > matching of request and responses (Token) and traffic analysis. > OSCORE does not provide protection for HTTP header fields which are > not both CoAP-mappable and class E. The HTTP message fields which > are visible to on-path entity are only used for the purpose of > transporting the OSCORE message, whereas the application layer > message is encoded in CoAP and encrypted. > > COSE message fields, i.e. the OSCORE option, may reveal information > about the communicating endpoints. E.g. 'kid' and 'kid context', > which are intended to help the server find the right context, may > reveal information about the client. Tracking 'kid' and 'kid > context' to one server may be used for correlating requests from one > client. > > Unprotected error messages reveal information about the security > state in the communication between the endpoints. Unprotected > signaling messages reveal information about the reliable transport > 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 > be mitigated by the device storing the precise state of sender > sequence number and replay window on a clean shutdown. > >Selander, et al. Expires January 27, 2019 [Page 50] > >Internet-Draft OSCORE July 2018 > > The length of message fields can reveal information about the > message. Applications may use a padding scheme to protect against > traffic analysis. > >13. IANA Considerations >14. References >Appendix A. Scenario Examples >Appendix B. Deployment Examples >B.1. Master Secret Used Once > > An application may derive a security context once and use it for the > lifetime of a device. For many IoT deployments, a 128 bit uniformly > random Master Key is sufficient for encrypting all data exchanged > with the IoT device. This specification describes techniques for > persistent storage of the security context and synchronization of > sequence numbers (see Section 7.5) to ensure that security is > maintained with the existing security context. > >B.2. Master Secret Used Multiple Times > > Section 12.2 recommends the use of a key establishment protocol > providing forward secrecy of the Master Secret. ><mglt> >I believe that forward secrecy is a property associated to the kex. I am >reading it as associated to the Master Secret. That said, English is not
>my >native language. </mglt> >[GS:] Correct. New formulation: >NEW >Section 12.2 recommends that the Master Secret is obtained from a key
>establishment protocol > providing forward secrecy. > > <mglt2> Thanks. </mglt2> > > An application which does not require forward secrecy may allow > multiple security contexts to be derived from one Master Secret. The > requirements on the security context parameters must be fulfilled > (Section 3.3) even if the client or server is rebooted, > recommissioned or in error cases. > > This section gives an example of an application allowing new security > contexts to be derived from input parameters pre-established between > client and server for this purpose: in particular Master Secret, > Master Salt and Sender/Recipient ID (see Section 3.2): > > o The client generates an ID Context which has previously not been > used with the pre-established input parameters and derives a new > security context. ID context may be pseudo-random and large for > >Selander, et al. Expires January 27, 2019 [Page 62] > >Internet-Draft OSCORE July 2018 > > stochastic uniqueness, but care must be taken e.g. to avoid re-use > of the same seed for random number generation. Using this new > security context, the client generates an OSCORE request with (kid > context, kid) = (ID Context, Sender ID) in the OSCORE option. > > o The server receiving such an OSCORE request with kid matching the > Recipient ID of pre-established input parameters, but with a new > kid context, derives the security context using ID Context = kid > context. If the message verifies then a new security context with > this ID Context is stored in the server, and used in the response. > Further requests with the same (kid context, kid) are verified > with this security context. > > As an alternative procedure to reduce the subsequent overhead in > requests due to kid context, the verification of a message with a new > ID Context may trigger the server to generate a new kid to replace > the Client Sender ID in future requests. A client may e.g. indicate > support for such a procedure by requesting a special well-known URI > and receive the new kid in the response, which together with the > input parameters and the ID context is used to derive the new > security context which may be identified only by its kid. The > details are out of scope for this specification. > > The procedures may be complemented with the use of the Echo option > for verifying the aliveness of the client requesting a new security > context. > >Appendix C. Test Vectors >Appendix D. Overview of Security Properties > >D.1. Supporting Proxy Operations > > CoAP is designed to work with intermediaries reading and/or changing > CoAP message fields to perform supporting operations in constrained > environments, e.g. forwarding and cross-protocol translations. > > Securing CoAP on transport layer protects the entire message between > the endpoints in which case CoAP proxy operations are not possible. > In order to enable proxy operations, security on transport layer > needs to be terminated at the proxy in which case the CoAP message in > its entirety is unprotected in the proxy. > > Requirements for CoAP end-to-end security are specified in > [I-D.hartke-core-e2e-security-reqs]. The client and server are > assumed to be honest, but proxies and gateways are only trusted to > perform their intended operations. ><mglt> >I expected after 'but' something saying the proxies are not trusted, but t >seems that everyone is honest here. maybe we should replace: OLD but
>proxies >and gateways are only trusted to > perform their intended operations. >NEW: >and proxies and gateways are trusted to > perform their intended operations. > >That the server is honest does not means that the node terminating the
>session >is the server.... </mglt> > >[GS:] Isn’t that too many “and” ;-). We can replace “but” with some other
>word, e.g. “while” to indicate that there is a difference. >NEW: >while proxies and gateways are only trusted to > perform their intended operations. > > > <mglt2> Maybe 😉 You wording is better.
</mglt2> > > > Forwarding is specified in > Section 2.2.1 of [I-D.hartke-core-e2e-security-reqs]. HTTP-CoAP > translation is specified in [RFC8075]. Intermediaries translating > between different transport layers are intended to perform just that. > > By working at the CoAP layer, OSCORE enables different CoAP message > fields to be protected differently, which allows message fields > required for proxy operations to be available to the proxy while > message fields intended for the other endpoint remain protected. In > the remainder of this section we analyze how OSCORE protects the > protected message fields and the consequences of message fields > intended for proxy operation being unprotected. ><mglt> >This text seems clear to me. Maybe the last paragraph could be sufficient. ></mglt> > >[GS:] Is the proposal to remove “Forwarding is specified . . . to
>perform >just that”? We could do that and replace this text with some references
>to >other parts of the document if that is desirable. > > <mglt2> Not really a proposal, more a suggestion
😉 I am fine either ways.
</mglt2> >D.2. Protected Message Fields > > > > Protected message fields are included in the Plaintext (Section 5.3) > and the Additional Authenticated Data (Section 5.4) of the > COSE_Encrypt0 object and encrypted using an AEAD algorithm. > > OSCORE depends on a pre-established random Master Secret > (Section 12.3) used to derive encryption keys, and a construction for > making (key, nonce) pairs unique (Appendix D.3). Assuming this is > true, and the keys are used for no more data than indicated in > Section 7.2.1, OSCORE should provide the following guarantees: > > o Confidentiality: An attacker should not be able to determine the > plaintext contents of a given OSCORE message or determine that > different plaintexts are related (Section 5.3). > >Selander, et al. Expires January 27, 2019 [Page 74] > >Internet-Draft OSCORE July 2018 > > o Integrity: An attacker should not be able to craft a new OSCORE > message with protected message fields different from an existing > OSCORE message which will be accepted by the receiver. > > o Request-response binding: An attacker should not be able to make a > client match a response to the wrong request. > > o Non-replayability: An attacker should not be able to cause the > receiver to accept a message which it has previously received and > accepted. > > In the above, the attacker is anyone except the endpoints, e.g. a > compromised intermediary. Informally, OSCORE provides these > properties by AEAD-protecting the plaintext with a strong key and > uniqueness of (key, nonce) pairs. AEAD encryption [RFC5116] provides > confidentiality and integrity for the data. Response-request binding > is provided by including the kid and Partial IV of the request in the > AAD of the response. Non-replayability of requests and notifications > is provided by using unique (key, nonce) pairs and a replay > protection mechanism (application dependent, see Section 7.4). > > OSCORE is susceptible to a variety of traffic analysis attacks based > on observing the length and timing of encrypted packets. OSCORE does > not provide any specific defenses against this form of attack but the > application may use a padding mechanism to prevent an attacker from > directly determine the length of the padding. However, information > about padding may still be revealed by side-channel attacks observing > differences in timing. > >D.3. Uniqueness of (key, nonce) > > In this section we show that (key, nonce) pairs are unique as long as > the requirements in Sections 3.3 and 7.2.1 are followed. > > Fix a Common Context (Section 3.1) and an endpoint, called the > encrypting endpoint. An endpoint may alternate between client and > server roles, but each endpoint always encrypts with the Sender Key > of its Sender Context. Sender Keys are (stochastically) unique since > they are derived with HKDF using unique Sender IDs, so messages > encrypted by different endpoints use different keys. It remains to > prove that the nonces used by the fixed endpoint are unique. > > Since the Common IV is fixed, the nonces are determined by a Partial > IV (PIV) and the Sender ID of the endpoint generating that Partial IV > (ID_PIV). The nonce construction (Section 5.2) with the size of the > ID_PIV (S) creates unique nonces for different (ID_PIV, PIV) pairs. > There are two cases: > >Selander, et al. Expires January 27, 2019 [Page 75] > >Internet-Draft OSCORE July 2018 > > A. For requests, and responses with Partial IV (e.g. Observe > notifications): > > o ID_PIV = Sender ID of the encrypting endpoint > > o PIV = current Partial IV of the encrypting endpoint > > Since the encrypting endpoint steps the Partial IV for each use, the > nonces used in case A are all unique as long as the number of > encrypted messages is kept within the required range (Section 7.2.1). > > B. For responses without Partial IV (e.g. single response to a > request): > > o ID_PIV = Sender ID of the endpoint generating the request > > o PIV = Partial IV of the request > > Since the Sender IDs are unique, ID_PIV is different from the Sender > ID of the encrypting endpoint. Therefore, the nonces in case B are > different compared to nonces in case A, where the encrypting endpoint > generated the Partial IV. Since the Partial IV of the request is > verified for replay (Section 7.4) associated to this Recipient > Context, PIV is unique for this ID_PIV, which makes all nonces in > case B distinct. > >D.4. Unprotected Message Fields > > This section lists and discusses issues with unprotected message > fields. > >D.4.1. CoAP Header Fields > > o Version. The CoAP version [RFC7252] is not expected to be > sensitive to disclose. Currently there is only one CoAP version > defined. A change of this parameter is potentially a denial-of- > service attack. Future versions of CoAP need to analyze attacks > to OSCORE protected messages due to an adversary changing the CoAP > version. > > o Token/Token Length. The Token field is a client-local identifier > for differentiating between concurrent requests [RFC7252]. An > eavesdropper reading the token can match requests to responses > which can be used in traffic analysis. In particular this is true > for notifications, where multiple responses are matched with one > request. CoAP proxies are allowed to change Token and Token > Length between UDP hops. However, modifications of Token and > Token Length during a UDP hop may become a denial-of-service > >Selander, et al. Expires January 27, 2019 [Page 76] > >Internet-Draft OSCORE July 2018 > > attack, since it may prevent the client to identify to which > request the response belongs or to find the correct information to > verify integrity of the response. ><mglt> >I am reading the text as. When the attacker is on-path, a long Token does
>not >prevents the attack based on a spoofed response. However, for an attacker
>that >is not on path, the attacker needs to guess the Token, and this can be >mitigated (partially) by increasing the Token size. Note that in the
>latest >case, a long Token should not be seen as a replacement for cryptographic >protection of the message. </mglt> > >[GS:] There seems to be a misunderstanding somewhere. There is no need
>for anyone to “guess the Token” since it is not encrypted. There is
>nothing hinted about Token being a “replacement for crypto”, so I don’t
>understand why anyone would be lead to think that. Token length is
>mentioned twice; in the next to last sentence - mentioning that CoAP
>proxies (legitimately) may change Token length; and in the last sentence
>- describing that an on-path attacker may modify the Token Length which
>either created mismatch between request and response or no match at all,
>which are both denial of service. Is it clearer in the following way? NEW >o Token/Token Length. The Token field is a client-local identifier >for differentiating between concurrent requests [RFC7252]. > > <mglt2> What I was trying to say is that if you want to spoof a response ( like in DNS) and you are not on path, you need to guess the Token. In that sense, the longer the safer. However, as for DNS, we should not rely
on this. </mglt2> > CoAP proxies are allowed to change Token and Token > > >Length between UDP hops. An > > >eavesdropper reading the token can match requests to responses > > >which can be used in traffic analysis. In particular this is true > > >for notifications, where multiple responses are matched with one > > >request. Modifications of Token and > > >Token Length by on-path attackers during a UDP hop may become a
>denial-of-service > > >attack, since it may prevent a client to identify to which > > >request the response belongs or to find the correct information to > > >verify integrity of the response. > > o Code. The Outer CoAP Code of an OSCORE message is POST or FETCH for requests with corresponding response codes. The use of FETCH reveals no more than what is revealed by the Outer Observe option. Changing the Outer Code may be a denial-of-service attack by causing errors in the proxy processing. o Type/Message ID. The Type/Message ID fields [RFC7252] reveal information about the UDP transport binding, e.g. an eavesdropper reading the Type or Message ID gain information about how UDP messages are related to each other. CoAP proxies are allowed to change Type and Message ID. These message fields are not present in CoAP over TCP [RFC8323], and does not impact the request/ response message. A change of these fields in a UDP hop is a denial-of-service attack. By sending an ACK, an attacker can make the endpoint believe that the other endpoint received the previous message. By sending a RST, an attacker may be able to cancel an observation, make one endpoint believe the other endpoint is alive, or make one endpoint endpoint believe that the other endpoint is missing some context. By changing a NON to a CON, the attacker can cause the receiving endpoint to respond to messages for which no response was requested. o Length. This field contain the length of the message [RFC8323] which may be used for traffic analysis. These message fields are not present in CoAP over UDP, and does not impact the request/ response message. A change of Length is a denial-of-service attack similar to changing TCP header fields. D.4.2. CoAP Options o Max-Age. The Outer Max-Age is set to zero to avoid unnecessary caching of OSCORE error responses. Changing this value thus may cause unnecessary caching. No additional information is carried with this option. o Proxy-Uri/Proxy-Scheme. These options are used in forward proxy deployments. With OSCORE, the Proxy-Uri option does not contain the Uri-Path/Uri-Query parts of the URI. The other parts of Proxy-Uri cannot be protected since they are allowed to be changed by a forward proxy. The server can verify what scheme is used in the last hop, but not what was requested by the client or what was used in previous hops. Selander, et al. Expires January 27, 2019 [Page 77] Internet-Draft OSCORE July 2018 o Uri-Host/Uri-Port. In forward proxy deployments, the Uri-Host/ Uri-Port may be changed by an adversary, and the application needs to handle the consequences of that (see Section 4.1.3.2). The Uri-Host may either be omitted, reveal information equivalent to that of the IP address or more privacy-sensitive information, which is discouraged. o Observe. The Outer Observe option is intended for a proxy to support forwarding of Observe messages, but is ignored by the endpoints since the Inner Observe determines the processing in the endpoints. Since the Partial IV provides absolute ordering of notifications it is not possible for an intermediary to spoof reordering (see Section 4.1.3.5). The absence of Partial IV, since only allowed for the first notification, does not prevent correct ordering of notifications. The size and distributions of notifications over time may reveal information about the content or nature of the notifications. Cancellations (Section 4.1.3.5.1) are not bound to the corresponding registrations in the same way responses are bound to requests in OSCORE (see Appendix D.2), but that does not open up for attacks based on mismatched cancellations, since [RFC7641] specifies that for cancellations to be accepted, all options except for ETags MUST be the same (see Section 3.6 of [RFC7641]). For different target resources, the OSCORE option is different, and even if the Token is modified to match a different observation, such a cancellation would not be accepted. o Block1/Block2/Size1/Size2. The Outer Block options enables fragmentation of OSCORE messages in addition to segmentation performed by the Inner Block options. The presence of these options indicates a large message being sent and the message size can be estimated and used for traffic analysis. Manipulating these options is a potential denial-of-service attack, e.g. injection of alleged Block fragments. The specification of a maximum size of message, MAX_UNFRAGMENTED_SIZE (Section 4.1.3.4.2), above which messages will be dropped, is intended as one measure to mitigate this kind of attack. o No-Response. The Outer No-Response option is used to support proxy functionality, specifically to avoid error transmissions from proxies to clients, and to avoid bandwidth reduction to servers by proxies applying congestion control when not receiving responses. Modifying or introducing this option is a potential denial-of-service attack against the proxy operations, but since the option has an Inner value its use can be securely agreed between the endpoints. The presence of this option is not expected to reveal any sensitive information about the message exchange. Selander, et al. Expires January 27, 2019 [Page 78] Internet-Draft OSCORE July 2018 o OSCORE. The OSCORE option contains information about the compressed COSE header. Changing this field may cause OSCORE verification to fail. D.4.3. Error and Signaling Messages Error messages occurring during CoAP processing are protected end-to- end. Error messages occurring during OSCORE processing are not always possible to protect, e.g. if the receiving endpoint cannot locate the right security context. For this setting, unprotected error messages are allowed as specified to prevent extensive retransmissions. Those error messages can be spoofed or manipulated, which is a potential denial-of-service attack. Signaling messages used in CoAP over TCP [RFC8323] are intended to be hop-by-hop; spoofing signaling messages can be used as a denial-of- service attack of a TCP connection. D.4.4. HTTP Message Fields In contrast to CoAP, where OSCORE does not protect header fields to enable CoAP-CoAP proxy operations, the use of OSCORE with HTTP is restricted to transporting a protected CoAP message over an HTTP hop. Any unprotected HTTP message fields may reveal information about the transport of the OSCORE message and enable various denial-of-service attacks. It is recommended to additionally use TLS [RFC5246] for HTTP hops, which enables encryption and integrity protection of headers, but still leaves some information for traffic analysis. Appendix E. CDDL Summary _______________________________________________ secdir mailing list secdir@xxxxxxxx https://www.ietf.org/mailman/listinfo/secdir wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview |
