idnits 2.17.00 (12 Aug 2021) /tmp/idnits29049/draft-bormann-t2trg-sworn-05.txt: -(3): 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 3 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 document date (7 February 2022) is 96 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universität Bremen TZI 4 Intended status: Informational Y. Li 5 Expires: 11 August 2022 Huawei Technologies 6 7 February 2022 8 SWORN: Secure Wake on Radio Nudging 9 draft-bormann-t2trg-sworn-05 11 Abstract 13 Normally off devices (RFC7228) would need to expend considerable 14 energy resources to be reachable at all times. Instead, MAC layer 15 mechanisms are often employed that allow the last hop router of the 16 device to "wake" the device via radio when needed. Activating these 17 devices even for a short time still does expend energy and thus 18 should be available to authorized correspondents only. 19 Traditionally, this has been achieved by heavy firewalling, allowing 20 only authorized hosts to reach the device at all. This may be too 21 inflexible for an Internet of Things. 23 The present report describes how to use a combination of currently 24 standardized technologies to securely effect this authorization. 26 We also discuss how the general approach of the original SWORN 27 protocol can be extended to cover additional use cases and 28 implementation environments. 30 About This Document 32 This note is to be removed before publishing as an RFC. 34 Status information for this document may be found at 35 https://datatracker.ietf.org/doc/draft-bormann-t2trg-sworn/. 37 Discussion of this document takes place on the Thing-to-Thing (T2TRG) 38 Research Group mailing list (mailto:t2trg@irtf.org), which is 39 archived at https://mailarchive.ietf.org/arch/browse/t2trg/. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on 11 August 2022. 58 Copyright Notice 60 Copyright (c) 2022 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 65 license-info) in effect on the date of publication of this document. 66 Please review these documents carefully, as they describe your rights 67 and restrictions with respect to this document. Code Components 68 extracted from this document must include Revised BSD License text as 69 described in Section 4.e of the Trust Legal Provisions and are 70 provided without warranty as described in the Revised BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. The original SWORN proposal . . . . . . . . . . . . . . . . . 3 77 2.1. Assumptions and Requirements . . . . . . . . . . . . . . 3 78 2.2. Security goals . . . . . . . . . . . . . . . . . . . . . 4 79 2.3. Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.3.1. Wake-Grant . . . . . . . . . . . . . . . . . . . . . 5 81 2.3.2. Wake-Token . . . . . . . . . . . . . . . . . . . . . 5 82 2.3.3. Finding the wake token . . . . . . . . . . . . . . . 5 83 3. Generalizing SWORN towards Token-Based In-Network 84 Authorization . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1. Position of router R . . . . . . . . . . . . . . . . . . 7 86 3.2. Position of Token in Packet . . . . . . . . . . . . . . . 8 87 3.3. Range of Checking . . . . . . . . . . . . . . . . . . . . 8 88 3.4. Information (attributes) to be used on the way . . . . . 9 89 3.5. Example arrangements . . . . . . . . . . . . . . . . . . 10 90 3.5.1. Multiple Independent Grants . . . . . . . . . . . . . 11 91 3.5.2. Hierarchical Grants . . . . . . . . . . . . . . . . . 13 92 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 4.1. Original SWORN model . . . . . . . . . . . . . . . . . . 15 94 4.2. Generalized model . . . . . . . . . . . . . . . . . . . . 16 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 6.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 6.2. Informative References . . . . . . . . . . . . . . . . . 17 99 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Introduction 104 (See Abstract.) 106 1.1. Terminology 108 The term "byte" is used in its now customary sense as a synonym for 109 "octet". 111 Messages defined in this document employ CBOR [RFC8949] and are 112 described in CDDL [RFC8610]. 114 Terms used in this draft: 116 C: Client, or Correspondent host. The node that wants to effect 117 "Wake on Radio" on D by sending a message to D. 119 D: Device. This is typically battery operated and "Normally off" 120 [RFC7228]. 122 R: Router. The router that is adjacent to D, sharing an energy- 123 saving link with D, and serving as a ("parent") router to D. 125 MAC: Message Authentication Code (when discussing authentication 126 mechanisms) 128 MAC: Media Access Control (when discussing protocol layers) 130 2. The original SWORN proposal 132 2.1. Assumptions and Requirements 134 D is a normally off [RFC7228] device, waking up very briefly to 135 communicate with its first hop router R. R and D share a MAC layer 136 that allows R to keep D in extended wake periods. 138 R and D have a security association. (This may have been created in 139 network onboarding, or be setup dynamically from the device-to- 140 network security association when D chose R as a parent router.) 141 D wants to authorize a client (or correspondent host) C to ask R to 142 initiate wake periods in D. 144 Because of changes in the radio environment, D needs to be able to 145 change its parent router from R1 to R2 occasionally. This should not 146 cause a need to notify all its clients; which parent router is used 147 by D is therefore opaque to its clients as usual in IP. 149 2.2. Security goals 151 Since packets with wake tokens are kept in R for extended periods, 152 the limited size buffer provided in R for this is a resource that 153 needs to be protected to protect availability. 155 D uses up battery for a wake period, which would make it susceptible 156 to battery depletion attacks. To protect availability, D should only 157 undergo wake periods that R has commanded based on previous 158 authorization by D. 160 There may be confidentiality requirements (e.g., for privacy); this 161 is not addressed in the present version of this report. 163 2.3. Mechanism 165 +----------------+ . +----------------+ 166 | Client +-- 0 Share some context\. | Device | 167 | Authorization +-------. \_| Authorization + 168 | Manager CAM | \ | Manager DAM | 169 +------------+---+ \ +-------+----+---+ 170 ^ 1 Ask | 2 \ | 171 | for | Deliver \ | 172 | grant | grant | | 173 | v | | 174 +--+---------+---+ +--+----+----+---+ +--+----+----+---+ 175 | | | | | | 176 | Client C +--->| Router R +--->| Device D + 177 | | | | | | 178 +----------------+ +----------------+ +----------------+ 179 3 compute 4 send 5 verify 6 optionally send Token 181 Figure 1: Illustration of a potential setup with Authorization 182 Managers 184 2.3.1. Wake-Grant 186 A wake grant is a CWE [RFC8152], packaging a grant key, provided from 187 D or D's authorization manager to C. (Possibly the grant key can be 188 conveyed within a larger confidentiality protected data structure or 189 channel, such as a CWT [RFC8392] employing a cnf claim for the key 190 [RFC8747].) 192 A wake grant may then be used by C for initiating (a possibly limited 193 number or total duration of) wake periods, employing Wake-Tokens. 195 Information about the wake grant is also made available to R, so it 196 knows the grant key and the parameters of the wake grant. (Upon a 197 change of parent router, D will need to make that information 198 available to its new parent router as well.) 200 2.3.2. Wake-Token 202 A wake token is a CWS, in a COSE_MAC0 [RFC8152] message built with 203 the Wake-Grant's key, containing a CBOR data item of the form: 205 [serial: uint, wake-period: duration] 207 The CWS is additionally marked by tagging it with a CBOR tag 208 1398230866 (a value that becomes visible in a packet dump as ASCII 209 "SWOR"). 211 (Discussion: Should this be a CWE for confidentiality?) 213 The serial is used for replay detection, based on the usual window 214 mechanism. Wake-Tokens for a fresh wake grant start out with serial 215 numbers at zero. 217 A Wake-Token instructs R to use MAC mechanisms to provide an extended 218 wake period to D the next time it wakes up. 220 The wake token is sent from C to D; R finds it by examining packets 221 that it would need to forward to D. 223 2.3.3. Finding the wake token 225 As C is addressing D with the wake token, R needs to find it in 226 traffic purportedly for D. 228 As described in [I-D.bormann-intarea-alfi], this cannot be reasonably 229 done with IP options (which originally would have carried this kind 230 of information in the IP architecture). 232 Instead, R finds the wake token by deep packet inspection. The wake 233 token is found by a heuristic that may have false positives; this is 234 not a problem as the wake token is then verified by its MAC. 236 SWORN requests are carried in UDP packets that also may have a 237 payload function. To this end, they are conveyed as CoAP messages 238 [RFC7252]. The wake token is carried in a CoAP option, Wake-Token. 239 R can find the option by decoding the CoAP packet in the UDP payload 240 or simply by scanning for the 5-byte signature 0xda53574f52 created 241 by the CBOR wake token tag. Any potential wake token so found is 242 then validated as a CWS. 244 This works well with [RFC8613] as the CoAP security mechanism for any 245 payload function that this packet may have. To be able to use DTLS 246 as well, we define a media type "application/dtls-payload" that can 247 be used in a CoAP POST request to send a DTLS payload as payload of a 248 CoAP message (in other words, the CoAP POST request carries a Wake- 249 Token and a Content-Format option). (Any return packet can be 250 similarly sent back in the POST response.) (TODO: This media type 251 has to define the port number juggling needed.) 253 3. Generalizing SWORN towards Token-Based In-Network Authorization 255 The original SWORN protocol described so far was designed to solve a 256 specific use case in a specific implementation environment. 258 We can open up the design space in a number of dimensions, which will 259 be discussed in the following subsections. 261 The general idea of SWORN can be described as: 263 * giving a packet sender a way to send authenticating information 264 with the packet, 266 * that is not intended for the recipient of the packet, but instead 268 * to be checked at particular enforcement points on the way, 270 * which are not necessarily known by the sender, 272 * to derive authorization to forward. 274 Generalizing the terms used so far, we can identify the following 275 players and components: 277 * Packets P that require authorization (more generally, the reliable 278 derivation of attributes) by entities on their way, 280 * a sender (C) and a recipient (D), where the packets P go from C to 281 D, 283 * SWORN policy enforcement points (SPEPs) that are in the network in 284 places where the generalized SWORN authorization of and derivation 285 of attributes for the packets is performed; the ones that are 286 active for a packet P are called R, generalizing the concept of 287 the last-hop router R in the SWORN model, 289 * the "grant" G that provides setup information for the SPEP (wake 290 grant in SWORN), and 292 * the "token" T that is sent with a specific packet P to carry 293 information that will be checked by R/SPEP (wake token in SWORN). 295 This model can accommodate additional entities, "authorization 296 managers" (AM), that pair with C (CAM) and D (DAM) for purposes of 297 creating setup information and potentially distributing it among C 298 and D and to network elements that might play the role of R. The 299 distribution may be further facilitated by adding Router AMs (RAM). 301 The roles of C and D can also be played by tunnel ingress/egress 302 points; this can enable the use of unmodified client and device 303 implementations (note that D, if a DAM is used, need not implement 304 anything special at all, but can of course benefit from information 305 in the token). 307 3.1. Position of router R 309 The original SWORN protocol is based on a 6LoWPAN-like environment 310 where a host (D) has a defined relationship (often including a MAC 311 layer security association) to the last-hop router(s) (R) supplying 312 it with packets. This enables D to provide R with information about 313 wake grants in a secure way, or to delegate this to its authorization 314 manager. 316 Within a limited domain [RFC8799], routers that act as SWORN policy 317 enforcement points (SPEPs) may be known by configuration. Security 318 associations from D's authorization manager (DAM) to each such PEP 319 may be set up already, providing a way for DAM to broadcast policy 320 information to all such SPEPs. This enables policy distribution 321 without any involvement from D. 323 Alternatively, C can have a security association with the SPEPs 324 (possibly indirectly through a client authorization manager CAM) and 325 can send special SWORN probe packets towards D that carry grant 326 information that the SPEPs on the way can extract and copy into their 327 local (soft?) state. 329 A SPEP could also react to tokens it does not understand by asking 330 authorization managers for the applicable grant; this may be 331 facilitated by identifying information in a token such as a "key ID". 332 It remains a quality of implementation issue whether the packet can 333 be buffered while the relevant grant is obtained. (On-demand 334 retrieval of grants also adds an obvious attack vector.) 336 3.2. Position of Token in Packet 338 The original SWORN protocol goes to some lengths to avoid the need 339 for C to influence properties below the application layer of the 340 packets it sends. 342 However, routers may be able to provide more efficient 343 implementations of SWORN when the token information is in a header. 344 So if C has a platform API that could create/influence such a header, 345 this could be used instead. 347 While penultimate hop processing is in use in a number of 348 architectures (see, e.g., Section 3.16 of [RFC3031] or 349 [I-D.ietf-bier-php]), it is not currently part of the IPv6 350 architecture, so there is no obvious IPv6 header that could carry 351 this information. 353 3.3. Range of Checking 355 Tokens in the original SWORN protocol only check a serial number; 356 attackers might be able to extract such a token from a packet, 357 suppress the packet, and use the token in a different packet. We 358 call this form of attack "malicious reuse". Replay protection cannot 359 prevent this. 361 One way to reduce this attack vector is to make the grant very 362 specific to only a certain kind of packets, for instance by 363 effectively including an ACL (carrying, say, elements of the 5-tuple) 364 with the grant. (The grant could also include quantitative aspects, 365 such as a rate limit.) The cryptographic makeup of the grant then 366 must be such that a client cannot modify the ACL during generation of 367 a token from the grant. 369 Alternatively, some kinds of malicious reuse can be made harder to 370 perform by including more information in the signing input of the MAC 371 checked for a token. If a wake grant is shared between multiple 372 instances of D and C and therefore can only have a weak ACL, 373 including the source and destination addresses (IP address and 374 possibly port) in the signing input for a specific token T prevents 375 reuse of T for a different D/C pair. 377 Including the payload in the signing input (i.e., essentially 378 authenticating the entire packet) makes malicious reuse of tokens 379 less useful for an attacker as no new information can be injected by 380 it, but requires considerable processing power in the SPEP. We 381 assume that any authentication of the whole packet will most likely 382 be performed by its recipient D, based on a security association it 383 has with the sender C; R or any other SPEPs are not burdened with 384 this authentication. (However, some authentication offload in a 385 last-hop router R may be desirable for a very constrained device D, 386 at least if R and D have a robust security association that can 387 provide the level of authentication needed.) 389 Most likely, a token should include some information about what is 390 included in the signing input. (This information itself should then 391 also be included in the signing input.) This coverage information 392 could take the form of a bitmap, or of a set of offset-length pairs. 393 If coverage information and covered information is in a form that can 394 be processed by a network processor, higher processing and forwarding 395 rates can be achieved. 397 3.4. Information (attributes) to be used on the way 399 The original SWORN protocol provides one attribute beyond the 400 authentication itself: a wake period to be used in the MAC layer that 401 connects R and D. This can be generalized to other parameters that 402 control routing and forwarding, e.g., information that would be 403 equivalent to a DSCP. 405 An ambitious use case might be a path from a sender to a recipient 406 that crosses multiple domains, where each domain boundary normally 407 bleaches DSCP information coming in from the previous domain. 409 The domain ingress router might check the SWORN information to be 410 able to apply a policy not to bleach, or to install DSCP information 411 specific to the domain it belongs to, or to operate on some DSCP-like 412 information outside the DSCP field. 414 Note that the model used by this extended version of SWORN is based 415 on an assumption that it is in the interest of all players to 416 cooperate in achieving the objectives. Security is used to ensure 417 that only actually authorized players can participate. But, in 418 general, the assumed trust and incentive models work best within a 419 limited domain [RFC8799], which spans one or maybe two security 420 domains only. 422 3.5. Example arrangements 424 This subsection discusses a number of example arrangements with more 425 complex relationships between the players. Once the set of clients 426 starts to scale, the issue of key setup becomes significant. In the 427 best case, the SPEPs do not need to be provisioned (set up) 428 separately for each separate client authorization. 430 The arrangements presented here are based on symmetric cryptography, 431 specifically MACs (message authentication codes). The MACs are based 432 on grant keys GK shared between the origin or a packet (or of a grant 433 key, see below) and the enforcement point. Several grant keys may 434 need to be employed; they are differentiated in the names of 435 variables defined in this section by using suffixes such as _z for 436 authorization and _n for authentication, or _1 and _2 for consecutive 437 steps. 439 In these arrangements, grant keys are managed by "authorization 440 managers" (AM, compare Figure 1); we simplify the discussion by 441 mentioning only the client authorization manager (CAM), which 442 actually may be in contact with other authorization managers closer 443 to the SPEPs. Some grant keys are shared only between CAM and the 444 SPEPs, requiring the CAM to send a pre-computed MAC to the client; 445 some grant keys are shared between CAM, Client C, and the SPEPs, 446 allowing the client to compute MACs covering variable parts of the 447 packets. 449 The MACs of the example arrangements employ a mechanism to indicate 450 which parts of the packet go into the signing input for the MAC, the 451 _coverage area indication_, or cai for short, to be included in each 452 actual packet. The realization for this could contain a bitmap with 453 bits that enable individual predefined fields (e.g., elements of the 454 5-tuple), plus pointer/length information for the payload or other 455 dynamic attributes that need to be checked. As discussed above, the 456 coverage area indication itself should also go into the signing input 457 for the MAC. 459 The notation "fields(cai_x)" stands for the actual content of the 460 fields in the packet as enumerated by the coverage area indication 461 cai_x. If these fields are constant for the authorization conveyed 462 by a grant key (as is often required by an ACL), they can be included 463 in the derivation of the grant key; otherwise they are included in 464 the computation of the MAC keyed by the grant key. 466 Multiple MACs (based on a cai per MAC and separate GK) can be used in 467 each packet. This can be realized by including all of these MACs in 468 a packet (possibly by simply XORing them), or by building one of the 469 MACs into the signing input of another MAC. 471 We make the simplifying assumption that the IP address of the client 472 can be used as a client ID; this is always available in the 5-tuple 473 of the packet and can be included in a MAC via the coverage area 474 indication. We use Cx (C1, C2, ...) to discuss a specific client. 476 Based on these common mechanisms, we discuss two arrangements in the 477 rest of this section. Other arrangements can be built; the 478 information in the grants should enable the indication of the exact 479 structure of the arrangement, enabling the AM to determine which 480 specific arrangement is in use. 482 3.5.1. Multiple Independent Grants 484 In this example arrangement, the AM generates two different kinds of 485 grants, GK_z for authorization checking over a range of clients, and 486 GK_n_x that focuses only on authenticating the packet as originating 487 from a specific client Cx. 489 The corresponding MACs are used as follows: MAC_z contains 490 information that the AM wants to define, i.e. AM sets the values of 491 these fields; therefore MAC_z can be pre-computed by the AM. MAC_n 492 also contains information that the AM wants Cx to define, i.e. AM 493 identifies the fields (sets cai) and lets Cx set the values of these 494 fields. (As an example, the wake_period of original SWORN would be 495 in MAC_n.) 497 GK_z is not provided to the clients, instead the CAM provides the 498 client with a ready-made token complete with a MAC, called MAC_z, 499 based on the grant key. This token indicates authorization for its 500 coverage area (typically elements of the 5-tuple, plus possibly some 501 more dynamic attributes). It is pre-computed for each client Cx and 502 conveyed to Cx from the CAM; as there is no replay protection of the 503 authorization, this token can be used essentially as a bearer token, 504 until dynamic attributes or keys need to be updated (then a new 505 authorization token needs to be sent from CAM to each Cx that shall 506 continue to communicate). 508 The SPEP also has GK_z and can check the tokens based on the 509 information in the packet (and possibly cache e.g. MAC_z for the 510 flow, if not pre-computed from a table of client IDs). 512 This approach alone does not protect against replay attacks. For 513 this, we introduce GK_n_x in corresponding client grants, carrying a 514 client-specific authentication key. Each GK_n_x is provided by the 515 CAM to both an individual Cx and (indirectly via GK_z) to the SPEPs. 516 The authentication key is used against a selected subset of the five- 517 tuple, the dynamic attributes, and the payload. It effectively 518 proves that the holder of this key, Cx, is the actual originator of 519 the packet. It does not prove authorization of a specific five-tuple 520 plus attributes; this is the job of the GK_z/MAC_z. 522 Each packet carries MAC_z based on the shared grant key (bearer token 523 supplied by CAM for a specific selection of elements from the 524 5-tuple, proving that this communication with this selection of 525 5-tuple elements is generally authorized.) A typical selection from 526 the 5-tuple would comprise the source (client) and destination 527 (device) IP addresses as well as the destination port number and 528 protocol; the source port number would remain dynamic to be chosen by 529 the client in this case. (MAC_z could also cover further attributes 530 relevant to the authorization, such as an application-id or 531 performance parameters such as intended maximum bitrate and traffic 532 priority; some of these attributes could be included in the token, 533 others could be derived from policy and an attribute such as an 534 application-id.) 536 We assume that the mechanisms discussed here need to provide source 537 authentication for the packets from Cx. If a separate source 538 authentication mechanism is available, GK_n_x and MAC_n are not 539 needed. Otherwise, for authentication, each packet also carries 540 MAC_n based on GK_n_x, which proves the actual origin of the packet; 541 the authorization that applies to the packet needs to be checked via 542 the authorization token. The coverage area of MAC_n is indicated by 543 cai_n; this will generally be a superset of cai_z and will include 544 the source port number as well, so this can be freely chosen by the 545 client but is still authenticated. 547 The payload may or may not be included into the signing input to 548 MAC_n (this is also indicated by cai_n). If the payload is included, 549 this ensures that an attacker can only replay completely identical 550 packets; in situations where this kind of replay would not be a 551 problem, no replay window mechanism needs to be employed. 553 In summary (bracket notation [..., ...] stands for an array of 554 values): 556 MAC_z = MAC([cai_z, fields(cai_z), attributes, cai_n, timestamp], 557 GK_z) 559 MAC_n = MAC([serial, cai_n, fields(cai_n)], GK_n_x) 560 where the CAM provides to Cx: 562 * GK_n_x = KDF(["key for MAC_n", CxID, GK_z]) 564 * all other inputs to MAC_z except for timestamp 566 * MAC_z 568 The actual information in the packet contains the token: 570 Token = 571 [cai_z, cai_n, GK_z-kid, CxID, attributes_conveyed, 572 (MAC_z xor MAC_n_x)] 574 The provisioning needed is limited to distributing grant keys GK_z 575 for each specific authorization (e.g., Device IP address/port number) 576 plus a base key GK_n_x to derive authentication keys for each client 577 Cx. These are connected by the common parts of the 5-tuple and a 578 CxID. 580 The role of the different keys can be summarized as follows: 582 * GK_z, known only by AM and the SPEPs, allows the AM to specify the 583 authorization information, which then can be checked by the SPEP 584 using MAC_z under the key GK_z. 586 Since the AM can compute the MAC_z ahead of time, from the point 587 of view of the client MAC_z essentially serves as a bearer token, 588 which however is only useful for packets with the fields(cai_z) 589 that are being authorized by AM. 591 * GK_n_x provides client x with a way to authenticate a wider 592 coverage, including values of the client's choice such as the 593 source port number or even the payload. Here, client x needs to 594 have the key so it can dynamically vary these fields without 595 needing to recur to AM. 597 3.5.2. Hierarchical Grants 599 Section 3.5.1 requires distributing separate authentication grants 600 for each client Cx to each SPEP, which may however be orthogonal to 601 the specific authorizations granted. 603 We cannot completely eliminate per-client "provisioning" as SPEP 604 needs to know about the authorization it needs to enforce. However, 605 by giving clients (e.g., C1/C2) more specific information than SPEP, 606 we can relieve SPEP from needing to know each of C1/C2 a priori, as 607 follows: 609 Let GK0 be the _generic grant Key_, which is generated by CAM and 610 told to the SPEPs in a generic grant. Clients never obtain GK0. 612 Let GKx be a _specific grant Key_, which is generated by CAM for each 613 Cx and told to Cx in a _specific grant_. Client x only knows its own 614 GKx, not that of other clients Cy. 616 For a complete exposition, we also introduce cai_1 and cai_2: 618 * Both cai_1 and fields(cai_1) are shared between CAM and SPEP in a 619 generic grant; fields(cai_1) are the constant parts of the packets 620 to be authorized (e.g., device IP address, device port number). 622 * cai_2 is a superset of cai_1; it indicates the fields that need to 623 be checked by SPEP. The generic grant provides cai_2, but not 624 fields(cai_2), as these can differ per packet and are chosen by 625 Cx. 627 Ignoring nonces, serials, and key identifier/lifetime/rollover 628 mechanisms, the following computations can be done: 630 * by CAM or SPEP (who both know GK0 and cai_1, i.e. generic 631 information about all packets covered by this grant): 633 Grant_x = [GK0-kid, cai_1, cai_2, fields(cai_1), GKx] 635 where GKx = KDF([cai_1, cai_2, fields(cai_1), GK0]) 637 * by Cx based on its provisioned GKx and a specific packet, but also 638 by SPEP based on the GKx the SPEP can compute for Cx 640 token = [GK0-kid, cai_1, cai_2, MAC([serial, cai_2, 641 fields(cai_2)], GKx)] 643 (These computations do not explicitly mention a client ID, which is 644 implied by the source IP address included in fields(cai__n_).) 645 Note that the token can be verified by SPEP as it can compute GKx 646 from the secret key GK0 that is only shared between CAM and SPEP, as 647 long as it knows which GK0 to apply (e.g., using GK0-kid, which here 648 simply is copied into the token). As they don't know GK0, the 649 individual clients Cx cannot compute GKx -- they need to obtain it 650 from CAM as part of Grant_x, which also gives them cai_1 and cai_2 -- 651 containing the information for Cx how to apply the GKx. The token, 652 computed from GKx, therefore authenticates Cx as the holder of xGKx, 653 and signifies the authorization of Cx to send a packet with 654 fields(cai_1) as indicated in GKx, with the additional requirement on 655 Cx that it also authenticates a serial number (used for replay 656 protection) and additional fields(cai_2). 658 Since the token includes the relevant parts of the 5-tuple, and cai_1 659 is part of the first MAC and therefore cannot be changed by the Cxes, 660 there is no need to apply any additional ACL beyond feeding the cai- 661 selected fields of the packet into the MAC. 663 So GK0 only needs to be provisioned once to the SPEPs for all Cxes; 664 each GKx is provisioned only to Cx. An SPEP can compute GKx from 665 cai_1, cai_2 (part of the token) and fields(cai_1) (taken from the 666 packet). GKx is eminently cacheable, but in any case does _not_ need 667 to be provisioned as it can be derived from GK0 and information that 668 is in the packet. 670 C1 and C2 have GK1 and GK2, respectively; the coverage area is easily 671 extended to include D1-address and D1-port etc., by setting the bits 672 in either cai_1 (if these are fixed for Cx) or cai_2 (if these can be 673 chosen by Cx). 675 4. IANA Considerations 677 4.1. Original SWORN model 679 Define CBOR Wake-Token Tag 1398230866 in [IANA.cbor-tags]. 681 Define CoAP option Wake-Token in the CoAP Option Numbers Registry of 682 [IANA.core-parameters] (Section 12.2 of [RFC7252]. (The option is 683 safe, no-cache-key, elective, repeatable, of type opaque 0-255 684 bytes.) 686 Define media-type "application/dtls-payload", with an associated CoAP 687 Content-Format in the CoAP Content-Formats Registry of 688 [IANA.core-parameters] (Section 12.3 of [RFC7252]. 690 4.2. Generalized model 692 TBD 694 5. Security Considerations 696 The purpose of the security mechanisms described is primarily to 697 protect availability (obviously, any symmetric keys employed also 698 need to be confidentiality protected for the sake of the integrity of 699 the mechanism). For the purposes of this kind of availability 700 protection, occasional false positives of the per-packet 701 authorization mechanisms may be acceptable, as long as they don't 702 reach a threshold of probability of success that is application 703 dependent (say, success in one out of a million of brute force 704 attempts, equivalent to 20-bit security). This may offer 705 optimization opportunities that need further study. 707 TBD 709 6. References 711 6.1. Normative References 713 [IANA.cbor-tags] 714 IANA, "Concise Binary Object Representation (CBOR) Tags", 715 . 717 [IANA.core-parameters] 718 IANA, "Constrained RESTful Environments (CoRE) 719 Parameters", 720 . 722 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 723 Application Protocol (CoAP)", RFC 7252, 724 DOI 10.17487/RFC7252, June 2014, 725 . 727 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 728 RFC 8152, DOI 10.17487/RFC8152, July 2017, 729 . 731 [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, 732 "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, 733 May 2018, . 735 [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data 736 Definition Language (CDDL): A Notational Convention to 737 Express Concise Binary Object Representation (CBOR) and 738 JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, 739 June 2019, . 741 [RFC8747] Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 742 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 743 Web Tokens (CWTs)", RFC 8747, DOI 10.17487/RFC8747, March 744 2020, . 746 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object 747 Representation (CBOR)", STD 94, RFC 8949, 748 DOI 10.17487/RFC8949, December 2020, 749 . 751 6.2. Informative References 753 [I-D.bormann-intarea-alfi] 754 Bormann, C., "Adaptation Layer Fragmentation Indication", 755 Work in Progress, Internet-Draft, draft-bormann-intarea- 756 alfi-04, 9 September 2013, 757 . 760 [I-D.ietf-bier-php] 761 Zhang, Z., "BIER Penultimate Hop Popping", Work in 762 Progress, Internet-Draft, draft-ietf-bier-php-07, 7 763 December 2021, . 766 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 767 Label Switching Architecture", RFC 3031, 768 DOI 10.17487/RFC3031, January 2001, 769 . 771 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 772 Constrained-Node Networks", RFC 7228, 773 DOI 10.17487/RFC7228, May 2014, 774 . 776 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 777 "Object Security for Constrained RESTful Environments 778 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 779 . 781 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 782 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 783 . 785 Acknowledgements 787 陈博 (Bo Chen) provided input for Section 3. 789 TBD 791 Authors' Addresses 793 Carsten Bormann 794 Universität Bremen TZI 795 Postfach 330440 796 D-28359 Bremen 797 Germany 799 Phone: +49-421-218-63921 800 Email: cabo@tzi.org 802 Yizhou Li 803 Huawei Technologies 805 Email: liyizhou@huawei.com