idnits 2.17.1 draft-barnes-jose-use-cases-02.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 (February 25, 2013) is 4049 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-27) exists of draft-ietf-alto-protocol-13 == Outdated reference: A later version (-32) exists of draft-ietf-oauth-json-web-token-06 == Outdated reference: A later version (-07) exists of draft-miller-xmpp-e2e-04 ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) == Outdated reference: A later version (-12) exists of draft-ietf-oauth-jwt-bearer-04 == Outdated reference: A later version (-23) exists of draft-ietf-oauth-saml2-bearer-15 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 JOSE R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Informational February 25, 2013 5 Expires: August 29, 2013 7 Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) 8 draft-barnes-jose-use-cases-02.txt 10 Abstract 12 Many Internet applications have a need for object-based security 13 mechanisms in addition to security mechanisms at the network layer or 14 transport layer. In the past, the Cryptographic Message Syntax has 15 provided a binary secure object format based on ASN.1. Over time, 16 the use of binary object encodings such as ASN.1 has been overtaken 17 by text-based encodings, for example JavaScript Object Notation. 18 This document defines a set of use cases and requirements for a 19 secure object format encoded using JavaScript Object Notation, drawn 20 from a variety of application security mechanisms currently in 21 development. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 29, 2013. 40 Copyright Notice 42 Copyright (c) 2013 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Security Tokens and Authorization . . . . . . . . . . . . 6 62 4.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.4. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 11 65 4.5. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 13 66 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 67 5.1. Functional Requirements . . . . . . . . . . . . . . . . . 14 68 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 15 69 5.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 74 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 75 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 1. Introduction 80 Internet applications rest on the layered architecture of the 81 Internet, and take advantage of security mechanisms at all layers. 82 Many applications rely primarily on channel-based security 83 technologies, which create a secure channel at the IP layer or 84 transport layer over which application data can flow 85 [RFC4301][RFC5246]. These mechanisms, however, cannot provide end- 86 to-end security in some cases. For example, in protocols with 87 application-layer intermediaries, channel-based security protocols 88 would protect messages from attackers between intermediaries, but not 89 from the intermediaries themselves. These cases require object-based 90 security technologies, which embed application data within a secure 91 object that can be safely handled by untrusted entities. 93 The most well-known example of such a protocol today is the use of 94 Secure/Multipurpose Internet Mail Extensions (S/MIME) protections 95 within the email system [RFC5751][RFC5322]. An email message 96 typically passes through a series of intermediate Mail Transfer 97 Agents (MTAs) en route to its destination. While these MTAs often 98 apply channel-based security protections to their interactions (e.g., 99 [RFC3207]), these protections do not prevent the MTAs from 100 interfering with the message. In order to provide end-to-end 101 security protections in the presence of untrusted MTAs, mail users 102 can use S/MIME to embed message bodies in a secure object format that 103 can provide confidentiality, integrity, and data origin 104 authentication. 106 S/MIME is based on the Cryptographic Message Syntax for secure 107 objects (CMS) [RFC5652]. CMS is defined using Abstract Syntax 108 Notation 1 (ASN.1) and traditionally encoded using the ASN.1 109 Distinguished Encoding Rules (DER), which define a binary encoding of 110 the protected message and associated parameters [ITU.X690.1994]. In 111 recent years, usage of ASN.1 has decreased (along with other binary 112 encodings for general objects), while more applications have come to 113 rely on text-based formats such as the Extensible Markup Language 114 (XML) or the JavaScript Object Notation (JSON) 115 [W3C.REC-xml-1998][RFC4627]. 117 Many current applications thus have much more robust support for 118 processing objects in these text-based formats than ASN.1 objects; 119 indeed, many lack the ability to process ASN.1 objects at all. To 120 simplify the addition of object-based security features to these 121 applications, the IETF JSON Object Signing and Encryption (JOSE) 122 working group has been chartered to develop a secure object format 123 based on JSON. While the basic requirements for this object format 124 are straightforward -- namely, confidentiality and integrity 125 mechanisms, encoded in JSON -- early discussions in the working group 126 indicated that many applications hoping to use the formats define in 127 JOSE have additional requirements. This document summarizes the use 128 cases for JOSE envisioned by those applications and the resulting 129 requirements for security mechanisms and object encoding. 131 Some systems that use XML have specified the use of XML-based 132 security mechanisms for object security, namely XML Digital 133 Signatures and XML Encryption 134 [W3C.CR-xmldsig-core2-20120124][W3C.CR-xmlenc-core1-20120313]. These 135 mechanisms are defined for use with several security token systems 136 (e.g., SAML, WS-Federation, and OpenID connect 137 [OASIS.saml-core-2.0-os][WS-Federation][OpenID.Messages]) and the CAP 138 emergency alerting format [CAP]. In practice, however, XML-based 139 secure object formats introduce similar levels of complexity to 140 ASN.1, so developers that lack the tools or motivation to handle 141 ASN.1 aren't able to use XML security either. This situation 142 motivates the creation of a JSON-based secure object format that is 143 simple enough to implement and deploy that it can be easily adopted 144 by developers with minimal effort and tools. 146 2. Definitions 148 This document makes extensive use of standard security terminology 149 [RFC4949]. In addition, because the use cases for JOSE and CMS are 150 similar, we will sometimes make analogies to some CMS concepts 151 [RFC5652]. 153 The JOSE working group charter calls for the group to define three 154 basic JSON object formats: 156 1. Confidentiality-protected object format 158 2. Integrity-protected object format 160 3. A format for expressing public keys 162 In the below, we will refer to these as the "encrypted object 163 format", the "signed object format", and the "key format", 164 respectively. In general, where there is no need to distinguish 165 between asymmetric and symmetric operations, we will use the terms 166 "signing", "signature", etc. to denote both true digital signatures 167 involving asymmtric cryptography as well as message authentication 168 codes using symmetric keys(MACs). 170 In the lifespan of a secure object, there are two basic roles, an 171 entity that creates the object (e.g., encrypting or signing a 172 payload), and an entity that uses the object (decrypting, verifying). 174 We will refer to these roles as "sender" and "recipient", 175 respectively. Note that while some requirements and use cases may 176 refer to these as single entities, each object may have multiple 177 entities in each role. For example, a message may be signed by 178 multiple senders, or decrypted by multiple recipients. 180 3. Basic Requirements 182 Obviously, for the encrypted and signed object formats, the necessary 183 protections will be created using appropriate cryptographic 184 mechanisms: symmetric or asymmetric encryption for confidentiality 185 and MACs or digital signatures for integrity protection. In both 186 cases, it is necessary for the JOSE format to support both symmetric 187 and asymmetric operations. 189 o The JOSE encrypted object format must support object encryption in 190 the case where the sender and receiver share a symmetric key. 192 o The JOSE encrypted object format must support object encryption in 193 the case where the sender has only a public key for the receiver. 195 o The JOSE signed object format must integrity protection using 196 Message Authentication Codes (MACs), for the case where the sender 197 and receiver share only a symmetric key. 199 o The JOSE signed object format must integrity protection using 200 digital signatures, for the case where the receiver has only a 201 public key for the sender. 203 In cases where two entities are going to be exchanging several JOSE 204 objects, it might be helpful to pre-negotiate some parameters so that 205 they do not have to be signaled in every JOSE object. However, in 206 order to not interfere with endpoints that do not support pre- 207 negotiation, it is necessary to signal when pre-negotiated parameters 208 are in use. 210 o The JOSE signed and encrypted object formats must include a field 211 that indicates that pre-negotiated parameters are to be used to 212 process the object. This field may also provide an indication of 213 which parameters are to be used. 215 The purpose of the key format is to provide the recipient with 216 sufficient information to use the encoded key to process 217 cryptographic messages. Thus it is necessary to include additional 218 parameters along with the bare key. 220 o The JOSE key format must include all algorithm parameters 221 necesssary to use the encoded key, including an identifier for the 222 algorithm with which the key is used as well as any additional 223 parameters required by the algorithm (e.g., elliptic curve 224 parameters). 226 4. Use Cases 228 Based on early discussions of JOSE, several working groups developing 229 application-layer protocols have expressed a desire to use JOSE in 230 their designs for end-to-end security features. In this section, we 231 summarize the use cases proposed by these groups and discuss the 232 requirements that they imply for the JOSE object formats. 234 4.1. Security Tokens and Authorization 236 Security tokens are a common use case for object-based security, for 237 example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens 238 are used to convey information about a subject entity ("claims" or 239 "assertions") from an issuer to a recipient. The security features 240 of a token format enable the recipient to verify that the claims came 241 from the issuer and, if the object is confidentiality-protected, that 242 they were not visible to other parties. 244 Security tokens are used in federation protocols such as SAML 2.0, 245 WS-Federation, and OpenID Connect 246 [OASIS.saml-core-2.0-os][WS-Federation][OpenID.Messages], as well as 247 in resource authorization protocols such as OAuth 2.0 [RFC6749]. In 248 some cases, security tokens are used for client authentication and 249 for access control 250 [I-D.ietf-oauth-jwt-bearer][I-D.ietf-oauth-saml2-bearer]. 252 The OAuth protocol defines a mechanism for distributing and using 253 authorization tokens using HTTP [RFC6749]. A Client that wishes to 254 access a protected resource requests authorization from the Resource 255 Owner. If the Resource Owner allows this access, he directs an 256 Authorization Server to issue an access token to the Client. When 257 the Client wishes to access the protected resource, he presents the 258 token to the relevant Resource Server, which verifies the validity of 259 the token before providing access to the protected resource. 261 +---------------+ +---------------+ 262 | | | | 263 | Resource |<........>| Authorization | 264 | Server | | Server | 265 | | | | 266 +---------------+ +---------------+ 267 ^ | 268 | | 269 | | 270 | | 271 | | 272 +------------|--+ +--|------------+ 273 | +----------------+ | 274 | | | Resource | 275 | Client | | Owner | 276 | | | | 277 +---------------+ +---------------+ 279 Figure 1: The OAuth process 281 In effect, this process moves the token from the Authorization Server 282 (as a sender of the object) to the Resource Server (recipient), via 283 the Client as well as the Resource Owner (the latter because of the 284 HTTP mechanics underlying the protocol). So again we have a case 285 where an application object is transported via untrusted 286 intermediaries. 288 This application has two essential security requirements: Integrity 289 and data origin authentication. Integrity protection is required so 290 that the Resource Owner and the Client cannot modify the permission 291 encoded in the token. Data origin authentication is required so that 292 the Resource Server can verify that the token was issued by a trusted 293 Authorization Server. Confidentiality protection may also be needed, 294 if the Authorization Server is concerned about the visibility of 295 permissions information to the Resource Owner or Client. For 296 example, permissions related to social networking might be considered 297 private information. Note, however, that OAuth already requires that 298 the underlying HTTP transactions be protected by TLS, so 299 confidentiality protection is not strictly necessary for this use 300 case. 302 The confidentiality and integrity needs are met by the basic 303 requirements for signed and encrypted object formats, whether the 304 signing and encryption are provided using asymmetric or symmetric 305 cryptography. The choice of which mechanism is applied will depend 306 on the relationship between the two servers, namely whether they 307 share a symmetric key or only public keys. 309 Authentication requirements will also depend on deployment 310 characteristics. Where there is a relatively strong binding between 311 the resource server and the authorization server, it may suffice for 312 the Authorization Server issuing a token to be identified by the key 313 used to sign the token. This requires that the token carry either 314 the public key of the Authorization Server or an identifier for the 315 public or symmetric key. 317 There may also be more advanced cases, where the Authorization 318 Server's key is not known in advance to the Resource Server. This 319 may happen, for instance, if an entity instantiated a collection of 320 Authorization Servers (say for load balancing), each of which has an 321 independent key pair. In these cases, it may be necessary to also 322 include a certificate or certificate chain for the Authorization 323 Server, so that the Resource Server can verify that the Authorization 324 Server is an entity that it trusts. 326 The HTTP transport for OAuth imposes a particular constraint on the 327 encoding. In the OAuth protocol, tokens frequently need to be passed 328 as query parameters in HTTP URIs [RFC2616], after having been 329 base64url encoded [RFC4648]. While there is no specified limit on 330 the length of URIs (and thus of query parameters), in practice URIs 331 of more than around 2,000 characters are rejected by some user 332 agents. So this use case requires that a JOSE object have 333 sufficiently small size even after signing, possibly encrypting, 334 while still being simple to include in an HTTP URI query parameter. 336 Two related security token systems have similar requirements: 338 o The JSON Web Token format (JWT) is a security token format based 339 on JSON and JOSE [I-D.ietf-oauth-json-web-token]. It is used with 340 both OpenID Connect and OAuth. Because JWTs are often used in 341 contexts with limited space (e.g., HTTP query parameters), it is a 342 core requirement for JWTs, and thus JOSE, to have a compact 343 representation. 345 o The OpenID Connect protocol is a simple, REST/JSON-based identity 346 federation protocol layered on OAuth 2.0 [OpenID.Messages]. It 347 uses the JWT and JOSE formats both to represent security tokens 348 and to provide security for other protocol messages (signing and 349 optionally encryption). 351 4.2. XMPP 353 The Extensible Messaging and Presence Protocol (XMPP) routes messages 354 from one end client to another by way of XMPP servers [RFC6120]. 355 There are typically two servers involved in delivering any given 356 message: The first client (Alice) sends a message for another client 357 (B) to her server (A). Server A uses Bob's identity and the DNS to 358 locate the server for Bob's domain (B), then delivers the message to 359 that server. Server B then routes the message to Bob. 361 +-------+ +----------+ +----------+ +-----+ 362 | Alice |-->| Server A |-->| Server B |-->| Bob | 363 +-------+ +----------+ +----------+ +-----+ 365 Figure 2: Delivering an XMPP message 367 The untrusted-intermediary problems are especially acute for XMPP 368 because in many current deployments, the holder of an XMPP domain 369 outsources the operation of the domain's servers to a different 370 entity. In this environment, there is a clear risk of exposing the 371 domain holder's private information to the domain operator. XMPP 372 already has a defined mechanism for end-to-end security using S/MIME, 373 but it has failed to gain widespread deployment [RFC3923], in part 374 because of key management challenges and because of the difficulty of 375 processing S/MIME objects. 377 The XMPP working group is in the process of developing a new end-to- 378 end encryption system with an encoding based on JOSE and a clearer 379 key management system [I-D.miller-xmpp-e2e]. The process of sending 380 an encrypted message in this system involves two steps: First, the 381 sender generates a symmetric Content Encryption Key (CEK), encrypts 382 the message content, and sends the encrypted message to the desired 383 set of recipients. Second, each recipient "dials back" to the 384 sender, providing his public key; the sender then responds with the 385 relevent CEK, wrapped with the recipient's public key. 387 +-------+ +----------+ +----------+ +-----+ 388 | Alice |<->| Server A |<->| Server B |<->| Bob | 389 +-------+ +----------+ +----------+ +-----+ 390 | | | | 391 |------------Encrypted--message--------->| 392 | | | | 393 |<---------------Public-key--------------| 394 | | | | 395 |---------------Wrapped CEK------------->| 396 | | | | 398 Figure 3: Delivering a secure XMPP message 400 The main thing that this system requires from the JOSE formats is 401 confidentiality protection via content encryption, plus an integrity 402 check via a MAC derived from the same symmetric key. The separation 403 of the key exchange from the transmission of the encrypted content, 404 however, requires that the JOSE encrypted object format allow wrapped 405 symmetric keys to be carried separately from the encrypted payload. 406 In addition, the encrypted object will need to have a tag for the key 407 that was used to encrypt the content, so that the recipient (Bob) can 408 present the tag to the sender (Alice) when requesting the wrapped 409 key. 411 Another important feature of XMPP is that it allows for the 412 simultaneous delivery of a message to multiple recipients. In the 413 diagrams above, Server A could deliver the message not only to Server 414 B (for Bob) but also to Servers C, D, E, etc. for other users. In 415 such cases, to avoid the multiple "dial back" transactions implied by 416 the above mechanism, XMPP systems will likely cache public keys for 417 end recipients, so that wrapped keys can be sent along with content 418 on future messages. This implies that the JOSE encrypted object 419 format must support the provision of multiple versions of the same 420 wrapped CEK (much as a CMS EnvelopedData structure can include 421 multiple RecipientInfo structures). 423 In the current draft of the XMPP end-to-end security system, each 424 party is authenticated by virtue of the other party's trust in the 425 XMPP message routing system. The sender is authenticated to the 426 receiver because he can receive messages for the identifier "Alice" 427 (in particular, the request for wrapped keys), and can originate 428 messages for that identifier (the wrapped key). Likewise, the 429 receiver is authenticated to the sender because he received the 430 original encrypted message and originated the request for wrapped 431 key. So the authentication here requires not only that XMPP routing 432 be done properly, but also that TLS be used on every hop. Moreover, 433 it requires that the TLS channels have strong authentication, since a 434 man in the middle on any of the three hops can masquerade as Bob and 435 obtain the key material for an encrypted message. 437 Because this authentication is quite weak (depending on the use of 438 transport-layer security on three hops) and unverifiable by the 439 endpoints, it is possible that the XMPP working group will integrate 440 some sort of credentials for end recipients, in which case there 441 would need to be a way to associate these credentials with JOSE 442 objects. 444 Finally, it's worth noting that XMPP is based on XML, not JSON. So 445 by using JOSE, XMPP will be carrying JSON objects within XML. It is 446 thus a desirable property for JOSE objects to be encoded in such a 447 way as to be safe for inclusion in XML. Otherwise, an explicit CDATA 448 indication must be given to the parser to indicate that it is not to 449 be parsed as XML. One way to meet this requirement would be to apply 450 base64url encoding, but for XMPP messages of medium-to-large size, 451 this could impose a fair degree of overhead. 453 4.3. ALTO 455 Application-Layer Traffic Optimization (ALTO) is a system for 456 distributing network topology information to end devices, so that 457 those devices can modify their behavior to have a lower impact on the 458 network [I-D.ietf-alto-reqs]. The ALTO protocol distributes topology 459 information in the form of JSON objects carried in HTTP 460 [RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is 461 simply a client-server protocol, so simple use of HTTPS suffices for 462 this case [RFC2818]. However, there is beginning to be some 463 discussion of use cases for ALTO in which these JSON objects will be 464 distributed through a collection of intermediate servers before 465 reaching the client, while still preserving the ability of the client 466 to authenticate the original source of the object. Even the base 467 ALTO protocol notes that "ALTO clients obtaining ALTO information 468 must be able to validate the received ALTO information to ensure that 469 it was generated by an appropriate ALTO server." 471 In this case, the security requirements are straightforward. JOSE 472 objects carrying ALTO payloads will need to bear digital signatures 473 from the originating servers, which will be bound to certificates 474 attesting to the identities of the servers. There is no requirement 475 for confidentiality in this case, since ALTO information is generally 476 public. 478 The more interesting questions are encoding questions. ALTO objects 479 are likely to be much larger than payloads in the two cases above, 480 with sizes of up to several megabytes. Processing of such large 481 objects can be done more quickly if it can be done in a single pass, 482 which may be possible if JOSE objects require specific orderings of 483 fields within the JSON structure. 485 In addition, because ALTO objects are also encoded as JSON, they are 486 already safe for inclusion in a JOSE object. Signed JOSE objects 487 will likely carry the signed data in a string alongside the 488 signature. JSON objects have the property that they can be safely 489 encoded in JSON strings. All they require is that unnecessary white 490 space be removed, a much simpler transformation than, say base64url 491 encoding. This raises the question of whether it might be possible 492 to optimize the JOSE encoding for certain "JSON-safe" cases. 494 4.4. Emergency Alerting 496 Emergency alerting is an emerging use case for IP networks 497 [I-D.ietf-atoca-requirements]. Alerting systems allow authorities to 498 warn users of impending danger by sending alert messages to connected 499 devices. For example, in the event of hurricane or tornado, alerts 500 might be sent to all devices in the path of the storm. 502 The most critical security requirement for alerting systems is that 503 it must not be possible for an attacker to send false alerts to 504 devices. Such a capability would potentially allow an attacker to 505 create wide-spread panic. In practice, alert systems prevent these 506 attacks both by controls on sending messages at points where alerts 507 are originated, as well as by having recipients of alerts verify that 508 the alert was sent by an authorized source. The former type of 509 control implemented with local security on hosts from which alerts 510 can be originated. The latter type implemented by digital signatures 511 on alert messages (using channel-based or object-based mechanisms). 513 Alerts typically reach end recipients via a series of intermediaries. 514 For example, while a national weather service might originate a 515 hurricane alert, it might first be delivered to a national gateway, 516 and then to network operators, who broadcast it to end subscribers. 518 +------------+ +------------+ +------------+ 519 | Originator | | Originator | | Originator | 520 +------------+ +------------+ +------------+ 521 | . . 522 +-----------------+.................. 523 | 524 V 525 +---------+ 526 | Gateway | 527 +---------+ 528 | 529 +------------+------------+ 530 | | 531 V V 532 +---------+ +---------+ 533 | Network | | Network | 534 +---------+ +---------+ 535 | | 536 +------+-----+ +------+-----+ 537 | | | | 538 V V V V 539 +--------+ +--------+ +--------+ +--------+ 540 | Device | | Device | | Device | | Device | 541 +--------+ +--------+ +--------+ +--------+ 543 Figure 4: Delivering an emergency alert 545 In order to verify alert signatures, recipients must be provisioned 546 with the proper public keys for trusted alert authorities. This 547 trust may be "piece-wise" along the path the alert takes. For 548 example, the alert relays operated by networks might have a full set 549 of ceritificates for all alert originators, while end devices may 550 only trust their local alert relay. Or devices might require that a 551 device be signed by an authorized originator and by its local 552 network's relay. 554 This scenario creates a need for multiple signatures on alert 555 documents, so that an alert can bear signatures from any or all of 556 the entities that processed it along the path. In order to minimize 557 complexity, these signatures should be "modular", in the sense that a 558 new signature can be added without a need to alter or recompute 559 previous signatures. 561 4.5. Web Cryptography 563 The W3C Web Cryptography API defines a standard cryptographic API for 564 the web [WebCrypto]. If a browser exposes this API, then JavaScript 565 provided as part of a web page can ask the browser to perform 566 cryptographic operations, such as digest, MAC, encryption, or digital 567 signing. 569 One of the key reasons to have the browser perform cryptographic 570 operations to avoid allowing JavaScript code to access the keying 571 material used for these operations. For example, this separation 572 would prevent code injected through a cross-site scripting (XSS) 573 attack from reading and exfiltrating keys stored within a browser. 574 While the malicious code could still use the key while running in the 575 browser, this vulnerability can only be exercised while the 576 vulnerable page is active in a user's browser. 578 However, the WebCryptography API also provides a key export 579 functionality, which can allow JavaScript to extract a key from the 580 API in wrapped form. For example, the JavaScript might provide a 581 public key for which the corresponding private key is held by another 582 device. The wrapped key provided by the API could then be used to 583 safely transport the key to the new device. While this could 584 potentially allow malicious code to export a key, the need for an 585 explicit export operation provides a control point, allowing for user 586 notification or consent verification. 588 The Web Cryptography API also allows browsers to impose limitations 589 on the usage of the keys it handles. For example, a symmetric key 590 might be marked as usable only for encryption, and not for MAC. When 591 a key is exported in wrapped form, these attributes should be carried 592 along with it. 594 The Web Cryptography API thus requires formats to express several 595 forms of keys. Obviously, the public key from an asymmetric key pair 596 can be freely imported to and exported from the browser, so there 597 needs to be a format for public keys. There is also a need for a 598 format to express private keys and symmetric keys. For non-public 599 keys, the primary need is for a wrapped form, where the 600 confidentiality and integrity of the key is assured 601 cryptographically; these protections should also apply to any 602 attributes of the key. It may also be useful to define a direct, 603 unwrapped format, for use within a security boundary. 605 5. Requirements 607 This section summarizes the requirements from the above uses cases, 608 and lists further requirements not directly derived from the above 609 use cases. There are also some constraints that are not hard 610 requrirements, but which are still desireable properties for the JOSE 611 system to have. 613 5.1. Functional Requirements 615 F1 Define formats for secure objects that provide the following 616 security properties: 618 * Digital signature (integrity/authentication under an asymmetric 619 key pair) 621 * Message authentication (integrity/authentication under a 622 symmetric key) 624 * Encryption 626 * Authenticated encryption 628 That is, the secure objects defined by this working group should 629 provide equivalent security properties to the CMS SignedData, 630 AuthenticatedData, EnvelopedData, and AuthEnveloped data objects 631 [RFC5652] [RFC5083]. 633 F2 Define a format for public keys and private keys for asymmetric 634 cryptographic algorithms, with associated attributes, including a 635 wrapped form for private keys. 637 F3 Define a format for symmetric keys with associated attributes, 638 allowing for both wrapped and unwrapped keys. 640 F4 Define a JSON serialization for the above objects. An object in 641 this encoding must be valid according to the JSON ABNF syntax 642 [RFC4627] 644 F5 Define a compact, URL-safe text serialization for the above 645 objects. 647 F6 Allow for attributes associated to wrapped keys to be bound to 648 them cryptographically 650 F7 Allow for wrapped keys to be separated from a secure object that 651 uses a symmetric key. In such cases, cryptographic components of 652 the secure object other than the wrapped key (e.g., ciphertext, 653 MAC values) must be independent of the wrapped form of the key. 654 For example, if an encrypted object is prepared for multiple 655 recipients, then only the wrapped key may vary, not the 656 ciphertext. 658 5.2. Security Requirements 660 S1 Provide key management functions for all symmetric keys, including 661 encryption keys and MAC keys. It should be possible to use any of 662 the key management techniques provided in CMS [RFC5652]: 664 * Key transport (wrapping for a public key) 666 * Key encipherment (wrapping for a symmetric key) 668 * Key agreement (wrapping for a DH public key) 670 * Password-based encryption (wrapping under a derived key) 672 S2 Use cryptographic algorithms in a manner compatible with major 673 validation processes. For example, if a FIPS standard allows 674 algorithm A to be used for purpose X but not purpose Y, then JOSE 675 should not recommend using algorithm A for purpose Y. 677 S3 Support operation with or without pre-negotiation. It must be 678 possible to create or process a secure object without any 679 configuration beyond key provisioning. If it is possible to 680 negotiate parameters out of band, then the object must signal that 681 pre-negotiated parameters are to be used. 683 5.3. Desiderata 685 D1 Maximize compatibility with the W3C WebCrypto specification, e.g., 686 by using the same identifiers for algorithms. 688 D2 Avoid JSON canonicalization to the extent possible possible. That 689 is, all other things being equal, techniques that rely on fixing a 690 serialization of an object (e.g., by base64url encoding it) are 691 preferred over those that require converting an object to a 692 canonical form. 694 6. Acknowledgements 696 Thanks to Matt Miller for discussions related to XMPP end-to-end 697 security model, and to Mike Jones for considerations related to 698 security tokens and XML security. Thanks to Mark Watson for raising 699 the need for representing symmetric keys and binding attributes to 700 them. 702 7. IANA Considerations 704 This document makes no request of IANA. 706 8. Security Considerations 708 The primary focus of this document is the requirements for a JSON- 709 based secure object format. At the level of general security 710 considerations for object-based security technologies, the security 711 considerations for this format are the same as for CMS [RFC5652]. 712 The primary difference between the JOSE format and CMS is that JOSE 713 is based on JSON, which does not have a canonical representation. 714 The lack of a canonical form means that it is difficult to determine 715 whether two JSON objects represent the same information, which could 716 lead to vulnerabilities in some usages of JOSE. 718 9. References 720 9.1. Normative References 722 [I-D.ietf-alto-protocol] 723 Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", 724 draft-ietf-alto-protocol-13 (work in progress), 725 September 2012. 727 [I-D.ietf-alto-reqs] 728 Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and 729 Y. Yang, "Application-Layer Traffic Optimization (ALTO) 730 Requirements", draft-ietf-alto-reqs-16 (work in progress), 731 June 2012. 733 [I-D.ietf-atoca-requirements] 734 Schulzrinne, H., Norreys, S., Rosen, B., and H. 735 Tschofenig, "Requirements, Terminology and Framework for 736 Exigent Communications", draft-ietf-atoca-requirements-03 737 (work in progress), March 2012. 739 [I-D.ietf-oauth-json-web-token] 740 Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 741 (JWT)", draft-ietf-oauth-json-web-token-06 (work in 742 progress), December 2012. 744 [I-D.miller-xmpp-e2e] 745 Miller, M., "End-to-End Object Encryption for the 746 Extensible Messaging and Presence Protocol (XMPP)", 747 draft-miller-xmpp-e2e-04 (work in progress), 748 February 2013. 750 [RFC4627] Crockford, D., "The application/json Media Type for 751 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 753 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 754 Encodings", RFC 4648, October 2006. 756 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 757 RFC 4949, August 2007. 759 [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) 760 Authenticated-Enveloped-Data Content Type", RFC 5083, 761 November 2007. 763 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 764 RFC 5652, September 2009. 766 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 767 Protocol (XMPP): Core", RFC 6120, March 2011. 769 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", 770 RFC 6749, October 2012. 772 [W3C.CR-xmldsig-core2-20120124] 773 Datta, P., Hirsch, F., Eastlake, D., Cantor, S., Roessler, 774 T., Reagle, J., Yiu, K., and D. Solo, "XML Signature 775 Syntax and Processing Version 2.0", World Wide Web 776 Consortium CR CR-xmldsig-core2-20120124, January 2012, 777 . 779 [W3C.CR-xmlenc-core1-20120313] 780 Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, 781 "XML Encryption Syntax and Processing Version 1.1", World 782 Wide Web Consortium CR CR-xmlenc-core1-20120313, 783 March 2012, 784 . 786 [W3C.REC-xml-1998] 787 Bray, T., Paoli, J., and C. Sperberg-McQueen, "Extensible 788 Markup Language (XML) 1.0", W3C REC-xml-1998, 789 February 1998, 790 . 792 [WebCrypto] 793 Sleevi, R. and D. Dahl, "Web Cryptography API", 794 January 2013. 796 9.2. Informative References 798 [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol 799 v1.1", October 2005. 801 [I-D.ietf-oauth-jwt-bearer] 802 Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token 803 (JWT) Bearer Token Profiles for OAuth 2.0", 804 draft-ietf-oauth-jwt-bearer-04 (work in progress), 805 December 2012. 807 [I-D.ietf-oauth-saml2-bearer] 808 Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion 809 Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15 810 (work in progress), November 2012. 812 [ITU.X690.1994] 813 International Telecommunications Union, "Information 814 Technology - ASN.1 encoding rules: Specification of Basic 815 Encoding Rules (BER), Canonical Encoding Rules (CER) and 816 Distinguished Encoding Rules (DER)", ITU-T Recommendation 817 X.690, 1994. 819 [OASIS.saml-core-2.0-os] 820 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 821 "Assertions and Protocol for the OASIS Security Assertion 822 Markup Language (SAML) V2.0", OASIS Standard saml-core- 823 2.0-os, March 2005. 825 [OpenID.Messages] 826 Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., 827 Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", 828 June 2012, 829 . 832 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 833 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 834 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 836 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 838 [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over 839 Transport Layer Security", RFC 3207, February 2002. 841 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 842 for the Extensible Messaging and Presence Protocol 843 (XMPP)", RFC 3923, October 2004. 845 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 846 Internet Protocol", RFC 4301, December 2005. 848 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 849 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 851 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 852 October 2008. 854 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 855 Mail Extensions (S/MIME) Version 3.2 Message 856 Specification", RFC 5751, January 2010. 858 [WS-Federation] 859 Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, 860 "OpenID Connect Messages 1.0", May 2009, . 864 Author's Address 866 Richard Barnes 867 BBN Technologies 868 1300 N 17th St 869 Arlington, VA 22209 870 US 872 Email: rlb@ipv.sx