idnits 2.17.1 draft-ietf-ace-oauth-params-11.txt: 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: ---------------------------------------------------------------------------- No issues found here. 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 (January 11, 2020) is 1567 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-29 ** Obsolete normative reference: RFC 7049 (Obsoleted by RFC 8949) ** Obsolete normative reference: RFC 8152 (Obsoleted by RFC 9052, RFC 9053) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ACE Working Group L. Seitz 3 Internet-Draft Combitech 4 Intended status: Standards Track January 11, 2020 5 Expires: July 14, 2020 7 Additional OAuth Parameters for Authorization in Constrained 8 Environments (ACE) 9 draft-ietf-ace-oauth-params-11 11 Abstract 13 This specification defines new parameters for the OAuth 2.0 token and 14 introspection endpoints when used with the framework for 15 authentication and authorization for constrained environments (ACE). 16 These are used to express the proof-of-possession key the client 17 wishes to use, the proof-of-possession key that the Authorization 18 Server has selected, and the key the Resource Server should use to 19 authenticate to the client. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 14, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Parameters for the Token Endpoint . . . . . . . . . . . . . . 3 58 3.1. Client-to-AS Request . . . . . . . . . . . . . . . . . . 3 59 3.2. AS-to-Client Response . . . . . . . . . . . . . . . . . . 4 60 3.3. The Resource Server Confirmation Claim . . . . . . . . . 6 61 4. Parameters for the Introspection Endpoint . . . . . . . . . . 6 62 4.1. AS-to-RS Response . . . . . . . . . . . . . . . . . . . . 6 63 5. Confirmation Method Parameters . . . . . . . . . . . . . . . 8 64 6. CBOR Mappings . . . . . . . . . . . . . . . . . . . . . . . . 9 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 68 9.1. JSON Web Token Claims . . . . . . . . . . . . . . . . . . 9 69 9.2. CBOR Web Token Claims . . . . . . . . . . . . . . . . . . 9 70 9.3. OAuth Parameter Registration . . . . . . . . . . . . . . 10 71 9.4. OAuth Introspection Response Parameter Registration . . . 10 72 9.5. OAuth Parameters CBOR Mappings Registration . . . . . . . 10 73 9.6. OAuth Token Introspection Response CBOR Mappings 74 Registration . . . . . . . . . . . . . . . . . . . . . . 11 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 11.2. Informative References . . . . . . . . . . . . . . . . . 13 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 The Authentication and Authorization for Constrained Environments 84 (ACE) specification [I-D.ietf-ace-oauth-authz] requires some new 85 parameters for interactions with the OAuth 2.0 [RFC6749] token and 86 introspection endpoints, as well as some new claims to be used in 87 access tokens. These parameters and claims can also be used in other 88 contexts and have therefore been put into a dedicated document, to 89 facilitate their use in a manner independent of 90 [I-D.ietf-ace-oauth-authz]. 92 Note that although all examples are shown in CBOR [RFC7049], JSON 93 [RFC8259] MAY be used as an alternative for HTTP-based 94 communications, as specified in [I-D.ietf-ace-oauth-authz]. 96 2. Terminology 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 Readers are assumed to be familiar with the terminology from 105 [I-D.ietf-ace-oauth-authz], especially the terminology for entities 106 in the architecture such as client (C), resource server (RS) and 107 authorization server (AS). 109 Terminology from [RFC8152] is used in the examples, especially 110 COSE_Key defined in section 7 of [RFC8152]. 112 Note that the term "endpoint" is used here following its OAuth 2.0 113 [RFC6749] definition, which is to denote resources such as token and 114 introspection at the AS and authz-info at the RS. The CoAP [RFC7252] 115 definition, which is "An entity participating in the CoAP protocol" 116 is not used in this specification. 118 3. Parameters for the Token Endpoint 120 This section defines additional parameters for the interactions with 121 the token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz]. 123 3.1. Client-to-AS Request 125 This section defines the "req_cnf" parameter allowing clients to 126 request a specific proof-of-possession key in an access token from a 127 token endpoint in the ACE framework [I-D.ietf-ace-oauth-authz]: 129 req_cnf 130 OPTIONAL. This field contains information about the key the 131 client would like to bind to the access token for proof-of- 132 possession. It is RECOMMENDED that an AS reject a request 133 containing a symmetric key value in the 'req_cnf' field 134 (kty=Symmetric), since the AS is expected to be able to generate 135 better symmetric keys than a constrained client. The AS MUST 136 verify that the client really is in possession of the 137 corresponding key. Values of this parameter follow the syntax and 138 semantics of the "cnf" claim either from section 3.1 of 139 [I-D.ietf-ace-cwt-proof-of-possession] for CBOR-based interactions 140 or from section 3.1 of [RFC7800] for JSON-based interactions. 142 Figure 1 shows a request for an access token using the "req_cnf" 143 parameter to request a specific public key as proof-of-possession 144 key. The content is displayed in CBOR diagnostic notation, without 145 abbreviations and with line-breaks for better readability. 147 Header: POST (Code=0.02) 148 Uri-Host: "as.example.com" 149 Uri-Path: "token" 150 Content-Format: "application/ace+cbor" 151 Payload: 152 { 153 "req_cnf" : { 154 "COSE_Key" : { 155 "kty" : "EC2", 156 "kid" : h'11', 157 "crv" : "P-256", 158 "x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24 159 4DC189F745228255A219A86D6A09EFF', 160 "y" : h'20138BF82DC1B6D562BE0FA54AB7804A3 161 A64B6D72CCFED6B6FB6ED28BBFC117E' 162 } 163 } 164 } 166 Figure 1: Example request for an access token bound to an asymmetric 167 key. 169 3.2. AS-to-Client Response 171 This section defines the following additional parameters for an AS 172 response to a request to the token endpoint: 174 cnf 175 REQUIRED if the token type is "pop" and a symmetric key is used. 176 MAY be present for asymmetric proof-of-possession keys. This 177 field contains the proof-of-possession key that the AS selected 178 for the token. Values of this parameter follow the syntax and 179 semantics of the "cnf" claim either from section 3.1 of 180 [I-D.ietf-ace-cwt-proof-of-possession] for CBOR-based interactions 181 of from section 3.1 of [RFC7800] for JSON-based interactions. See 182 Section 5 for additional discussion of the usage of this 183 parameter. 185 rs_cnf 186 OPTIONAL if the token type is "pop" and asymmetric keys are used. 187 MUST NOT be present otherwise. This field contains information 188 about the public key used by the RS to authenticate. If this 189 parameter is absent, either the RS does not use a public key or 190 the AS knows that the RS can authenticate itself to the client 191 without additional information. Values of this parameter follow 192 the syntax and semantics of the "cnf" claim either from section 193 3.1 of [I-D.ietf-ace-cwt-proof-of-possession] for CBOR-based 194 interactions or from section 3.1 of [RFC7800] for JSON-based 195 interactions. See Section 5 for additional discussion of the 196 usage of this parameter. 198 Figure 2 shows an AS response containing a token and a "cnf" 199 parameter with a symmetric proof-of-possession key. 201 Header: Created (Code=2.01) 202 Content-Format: "application/ace+cbor" 203 Payload: 204 { 205 "access_token" : h'4A5015DF686428 ... 206 (remainder of CWT omitted for brevity; 207 CWT contains COSE_Key in the "cnf" claim)', 208 "cnf" : { 209 "COSE_Key" : { 210 "kty" : "Symmetric", 211 "kid" : h'DFD1AA97', 212 "k" : h'849B5786457C1491BE3A76DCEA6C427108' 213 } 214 } 215 } 217 Figure 2: Example AS response with an access token bound to a 218 symmetric key. 220 Figure 3 shows an AS response containing a token bound to a 221 previously requested asymmetric proof-of-possession key (not shown) 222 and a "rs_cnf" parameter containing the public key of the RS. 224 Header: Created (Code=2.01) 225 Content-Format: "application/ace+cbor" 226 Payload: 227 { 228 "access_token" : h'D08343A1010AA1054D2A45DF6FBC5A5A ... 229 (remainder of CWT omitted for brevity; 230 CWT contains COSE_Key in the "cnf" claim)', 231 "rs_cnf" : { 232 "COSE_Key" : { 233 "kty" : "EC2", 234 "kid" : h'12', 235 "crv" : "P-256", 236 "x" : h'BCEE7EAAC162F91E6F330F5771211E220 237 B8B546C96589B0AC4AD0FD24C77E1F1', 238 "y" : h'C647B38C55EFBBC4E62E651720F002D5D 239 75B2E0C02CD1326E662BCA222B90416' 240 } 241 } 242 } 244 Figure 3: Example AS response, including the RS's public key. 246 3.3. The Resource Server Confirmation Claim 248 If the AS needs to convey a hint to the RS about which key it should 249 use to authenticate towards the client, this specification defines 250 the "rs_cnf" claim, which MAY be used in the access token, with the 251 same syntax and semantics as defined in for the "rs_cnf" parameter. 253 4. Parameters for the Introspection Endpoint 255 This section defines an additional parameter for the interactions 256 with the introspection endpoint in the ACE framework 257 [I-D.ietf-ace-oauth-authz]. 259 4.1. AS-to-RS Response 261 This section defines the following additional parameter for an AS 262 response to a request to the introspection endpoint: 264 rs_cnf 265 OPTIONAL. If the RS uses asymmetric keys to authenticate towards 266 the client (e.g., with a DTLS Raw Public Key handshake [RFC7250] 267 and it has several such keys (e.g., for different elliptic 268 curves), the AS can give the RS a hint using this parameter, as to 269 which key it should use. Values of this parameter follow the 270 syntax and semantics of the "cnf" claim from either section 3.1 of 271 [I-D.ietf-ace-cwt-proof-of-possession] for CBOR-based interactions 272 or section 3.1 of [RFC7800] for JSON-based interactions. See 273 Section 5 for additional discussion of the usage of this 274 parameter. 276 Furthermore the AS can use the "cnf" parameter specified in section 277 9.4 of [I-D.ietf-oauth-mtls] in an introspection response. For CBOR- 278 based interactions the AS MUST use the parameter mapping specified in 279 Figure 5 and the value must follow the syntax of "cnf" claim values 280 from section 3.1 of [I-D.ietf-ace-cwt-proof-of-possession]. 282 Figure 4 shows an AS response to an introspection request including 283 the "cnf" parameter to indicate the proof-of-possession key bound to 284 the token and the "rs_cnf" parameter to indicate the key the RS is 285 supposed to use to authenticate to the client. 287 Header: Created Code=2.01) 288 Content-Format: "application/ace+cbor" 289 Payload: 290 { 291 "active" : true, 292 "scope" : "read", 293 "aud" : "tempSensor4711", 294 "cnf" : { 295 "COSE_Key" : { 296 "kty" : "EC2", 297 "kid" : h'11', 298 "crv" : "P-256", 299 "x" : h'BAC5B11CAD8F99F9C72B05CF4B9E26D24 300 4DC189F745228255A219A86D6A09EFF', 301 "y" : h'20138BF82DC1B6D562BE0FA54AB7804A3 302 A64B6D72CCFED6B6FB6ED28BBFC117E' 303 } 304 }, 305 "rs_cnf" : { 306 "COSE_Key" : { 307 "kty" : "EC2", 308 "kid" : h'12', 309 "crv" : "P-256", 310 "x" : h'BCEE7EAAC162F91E6F330F5771211E220 311 B8B546C96589B0AC4AD0FD24C77E1F1', 312 "y" : h'C647B38C55EFBBC4E62E651720F002D5D 313 75B2E0C02CD1326E662BCA222B90416' 314 } 315 } 316 } 318 Figure 4: Example introspection response. 320 5. Confirmation Method Parameters 322 The confirmation method parameters are used as follows: 324 o "req_cnf" in the access token request C -> AS, OPTIONAL to 325 indicate the client's raw public key, or the key-identifier of a 326 previously established key between C and RS that the client wishes 327 to use for proof-of-possession of the access token. 329 o "cnf" in the token response AS -> C, OPTIONAL if using an 330 asymmetric key or a key that the client requested via a key 331 identifier in the request. REQUIRED if the client didn't specify 332 a "req_cnf" and symmetric keys are used. Used to indicate the 333 symmetric key generated by the AS for proof-of-possession of the 334 access token. 336 o "cnf" in the introspection response AS -> RS, REQUIRED if the 337 access token that was subject to introspection is a proof-of- 338 possession token, absent otherwise. Indicates the proof-of- 339 possession key bound to the access token. 341 o "rs_cnf" in the token response AS -> C, OPTIONAL to indicate the 342 public key of the RS, if it uses one to authenticate itself to the 343 client and the binding between key and RS identity is not 344 established through other means. 346 o "rs_cnf" in the introspection response AS -> RS, OPTIONAL, 347 contains the public key that the RS should use for authenticating 348 itself to the client (e.g., if the RS has several different public 349 keys, and there may be ambiguity as to which key to use). 351 Note that the COSE_Key structure in a confirmation claim or parameter 352 may contain an "alg" or "key_ops" parameter. If such parameters are 353 present, a client MUST NOT use a key that is incompatible with the 354 profile or proof-of-possession algorithm according to those 355 parameters. An RS MUST reject a proof-of-possession using such a 356 key. 358 If an access token is issued for an audience that includes several 359 RS, the "rs_cnf" parameter MUST NOT be used, since the client cannot 360 determine for which RS the key applies. This document recommends to 361 specify a different endpoint that the client can use to acquire RS 362 authentication keys in such cases. The specification of such an 363 endpoint is out of scope for this document. 365 6. CBOR Mappings 367 If CBOR is used, the new parameters and claims defined in this 368 document MUST be mapped to CBOR types as specified in Figure 5, using 369 the given integer abbreviation for the map key. 371 /----------+----------+-------------------------------------\ 372 | Name | CBOR Key | Value Type | Usage | 373 |----------+----------+-------------------------------------| 374 | req_cnf | TBD (4) | map | token request | 375 | cnf | TBD (8) | map | token response | 376 | cnf | TBD (8) | map | introspection response | 377 | rs_cnf | TBD (41) | map | token response | 378 | rs_cnf | TBD (41) | map | introspection response | 379 | rs_cnf | TBD (41) | map | CWT claim | 380 \----------+----------+------------+------------------------/ 382 Figure 5: CBOR mappings for new parameters and claims. 384 7. Security Considerations 386 This document is an extension to [I-D.ietf-ace-oauth-authz]. All 387 security considerations from that document apply here as well. 389 8. Privacy Considerations 391 This document is an extension to [I-D.ietf-ace-oauth-authz]. All 392 privacy considerations from that document apply here as well. 394 9. IANA Considerations 396 9.1. JSON Web Token Claims 398 This specification registers the following new claim in the JSON Web 399 Token (JWT) registry of JSON Web Token Claims 400 [IANA.JsonWebTokenClaims]: 402 o Claim Name: "rs_cnf" 403 o Claim Description: public key used by RS to authenticate itself to 404 the client. 405 o Change Controller: IESG 406 o Reference: Section 3.3 of [this document] 408 9.2. CBOR Web Token Claims 410 This specification registers the following new claim in the "CBOR Web 411 Token (CWT) Claims" registry [IANA.CborWebTokenClaims]. 413 o Claim Name: "rs_cnf" 414 o Claim Description: public key used by RS to authenticate itself to 415 the client. 416 o JWT Claim Name: rs_cnf 417 o Claim Key: TBD (suggested: 41) 418 o Claim Value Type(s): map 419 o Change Controller: IESG 420 o Specification Document(s): Section 3.3 of [this document] 422 9.3. OAuth Parameter Registration 424 This section registers the following parameters in the "OAuth 425 Parameters" registry [IANA.OAuthParameters]: 427 o Name: "req_cnf" 428 o Parameter Usage Location: token request 429 o Change Controller: IESG 430 o Reference: Section 5 of [this document] 432 o Name: "rs_cnf" 433 o Parameter Usage Location: token response 434 o Change Controller: IESG 435 o Reference: Section 5 of [this document] 437 o Name: "cnf" 438 o Parameter Usage Location: token response 439 o Change Controller: IESG 440 o Reference: Section 5 of [this document] 442 9.4. OAuth Introspection Response Parameter Registration 444 This section registers the following parameter in the OAuth Token 445 Introspection Response registry [IANA.TokenIntrospectionResponse]. 447 o Name: "rs_cnf" 448 o Description: public key used by RS to authenticate itself to the 449 client. 450 o Change Controller: IESG 451 o Reference: Section 4.1 of [this document] 453 9.5. OAuth Parameters CBOR Mappings Registration 455 This section registers the following parameter mappings in the "OAuth 456 Parameters CBOR Mappings" registry established in section 8.9. of 457 [I-D.ietf-ace-oauth-authz]. 459 o Name: "req_cnf" 460 o CBOR key: TBD (suggested: 4) 461 o Change Controller: IESG 462 o Reference: Section 3.1 of [this document] 464 o Name: "cnf" 465 o CBOR key: TBD (suggested: 8) 466 o Change Controller: IESG 467 o Reference: Section 3.2 of [this document] 469 o Name: "rs_cnf" 470 o CBOR key: TBD (suggested: 41) 471 o Change Controller: IESG 472 o Reference: Section 3.2 of [this document] 474 9.6. OAuth Token Introspection Response CBOR Mappings Registration 476 This section registers the following parameter mappings in the "OAuth 477 Token Introspection Response CBOR Mappings" registry established in 478 section 8.11. of [I-D.ietf-ace-oauth-authz]. 480 o Name: "cnf" 481 o CBOR key: TBD (suggested: 8) 482 o Change Controller: IESG 483 o Reference: Section 4.1 of [this document] 485 o Name: "rs_cnf" 486 o CBOR key: TBD (suggested: 41) 487 o Change Controller: IESG 488 o Reference: Section 4.1 of [this document] 490 10. Acknowledgments 492 This document is a product of the ACE working group of the IETF. 494 Ludwig Seitz worked on this document as part of the CelticNext 495 projects CyberWI, and CRITISEC with funding from Vinnova. 497 11. References 499 11.1. Normative References 501 [I-D.ietf-ace-cwt-proof-of-possession] 502 Jones, M., Seitz, L., Selander, G., Erdtman, S., and H. 503 Tschofenig, "Proof-of-Possession Key Semantics for CBOR 504 Web Tokens (CWTs)", draft-ietf-ace-cwt-proof-of- 505 possession-11 (work in progress), October 2019. 507 [I-D.ietf-ace-oauth-authz] 508 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 509 H. Tschofenig, "Authentication and Authorization for 510 Constrained Environments (ACE) using the OAuth 2.0 511 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-29 512 (work in progress), December 2019. 514 [I-D.ietf-oauth-mtls] 515 Campbell, B., Bradley, J., Sakimura, N., and T. 516 Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication 517 and Certificate-Bound Access Tokens", draft-ietf-oauth- 518 mtls-17 (work in progress), August 2019. 520 [IANA.CborWebTokenClaims] 521 IANA, "CBOR Web Token (CWT) Claims", 522 . 525 [IANA.JsonWebTokenClaims] 526 IANA, "JSON Web Token Claims", 527 . 529 [IANA.OAuthParameters] 530 IANA, "OAuth Parameters", 531 . 534 [IANA.TokenIntrospectionResponse] 535 IANA, "OAuth Token Introspection Response", 536 . 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 545 RFC 6749, DOI 10.17487/RFC6749, October 2012, 546 . 548 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 549 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 550 October 2013, . 552 [RFC7800] Jones, M., Bradley, J., and H. Tschofenig, "Proof-of- 553 Possession Key Semantics for JSON Web Tokens (JWTs)", 554 RFC 7800, DOI 10.17487/RFC7800, April 2016, 555 . 557 [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", 558 RFC 8152, DOI 10.17487/RFC8152, July 2017, 559 . 561 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 562 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 563 May 2017, . 565 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 566 Interchange Format", STD 90, RFC 8259, 567 DOI 10.17487/RFC8259, December 2017, 568 . 570 11.2. Informative References 572 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 573 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 574 Transport Layer Security (TLS) and Datagram Transport 575 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 576 June 2014, . 578 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 579 Application Protocol (CoAP)", RFC 7252, 580 DOI 10.17487/RFC7252, June 2014, 581 . 583 Author's Address 585 Ludwig Seitz 586 Combitech 587 Djaeknegatan 31 588 Malmoe 211 35 589 Sweden 591 Email: ludwig.seitz@combitech.se