idnits 2.17.1 draft-amsuess-lwig-oscore-00.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 April 2020) is 1458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-33 == Outdated reference: A later version (-19) exists of draft-ietf-ace-oscore-profile-10 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-08 -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LWIG C. Amsüss 3 Internet-Draft 29 April 2020 4 Intended status: Informational 5 Expires: 31 October 2020 7 OSCORE Implementation Guidance 8 draft-amsuess-lwig-oscore-00 10 Abstract 12 Object Security for Constrained RESTful Environments (OSCORE) is a 13 means of end-to-end protection of short request/response exchanges 14 for tiny devices, typically transported using the Constrained 15 Application Protocol (CoAP). This document aims to assist 16 implementers in leveraging the optimizations catered for by the 17 combination of CoAP and OSCORE, and by generally providing experience 18 from earlier implementations. 20 Discussion Venues 22 This note is to be removed before publishing as an RFC. 24 Discussion of this document takes place on the LWIG Working Group 25 mailing list (lwig@ietf.org), which is archived at 26 https://mailarchive.ietf.org/arch/browse/lwig/ 27 (https://mailarchive.ietf.org/arch/browse/lwig/). 29 Source for this draft and an issue tracker can be found at 30 https://gitlab.com/chrysn/lwig-oscore/ (https://gitlab.com/chrysn/ 31 lwig-oscore/). 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 31 October 2020. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Context: ACE, LAKE, OSCORE . . . . . . . . . . . . . . . . . 2 68 2.1. Example compositiions . . . . . . . . . . . . . . . . . . 4 69 2.1.1. Plain ACE-OSCORE . . . . . . . . . . . . . . . . . . 4 70 2.1.2. ACE with opportunistic LAKE . . . . . . . . . . . . . 5 71 3. Protocol Implementation . . . . . . . . . . . . . . . . . . . 5 72 3.1. Replay, freshness and safety . . . . . . . . . . . . . . 5 73 3.1.1. Background . . . . . . . . . . . . . . . . . . . . . 5 74 3.1.2. Optimization . . . . . . . . . . . . . . . . . . . . 6 75 3.1.3. Implementation . . . . . . . . . . . . . . . . . . . 7 76 3.1.4. Consequences for replay window recovery using Echo . 7 77 4. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 5. HKDFs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 80 6.1. Assessment of idempotency . . . . . . . . . . . . . . . . 9 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 8. Informative References . . . . . . . . . . . . . . . . . . . 9 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 [ See abstract for now ] 90 2. Context: ACE, LAKE, OSCORE 92 [ Is this LWIG material? In W3C terminology, this would go into a 93 "primer" document. ] 94 When OSCORE was specified, other parts of the ecosystem in which it 95 is commonly used were already planned, but not to the extent to be 96 fully referernced. This section gives a bigger picture of how 97 surrounding technologies can be combined, with the caveat that some 98 of them are still in development: 100 * OSCORE ([RFC8613]): 102 - needs a pre-provisioned key, key identifiers and some other 103 details on two communication parties 105 - needs to keep sequence numbers on both parties (therfore, the 106 same setup can only be rolled out once, ever) 108 - provides a secure communication channel between those parties 110 - does not provide any form of Perfect-Forward Secrecy (PFS) 112 - has optional provisions for using a secret more than once, with 113 randomness from both parties (Appendix B.2) 115 * ACE ([I-D.ietf-ace-oauth-authz]): 117 - needs pre-existing secure channels and pre-established trust 118 between communication parties and an Authorization Server (AS) 120 - provides tokens that encode some authorization on a Resource 121 Serve (RS) to Clients (C) 123 - can be started by unprotected resource access (which fails, 124 indicating the AS to get a token from) or from pre-established 125 audiences and scopes 127 * OSCORE profile for ACE ([I-D.ietf-ace-oscore-profile]): 129 - needs an ACE token (obtained by the Client at an AS, valid for 130 a particular Resource Server) 132 - takes randomness from both C and RS 134 - provides all the data to start OSCORE between C and RS 136 - ensures to C that RS is the RS it asked a token for from AS 138 - ensures to RS that C was authorized by the AS for whatever the 139 scope of the token is 141 * a LAKE (Lightweight Key Exchange), for example EDHOC (Ephemeral 142 Diffie-Hellman Over COSE, [I-D.selander-lake-edhoc]): 144 - needs any combination of credentials between two parties, not 145 necessarily pre-shared (can be certificates, raw public keys, 146 or pre-shared keys) 148 - provides a shared set of keys and other details sufficient to 149 start OSCORE between the parties 151 - provides Perfect-Forward Secrecy (PFS) 153 - ensures to both parties that the other party has provided the 154 indicated credentials 156 * BRSKI 158 - [ TBD ] 160 [ same could be done for Group OSCORE ] 162 2.1. Example compositiions 164 [ While I'm reasonably sure what I'm writing in this document is 165 correct, the following is wild speculation in the hope that ACE and 166 LAKE authors tell me better ] 168 2.1.1. Plain ACE-OSCORE 170 A client tries to access a resource over unprotected CoAP, but the 171 server requires credentials (and thus a secure connection). 173 On the initial unprotected request, the server responds 4.01 174 Unauthorized, and sends the client off to the AS with information 175 from the payload. 177 The client, which needs to have a pre-established association with 178 the AS (or establishes one using yet unspecified mechanisms on the 179 fly), obtains a token from it, posts it over the original unprotected 180 CoAP transport to the server, and from then on has an OSCORE context 181 with the server, over which it can request the resource successfully. 183 This is illustrated well in [I-D.ietf-ace-oscore-profile] Figure 1. 185 This combination has the advantage of not requiring any asymmetric 186 cryptography, but has the original request data unprotected, and the 187 AS can decrypt communication between C and RS if it intercepts their 188 first exchanged messages. 190 2.1.2. ACE with opportunistic LAKE 192 A client that tries to access a resource but does not want to reveal 193 the request details to passive eavesdroppers can run an EDHOC with 194 the origin server. Nothing else being preconfigured, it runs it on a 195 raw public key, and accepts any credentials from the server. (If a 196 set of root certificates of a public key infrastructure (PKI) is set, 197 it could require a certificate chain to the root certificates). 199 Inside that opportunistically encrypted channel, the client sends a 200 first request to the resource. If the server, as in the ACE-OSCORE 201 example, requires authorization, it can still reject the request and 202 send the client off to the AS with the same response. 204 The client obtains a token from the AS as before, but does not need 205 to generate a new OSCORE context from it (and thus does not use the 206 OSCORE profile for ACE). Instead, it can post the token to the 207 server in the existing EDHOC-created OSCORE context, and thus 208 upgrades the authorization set of that context. 210 This combination has the advantage of not sending any actual request 211 unprotected, but does not ensure to the client that the server has 212 any association with the AS. 214 Alternatively, it can use ACE-OSCORE when obtaining the token and 215 when posting it to the RS over the EDHOC-created OSCORE context to 216 obtain a new OSCORE context. 218 This combination has similar properties to the plain ACE-OSCORE, at 219 the cost of an asymmetric cryptography step, but protecting the 220 original request from passive eavesdroppers. 222 3. Protocol Implementation 224 3.1. Replay, freshness and safety 226 3.1.1. Background 228 [RFC8613] Section 7.4 says that the server "SHALL stop processing the 229 message" if that fails, [ and I'm in quite a pickle here because I'd 230 like to tell implementers that they can partially ignore that ]. 232 In OSCORE, replay protection serves two distinct purposes: 234 * To ensure that only one response is sent with no Partial IV 235 present to any given request Partial IV on a context - i.e., to 236 curb nonce reuse. 238 * To ensure that any action authorized by OSCORE protection on the 239 request is only executed once. 241 For the first purpose, that mandate is absolute: processing any 242 request a second time and responding with an absent Partial IV is a 243 severe security violation. It does not apply, however, if the server 244 chooses to encode an own Partial IV in the response in step 3 of 245 RFC8613 Section 8.3. 247 The relevance of the second purpose depends on the request and the 248 implememtation of the resource backing it. If the request is safe 249 (in the sense of [RFC7231] Section 4.2.1, i.e. it is a GET or FETCH), 250 or at least idempotent (i.e. PUT, DELETE or iPATCH), processing a 251 replay of it has no side effect on the server, and the only thing an 252 attacking replaying party could learn from another response is the 253 current content's length. 255 [ TBD: Talk about how this interacts with freshness. ] 257 3.1.2. Optimization 259 Combined, these open some space for legitimate processing of replays. 260 Opening up to such processing is beneficial to the server, as it 261 allows a common optimization to happen even on OSCORE messages: 262 [RFC7252] Section 4.5 allows relaxation on message deduplication for 263 idempotent requests, to the point where some implementations of CoAP 264 do not perform message deduplication at all and demand of their 265 applications to only implement idempotent behavior. 267 On platforms that perform selective optimizations, these 268 optimizations can free up memory otherwised used for deduplication 269 and retransmission, provided the operation's idempotency is 270 communicated to the OSCORE and CoAP implementation (which would, in 271 general, not be allowed to enact that optimization for the POST 272 requests OSCORE requests appear as). 274 On platforms that do not perform deduplication at all, this enables 275 the implementation of OSCORE in the first place. (Otherwise, any 276 lost response message results in an otherwise unactionable 4.01 277 Unauthorized error). 279 Intermediaries (proxies) have no justification for treating the POST 280 requests they see most OSCORE request as as idempotent; however [ and 281 this can not really be called "moving on the fringe of the 282 specification" because it's clearly exceeding it ], clients of a very 283 constrained proxy (which might not even be able to forward non- 284 idempotent requests at all) might still appreciate a presumed- 285 idempotent forwarding of OSCORE messages over a 5.05 Proxying Not 286 Supported. 288 3.1.3. Implementation 290 Ensuring that only one response without a Partial IV is ever sent to 291 a given request is of utmost importance when implementing this 292 optimization. 294 One way of doing this is to annotate the received nonce or partial IV 295 with a marker that indicates the usability as an elided response 296 Partial IV. That marker is originally unset when the Partial IV is 297 extracted from the request, and only ever gets set the very time that 298 sequence number gets removed from the replay window. The marker is 299 removed from the data structure when it is used in the encryption of 300 a message. Care must be taken when a nonce / Partial IV is copied to 301 only let the marker stay with one copy, and to unset it on the other 302 one. 304 Note that this aligns well with the typical other cases when 305 responses use an own Partial IV: 307 * In observations, the first response can be sent without a Partial 308 IV. Later notifications are built with AAD linked to the original 309 request's Partial IV, but that was copied over from the original 310 request's Partial IV and thus does not carry a marker any more. 312 * In responses that serve to recover the replay window as in 313 [RFC8613] Appendix B.1.2, the replay window is invalid when the 314 first response is generated, thus there is no marker to respond 315 without Partial IV. 317 3.1.4. Consequences for replay window recovery using Echo 319 [ This is maybe more corr-clar or even my own wishful thinking than 320 actual implementation guidance. ] 322 For the first response to the replay window recovery of [RFC8613] 323 Appendix B.1.2, applying the above considerations means that the 324 server may not need to recover its replay window right away. 326 If the initial request that triggers the recovery process is 327 idempotent (for example, the typical initial GET to /.well-known/ 328 core), the server can accept the request as possible duplicate, and 329 send a successful response righ away. 331 The response should still contain an Echo value (and the client 332 should send the same Echo with the next request) for the benefit of 333 future non-idempotent operations and to eventually allow the server 334 to send shorter responses (without a Partial IV). 336 Only when a resource with freshness requirements is accessed, the 337 client needs to have included the Echo value in at latest that very 338 response. A 4.01 response (which incurs the additional round-trip) 339 thus only needs to happen if the first request that triggers recovery 340 is not idempotent. 342 4. Key IDs 344 The naming of Keys is a difficult matter, 345 it's not just one of your entropy games; 346 You may think at first I'm as mad as a hatter 347 When I tell you, a context needs space for its names. 349 [ 351 TBD. Topics: 353 * KID contexts are not strictly hierarchically above KIDs, that is 354 up to the KID: A device may have some KIDs that are KID-context 355 namespaced and will (at least initially) need a KID context, and 356 some that are B.2 and the KID context is more of a detail under 357 the KID than a namespace above. 359 * When ACE'ing with different ASs, or combining ACE with EDHOC, or 360 any of that with preconfigured keys, consider namespacing (eg. 361 dealing out a prefix-based group of KIDs to an AS) 363 - Generally recommend treating KIDs like URI paths - it's always 364 up to the server? 366 * Eventually avoid ever having to try different contexts, show it 367 can be done 369 ] 371 5. HKDFs 373 [ This is more of a corr-clar topic than a LWIG - still fits here? ] 375 [ TBD: Does it need to be HKDF? HMAC-based HKDF? What about other 376 direct+HKDFs in COSE ([I-D.ietf-core-oscore-groupcomm] may do some 377 updates here)? ] 379 [ Why and how do direct+ KDFs of COSE apply at all? My current 380 impression is: ] 382 When KDFs are referred to by identifier, they are usually identified 383 with the "direct+HKDF-..." COSE Algorithms. This makes sense as 384 those algorithms specify a particular key derivation function, but 385 also slightly misleading: What is meant by that usage is not to 386 actually apply the "Direct Key with KDF" algorthm of [RFC8152] ([ 387 what goes in as info there? ]) but to apply the OSCORE key derivation 388 process (with "[id, id_context, aead_alg, type, L]" as info). 390 6. Security Considerations 392 6.1. Assessment of idempotency 394 Getting all implications of processing an idempotent request without 395 an indication of freshness is hard. The topic has been discussed at 396 length in the context of TLS and HTTP/2 zero-round-trip actions [ but 397 I couldn't be bothered to find precise references for that yet ]. 399 [ Applications probably also need guidance as to what are the 400 temporal aspects or idempotency (a request that has the same effect 401 when processed twice in the same second, and different ones if 402 processed a day later - is it still idempotent then?), and on the re- 403 ordering of requests permitted by idempotency ("Just because you 404 received confirmation does not mean it can't be reordered with a 405 request you send later ... unless you put in a memory barrier?") ] 407 7. IANA Considerations 409 This document has no IANA actions. 411 8. Informative References 413 [I-D.ietf-ace-oauth-authz] 414 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 415 H. Tschofenig, "Authentication and Authorization for 416 Constrained Environments (ACE) using the OAuth 2.0 417 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 418 draft-ietf-ace-oauth-authz-33, 6 February 2020, 419 . 422 [I-D.ietf-ace-oscore-profile] 423 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 424 "OSCORE profile of the Authentication and Authorization 425 for Constrained Environments Framework", Work in Progress, 426 Internet-Draft, draft-ietf-ace-oscore-profile-10, 9 March 427 2020, . 430 [I-D.ietf-core-oscore-groupcomm] 431 Tiloca, M., Selander, G., Palombini, F., and J. Park, 432 "Group OSCORE - Secure Group Communication for CoAP", Work 433 in Progress, Internet-Draft, draft-ietf-core-oscore- 434 groupcomm-08, 6 April 2020, . 437 [I-D.selander-lake-edhoc] 438 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 439 Diffie-Hellman Over COSE (EDHOC)", Work in Progress, 440 Internet-Draft, draft-selander-lake-edhoc-01, 9 March 441 2020, . 444 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 445 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 446 DOI 10.17487/RFC7231, June 2014, 447 . 449 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 450 Application Protocol (CoAP)", RFC 7252, 451 DOI 10.17487/RFC7252, June 2014, 452 . 454 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 455 RFC 8152, DOI 10.17487/RFC8152, July 2017, 456 . 458 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 459 "Object Security for Constrained RESTful Environments 460 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 461 . 463 Acknowledgments 465 [ TBD put into text ] 467 OSCORE authors in general: discussion leading up to most of this 468 during OSCORE dev'mt FP: HKDF input 470 Author's Address 472 Christian Amsüss 474 Email: christian@amsuess.com