draft-ietf-jose-use-cases-06.txt   rfc7165.txt 
JOSE R. Barnes Internet Engineering Task Force (IETF) R. Barnes
Internet-Draft BBN Technologies Request for Comments: 7165 Mozilla
Intended status: Informational December 27, 2013 Category: Informational April 2014
Expires: June 30, 2014 ISSN: 2070-1721
Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) Use Cases and Requirements for
draft-ietf-jose-use-cases-06 JSON Object Signing and Encryption (JOSE)
Abstract Abstract
Many Internet applications have a need for object-based security Many Internet applications have a need for object-based security
mechanisms in addition to security mechanisms at the network layer or mechanisms in addition to security mechanisms at the network layer or
transport layer. For many years, the Cryptographic Message Syntax transport layer. For many years, the Cryptographic Message Syntax
(CMS) has provided a binary secure object format based on ASN.1. (CMS) has provided a binary secure object format based on ASN.1.
Over time, binary object encodings such as ASN.1 have become less Over time, binary object encodings such as ASN.1 have become less
common than text-based encodings, for example JavaScript Object common than text-based encodings, such as the JavaScript Object
Notation. This document defines a set of use cases and requirements Notation (JSON). This document defines a set of use cases and
for a secure object format encoded using JavaScript Object Notation requirements for a secure object format encoded using JSON, drawn
(JSON), drawn from a variety of application security mechanisms from a variety of application security mechanisms currently in
currently in development. development.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on June 30, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7165.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements on Application Protocols . . . . . . . . . . . . 6 4. Requirements on Application Protocols . . . . . . . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7 5.1. Security Tokens . . . . . . . . . . . . . . . . . . . . . 7
5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. OAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.3. Federation . . . . . . . . . . . . . . . . . . . . . . . . 9 5.3. OpenID Connect . . . . . . . . . . . . . . . . . . . . . 9
5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.4. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 13 5.6. Emergency Alerting . . . . . . . . . . . . . . . . . . . 13
5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 15 5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . 15
5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 16 5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 16
5.8.1. Example: MAC based on ECDH-derived key . . . . . . . . 16 5.8.1. Example: MAC Based on ECDH-Derived Key . . . . . . . 16
5.8.2. Object security for CoAP . . . . . . . . . . . . . . . 17 5.8.2. Object Security for CoAP . . . . . . . . . . . . . . 17
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18 6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18
6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19 6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19
6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 20 6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix B. Document History . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
Internet applications rest on the layered architecture of the Internet applications rest on the layered architecture of the
Internet, and take advantage of security mechanisms at all layers. Internet and take advantage of security mechanisms at all layers.
Many applications rely primarily on channel-based security Many applications rely primarily on channel-based security
technologies such as IPsec and TLS, which create a secure channel at technologies such as IPsec and Transport Layer Security (TLS), which
the IP layer or transport layer over which application data can flow create a secure channel at the IP layer or transport layer over which
[RFC4301][RFC5246]. These mechanisms, however, cannot provide end- application data can flow [RFC4301] [RFC5246]. These mechanisms,
to-end security in some cases. For example, in protocols with however, cannot provide end-to-end security in some cases. For
application-layer intermediaries, channel-based security protocols example, in protocols with application-layer intermediaries, channel-
would protect messages from attackers between intermediaries, but not based security protocols would protect messages from attackers
from the intermediaries themselves. These cases require object-based between intermediaries, but not from the intermediaries themselves.
security technologies, which embed application data within a secure These cases require object-based security technologies, which embed
object that can be safely handled by untrusted entities. application data within a secure object that can be safely handled by
untrusted entities.
The most well-known example of such a protocol today is the use of The most well-known example of such a protocol today is the use of
Secure/Multipurpose Internet Mail Extensions (S/MIME) protections Secure/Multipurpose Internet Mail Extensions (S/MIME) protections
within the email system [RFC5751][RFC5322]. An email message within the email system [RFC5751] [RFC5322]. An email message
typically passes through a series of intermediate Mail Transfer typically passes through a series of intermediate Mail Transfer
Agents (MTAs) en route to its destination. While these MTAs often Agents (MTAs) en route to its destination. While these MTAs often
apply channel-based security protections to their interactions (e.g., apply channel-based security protections to their interactions (e.g.,
STARTTLS [RFC3207]), these protections do not prevent the MTAs from STARTTLS [RFC3207]), these protections do not prevent the MTAs from
interfering with the message. In order to provide end-to-end interfering with the message. In order to provide end-to-end
security protections in the presence of untrusted MTAs, mail users security protections in the presence of untrusted MTAs, mail users
can use S/MIME to embed message bodies in a secure object format that can use S/MIME to embed message bodies in a secure object format that
can provide confidentiality, integrity, and data origin can provide confidentiality, integrity, and data origin
authentication. authentication.
S/MIME is based on the Cryptographic Message Syntax for secure S/MIME is based on the Cryptographic Message Syntax (CMS) for secure
objects (CMS) [RFC5652]. CMS is defined using Abstract Syntax objects [RFC5652]. CMS is defined using Abstract Syntax Notation 1
Notation 1 (ASN.1) and typically encoded using the ASN.1 (ASN.1) and typically encoded using the ASN.1 Distinguished Encoding
Distinguished Encoding Rules (DER), which define a binary encoding of Rules (DER), which define a binary encoding of the protected message
the protected message and associated parameters [ITU.X690.2002]. In and associated parameters [ITU.X690.2002]. In recent years, usage of
recent years, usage of ASN.1 has decreased (along with other binary ASN.1 has decreased (along with other binary encodings for general
encodings for general objects), while more applications have come to objects), while more applications have come to rely on text-based
rely on text-based formats such as the Extensible Markup Language formats such as the Extensible Markup Language (XML) [W3C.REC-xml] or
(XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON) the JavaScript Object Notation (JSON) [RFC7159].
[RFC4627].
Many current applications thus have much more robust support for Many current applications thus have much more robust support for
processing objects in these text-based formats than ASN.1 objects; processing objects in these text-based formats than ASN.1 objects;
indeed, many lack the ability to process ASN.1 objects at all. To indeed, many lack the ability to process ASN.1 objects at all. To
simplify the addition of object-based security features to these simplify the addition of object-based security features to these
applications, the IETF JSON Object Signing and Encryption (JOSE) applications, the IETF JSON Object Signing and Encryption (JOSE)
working group has been chartered to develop a secure object format working group has been chartered to develop a secure object format
based on JSON. While the basic requirements for this object format based on JSON. While the basic requirements for this object format
are straightforward -- namely, confidentiality and integrity are straightforward -- namely, confidentiality and integrity
mechanisms, encoded in JSON -- discussions in the working group mechanisms encoded in JSON -- discussions in the working group
indicated that different applications hoping to use the formats indicated that different applications hoping to use the formats
defined by JOSE have different requirements. This document defined by JOSE have different requirements. This document
summarizes the use cases for JOSE envisioned by those potential summarizes the use cases for JOSE envisioned by those potential
applications and the resulting requirements for security mechanisms applications and the resulting requirements for security mechanisms
and object encodings. and object encodings.
Some systems that use XML have specified the use of XML-based Some systems that use XML have specified the use of XML-based
security mechanisms for object security, namely XML Digital security mechanisms for object security, namely XML Digital
Signatures and XML Encryption [W3C.xmldsig-core][W3C.xmlenc-core]. Signatures and XML Encryption [W3C.xmldsig-core] [W3C.xmlenc-core].
These mechanisms are defined for use with several security token These mechanisms are used by several security token systems (e.g.,
systems (e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation Security Assertion Markup Language (SAML) [OASIS.saml-core-2.0-os],
[WS-Federation]) and the CAP emergency alerting format [CAP]. In Web Services Federation [WS-Federation]), and the Common Alerting
practice, however, XML-based secure object formats introduce similar Protocol (CAP) emergency alerting format [CAP]. In practice,
levels of complexity to ASN.1 (e.g., due to the need for XML however, XML-based secure object formats introduce similar levels of
canonicalization), so developers that lack the tools or motivation to complexity to ASN.1 (e.g., due to the need for XML canonicalization),
handle ASN.1 aren't likely to use XML security either. This so developers that lack the tools or motivation to handle ASN.1
situation motivates the creation of a JSON-based secure object format aren't likely to use XML security either. This situation motivates
that is simple enough to implement and deploy that it can be easily the creation of a JSON-based secure object format that is simple
adopted by developers with minimal effort and tools. enough to implement and deploy that it can be easily adopted by
developers with minimal effort and tools.
2. Definitions 2. Definitions
This document makes extensive use of standard security terminology This document makes extensive use of standard security terminology
[RFC4949]. In addition, because the use cases for JOSE and CMS are [RFC4949]. In addition, because the use cases for JOSE and CMS are
similar, we will sometimes make analogies to some CMS concepts similar, we will sometimes make analogies to some CMS concepts
[RFC5652]. [RFC5652].
The JOSE working group charter calls for the group to define three The JOSE working group charter calls for the group to define three
basic JSON object formats: basic JSON object formats:
1. Confidentiality-protected object format 1. Integrity-protected object format
2. Integrity-protected object format 2. Confidentiality-protected object format
3. A format for expressing keys 3. A format for expressing keys
In this document, we will refer to these as the "encrypted object In this document, we will refer to these as the "signed object
format", the "signed object format", and the "key format", format", the "encrypted object format", and the "key format",
respectively. The JOSE working group items intended to describe respectively. The JOSE working group items intended to describe
these formats are JSON Web Signature (JWS), JSON Web Encryption these formats are JSON Web Signature [JWS], JSON Web Encryption
(JWE), and JSON Web Key (JWK), respectively [JWE], and JSON Web Key [JWK], respectively. Algorithms and
[I-D.ietf-jose-json-web-signature] algorithm identifiers used by JWS, JWE, and JWK are defined in JSON
[I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key]. Web Algorithms [JWA].
Algorithms and algorithm identifiers used by JWS, JWE, and JWK are
defined in JSON Web Algorithms (JWA)
[I-D.ietf-jose-json-web-algorithms].
In general, where there is no need to distinguish between asymmetric In general, where there is no need to distinguish between asymmetric
and symmetric operations, we will use the terms "signing", and symmetric operations, we will use the terms "signing",
"signature", etc. to denote both true digital signatures involving "signature", etc., to denote both true digital signatures involving
asymmetric cryptography as well as message authentication codes using asymmetric cryptography as well as Message Authentication Codes
symmetric keys (MACs). (MACs) using symmetric keys.
In the lifespan of a secure object, there are two basic roles, an In the lifespan of a secure object, there are two basic roles, an
entity that creates the object (e.g., encrypting or signing a entity that creates the object (e.g., encrypting or signing a
payload), and an entity that uses the object (decrypting, verifying). payload) and an entity that uses the object (decrypting and
We will refer to these roles as "sender" and "recipient", verifying). We will refer to these roles as "sender" and
respectively. Note that while some requirements and use cases may "recipient", respectively. Note that while some requirements and use
refer to these as single entities, each object may have multiple cases may refer to these as single entities, each object may have
entities in each role. For example, a message may be signed by multiple entities in each role. For example, a message may be signed
multiple senders, or decrypted by multiple recipients. by multiple senders or decrypted by multiple recipients.
3. Basic Requirements 3. Basic Requirements
For the encrypted and signed object formats, the necessary For the encrypted and signed object formats, the necessary
protections will be created using appropriate cryptographic protections will be created using appropriate cryptographic
mechanisms: symmetric or asymmetric encryption for confidentiality mechanisms: symmetric or asymmetric encryption for confidentiality
and MACs or digital signatures for integrity protection. In both and MACs or digital signatures for integrity protection. In both
cases, it is necessary for the JOSE format to support both symmetric cases, it is necessary for the JOSE format to support both symmetric
and asymmetric operations. and asymmetric operations.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
the case where the sender and receiver share a symmetric key. the case where the sender and receiver share a symmetric key.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
the case where the sender has only a public key for the receiver. the case where the sender has only a public key for the receiver.
o The JOSE signed object format must support integrity protection o The JOSE signed object format must support integrity protection
using Message Authentication Codes (MACs), for the case where the using MACs, for the case where the sender and receiver share only
sender and receiver share only a symmetric key. a symmetric key.
o The JOSE signed object format must support integrity protection o The JOSE signed object format must support integrity protection
using digital signatures, for the case where the receiver has only using digital signatures, for the case where the receiver has only
a public key for the sender. a public key for the sender.
In some applications, the key used to process a JOSE object is In some applications, the key used to process a JOSE object is
indicated by application context, instead of directly in the JOSE indicated by application context, instead of directly in the JOSE
object. However, in order to avoid confusion, endpoints that lack object. However, in order to avoid confusion, endpoints that lack
the necessary context need to be able to recognize this and fail the necessary context need to be able to recognize this and fail
cleanly. Other than keys, JOSE objects do not support pre- cleanly. Other than keys, JOSE objects do not support pre-
skipping to change at page 6, line 23 skipping to change at page 6, line 18
In cases where two entities are going to be exchanging several JOSE In cases where two entities are going to be exchanging several JOSE
objects, it might be helpful to pre-negotiate some parameters so that objects, it might be helpful to pre-negotiate some parameters so that
they do not have to be signaled in every JOSE object. However, so as they do not have to be signaled in every JOSE object. However, so as
not to confuse endpoints that do not support pre-negotiation, it is not to confuse endpoints that do not support pre-negotiation, it is
useful to signal when pre-negotiated parameters are in use in those useful to signal when pre-negotiated parameters are in use in those
cases. cases.
o It should be possible to extend the base JOSE signed and encrypted o It should be possible to extend the base JOSE signed and encrypted
object formats to indicate that pre-negotiated parameters are to object formats to indicate that pre-negotiated parameters are to
be used to process the object. This extension should also provide be used to process the object. This extension should also provide
a means of indicating of which parameters are to be used. a means of indicating which parameters are to be used.
The purpose of the key format is to provide the recipient with The purpose of the key format is to provide the recipient with
sufficient information to use the encoded key to process sufficient information to use the encoded key to process
cryptographic messages. Thus it is sometimes necessary to include cryptographic messages. Thus, it is sometimes necessary to include
additional parameters along with the bare key. additional parameters along with the bare key.
o The JOSE key format must enable inclusion of all algorithm o The JOSE key format must enable inclusion of all algorithm
parameters necessary to use the encoded key, including an parameters necessary to use the encoded key, including an
identifier for the algorithm with which the key is used as well as identifier for the algorithm with which the key is used as well as
any additional parameters required by the algorithm (e.g., any additional parameters required by the algorithm (e.g.,
elliptic curve parameters). elliptic curve parameters).
4. Requirements on Application Protocols 4. Requirements on Application Protocols
The JOSE secure object formats describe how cryptographic processing The JOSE secure object formats describe how cryptographic processing
is done on secured content, ensuring that the recipient an object is is done on secured content, ensuring that the recipient of an object
able to properly decrypt an encrypted object or verify a signature. is able to properly decrypt an encrypted object or verify a
In order to make use of JOSE, however, applications will need to signature. In order to make use of JOSE, however, applications will
specify several aspects of how JOSE is to be used: need to specify several aspects of how JOSE is to be used:
o What application content is to be protected o What application content is to be protected
o Which cryptographic algorithms are to be used o Which cryptographic algorithms are to be used
o How application protocol entities establish keys o How application protocol entities establish keys
o Whether keys are to be explicitly indicated in JOSE objects, or o Whether keys are to be explicitly indicated in JOSE objects or
associated by application context associated by application context
o What serializations of JOSE objects are to be used o Which serialization(s) of JOSE objects are to be used
5. Use Cases 5. Use Cases
Several IETF working groups developing application-layer protocols Several IETF working groups developing application-layer protocols
have expressed a desire to use the JOSE data formats in their designs have expressed a desire to use the JOSE data formats in their designs
for end-to-end security features. In this section, we summarize the for end-to-end security features. In this section, we summarize the
use cases proposed by these groups and discuss the requirements that use cases proposed by these groups and discuss the requirements that
they imply for the JOSE object formats. they imply for the JOSE object formats.
5.1. Security Tokens 5.1. Security Tokens
Security tokens are a common use case for object-based security, for Security tokens are a common use case for object-based security, for
example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens
are used to convey information about a subject entity ("claims" or are used to convey information about a subject entity ("claims" or
"assertions") from an issuer to a recipient. The security features "assertions") from an issuer to a recipient. The security features
of a token format enable the recipient to verify that the claims came of a token format enable the recipient to verify that the claims came
from the issuer and, if the object is confidentiality-protected, that from the issuer and, if the object is confidentiality protected, that
they were not visible to other parties. they were not visible to other parties.
Security tokens are used in federation protocols such as SAML 2.0 Security tokens are used in federation protocols such as SAML 2.0
[OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla [OASIS.saml-core-2.0-os], WS-Federation [WS-Federation], Mozilla
Persona [Persona], and OpenID Connect [OpenID.Messages], as well as Persona [Persona], and OpenID Connect [OpenID.Core], as well as in
in resource authorization protocols such as OAuth 2.0 [RFC6749], resource authorization protocols such as OAuth 2.0 [RFC6749],
including for OAuth bearer tokens [RFC6750]. In some cases, security including for OAuth bearer tokens [RFC6750]. In some cases, security
tokens are used for client authentication and for access control tokens are used for client authentication and for access control
[I-D.ietf-oauth-jwt-bearer][I-D.ietf-oauth-saml2-bearer]. [JWT-BEARER] [SAML2].
JSON Web Token (JWT) [I-D.ietf-oauth-json-web-token] is a security JSON Web Token [JWT] is a security token format based on JSON and
token format based on JSON and JOSE. It is used with Mozilla JOSE. It is used with Mozilla Persona, OpenID Connect, and OAuth.
Persona, OpenID Connect, and OAuth. Because JWTs are often used in Because JWTs are often used in contexts with limited space (e.g.,
contexts with limited space (e.g., HTTP query parameters), it is a HTTP query parameters), it is a core requirement for JWTs, and thus
core requirement for JWTs, and thus JOSE, to have a compact, URL-safe JOSE, to have a compact, URL-safe representation.
representation.
5.2. OAuth 5.2. OAuth
The OAuth protocol defines a mechanism for distributing and using The OAuth protocol defines a mechanism for distributing and using
authorization tokens using HTTP [RFC6749]. A Client that wishes to authorization tokens using HTTP [RFC6749]. A client that wishes to
access a protected resource requests authorization from the Resource access a protected resource requests authorization from the resource
Owner. If the Resource Owner allows this access, he directs an owner. If the resource owner allows this access, he directs an
Authorization Server to issue an access token to the Client. When authorization server to issue an access token to the client. When
the Client wishes to access the protected resource, he presents the the client wishes to access the protected resource, he presents the
token to the relevant Resource Server, which verifies the validity of token to the relevant resource server, which verifies the validity of
the token before providing access to the protected resource. the token before providing access to the protected resource.
+---------------+ +---------------+ +---------------+ +---------------+
| | | | | | | |
| Resource |<........>| Authorization | | Resource |<........>| Authorization |
| Server | | Server | | Server | | Server |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
^ | ^ |
| | | |
| | | |
| | | |
| | | |
+------------|--+ +--|------------+ +------------|--+ +--|------------+
| +----------------+ | | +----------------+ |
| | | Resource | | | | Resource |
| Client | | Owner | | Client | | Owner |
| | | | | | | |
+---------------+ +---------------+ +---------------+ +---------------+
Figure 1: The OAuth process Figure 1: The OAuth Process
In effect, this process moves the token from the Authorization Server In effect, this process moves the token from the authorization server
(as a sender of the object) to the Resource Server (recipient), via (as a sender of the object) to the resource server (recipient) via
the Client as well as the Resource Owner (the latter because of the the client as well as the resource owner (the latter because of the
HTTP mechanics underlying the protocol). So again we have a case HTTP mechanics underlying the protocol). As with email, we have a
where an application object is transported via untrusted case where an application object is transported via untrusted
intermediaries. intermediaries.
This application has two essential security requirements: Integrity This application has two essential security requirements: integrity
and data origin authentication. Integrity protection is required so and data origin authentication. Integrity protection is required so
that the Resource Owner and the Client cannot modify the permission that the resource owner and the client cannot modify the permission
encoded in the token. Although the Resource Owner is ultimately the encoded in the token. Although the resource owner is ultimately the
entity that grants authorization, it is not trusted to modify the entity that grants authorization, it is not trusted to modify the
authorization token, since this could, for example, grant access to authorization token, since this could, for example, grant access to
resources not owned by the Resource Owner. resources not owned by the resource owner.
Data origin authentication is required so that the Resource Server Data origin authentication is required so that the resource server
can verify that the token was issued by a trusted Authorization can verify that the token was issued by a trusted authorization
Server. server.
Confidentiality protection may also be needed, if the Authorization Confidentiality protection may also be needed if the authorization
Server is concerned about the visibility of permissions information server is concerned about the visibility of permissions information
to the Resource Owner or Client. For example, permissions related to to the resource owner or client. For example, permissions related to
social networking might be considered private information. Note, social networking might be considered private information. Note,
however, that OAuth already requires that the underlying HTTP however, that OAuth already requires that the underlying HTTP
transactions be protected by TLS, so tokens are already transactions be protected by TLS, so tokens are already
confidentiality-protected from entities other than the Resource Owner confidentiality protected from entities other than the resource owner
and Client. and client.
The confidentiality and integrity needs are met by the basic The confidentiality and integrity needs are met by the basic
requirements for signed and encrypted object formats, whether the requirements for signed and encrypted object formats, whether the
signing and encryption are provided using asymmetric or symmetric signing and encryption are provided using asymmetric or symmetric
cryptography. The choice of which mechanism is applied will depend cryptography. The choice of which mechanism is applied will depend
on the relationship between the two servers, namely whether they on the relationship between the two servers, namely whether they
share a symmetric key or only public keys. share a symmetric key or only public keys.
Authentication requirements will also depend on deployment Authentication requirements will also depend on deployment
characteristics. Where there is a relatively strong binding between characteristics. Where there is a relatively strong binding between
the resource server and the authorization server, it may suffice for the resource server and the authorization server, it may suffice for
the Authorization Server issuing a token to be identified by the key the authorization server issuing a token to be identified by the key
used to sign the token. This requires that the protocol carry either used to sign the token. This requires that the protocol carry either
the public key of the Authorization Server or an identifier for the the public key of the authorization server or an identifier for the
public or symmetric key. In OAuth, the "client_id" parameter public or symmetric key. In OAuth, the "client_id" parameter
identifies the key to be used. (external to the token) identifies the key to be used.
There may also be more advanced cases, where the Authorization There may also be more advanced cases where the authorization
Server's key is not known in advance to the Resource Server. This server's key is not known in advance to the resource server. This
may happen, for instance, if an entity instantiated a collection of may happen, for instance, if an entity instantiated a collection of
Authorization Servers (say for load balancing), each of which has an authorization servers (say for load balancing), each of which has an
independent key pair. In these cases, it may be necessary to also independent key pair. In these cases, it may be necessary to also
include a certificate or certificate chain for the Authorization include a certificate or certificate chain for the authorization
Server, so that the Resource Server can verify that the Authorization server, so that the resource server can verify that the authorization
Server is an entity that it trusts. server is an entity that it trusts.
The HTTP transport for OAuth imposes a particular constraint on the The HTTP transport for OAuth imposes a particular constraint on the
encoding. In the OAuth protocol, tokens frequently need to be passed encoding. In the OAuth protocol, tokens frequently need to be passed
as query parameters in HTTP URIs [RFC2616], after having been as query parameters in HTTP URIs [RFC2616] after having been
base64url encoded [RFC4648]. While there is no specified limit on base64url encoded [RFC4648]. While there is no specified limit on
the length of URIs (and thus of query parameters), in practice, URIs the length of URIs (and thus of query parameters), in practice, URIs
of more than 2,048 characters are rejected by some user agents. For of more than 2,048 characters are rejected by some user agents. So
some mobile browsers, this limit is even smaller. So this use case this use case requires that JOSE objects be sufficiently small, even
requires that a JOSE object have sufficiently small size even after after being signed and possibly encrypted.
signing, possibly encrypting, while still being simple to include in
an HTTP URI query parameter.
5.3. Federation
Security tokens are used in two federated identity protocols, which
have similar requirements to the general considerations discussed
above:
o The OpenID Connect protocol [OpenID.Messages] is a simple, REST/ 5.3. OpenID Connect
JSON-based identity federation protocol layered on OAuth 2.0. It
uses the JWT and JOSE formats both to represent security tokens
and to provide security for other protocol messages (performing
signing and optionally encryption). OpenID Connect negotiates the
algorithms to be used and distributes information about the keys
to be used using protocol elements that are not part of the JWT
and JOSE header parameters.
o The Mozilla Persona [Persona] system is a simple single-sign-on The OpenID Connect protocol [OpenID.Core] is a simple, REST/JSON-
(SSO) protocol that uses JWTs that are signed JOSE JWS objects to based identity federation protocol layered on OAuth 2.0. It uses the
represent information about identities, applications, and keys for JWT and JOSE formats both to represent security tokens and to provide
participating entities. Persona distributes the keys used as security for other protocol messages (performing signing and
claims in JWT messages and not by using JOSE header parameters. optionally encryption). OpenID Connect negotiates the algorithms to
be used and distributes information about the keys to be used using
protocol elements that are not part of the JWT and JOSE header
parameters.
In the OpenID Connect context, and in some other applications of JWT, In the OpenID Connect context, it is possible for the recipient of a
it is possible for the recipient of a JWT to accept it without JWT to accept it without integrity protection in the JWT itself. In
integrity protection in the JWT itself. In such cases, the recipient such cases, the recipient chooses to rely on transport security
chooses to rely on transport security rather than object security. rather than object security. For example, if the payload is
For example, if the payload is delivered over a TLS-protected delivered over a TLS-protected channel, the recipient may regard the
channel, the recipient may regard the protections provided by TLS as protections provided by TLS as sufficient, so JOSE protection would
sufficient, so JOSE protection would not be required. not be required.
However, even in this case, it is desirable to associate some However, even in this case, it is desirable to associate some
metadata with the JWT payload (claim set), such as the content type, metadata with the JWT payload (claim set), such as the content type,
or other application-specific metadata. In a signed or encrypted or other application-specific metadata. In a signed or encrypted
object, these metadata values could be carried in a header with other object, these metadata values could be carried in a header with other
metadata required for signing or encryption. It would thus simplify metadata required for signing or encryption. It would thus simplify
the design of OpenID Connect and similar applications if there could the design of OpenID Connect if there could be a JOSE object format
be a JOSE object format that does not apply cryptographic protections that does not apply cryptographic protections to its payload, but
to its payload, but allows a header to be attached to the payload in allows a header to be attached to the payload in the same way as a
the same way as a signed or encrypted object. signed or encrypted object.
5.4. XMPP 5.4. XMPP
The Extensible Messaging and Presence Protocol (XMPP) routes messages The Extensible Messaging and Presence Protocol (XMPP) routes messages
from one end client to another by way of XMPP servers [RFC6120]. from one end client to another by way of XMPP servers [RFC6120].
There are typically two servers involved in delivering any given There are typically two servers involved in delivering any given
message: The first client (Alice) sends a message for another client message: The first client (Alice) sends a message for another client
(Bob) to her server (A). Server A uses Bob's identity and the DNS to (Bob) to her server (A). Server A uses Bob's identity and the DNS to
locate the server for Bob's domain (B), then delivers the message to locate the server for Bob's domain (B) and then delivers the message
that server. Server B then routes the message to Bob. to that server. Server B then routes the message to Bob.
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
| Alice |-->| Server A |-->| Server B |-->| Bob | | Alice |-->| Server A |-->| Server B |-->| Bob |
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
Figure 2: Delivering an XMPP message Figure 2: Delivering an XMPP Message
The untrusted-intermediary problems are especially acute for XMPP The untrusted-intermediary problems are especially acute for XMPP
because in many current deployments, the holder of an XMPP domain because in many current deployments, the holder of an XMPP domain
outsources the operation of the domain's servers to a different outsources the operation of the domain's servers to a different
entity. In this environment, there is a clear risk of exposing the entity. In this environment, there is a clear risk of exposing the
domain holder's private information to the domain operator. XMPP domain holder's private information to the domain operator. XMPP
already has a defined mechanism for end-to-end security using S/MIME, already has a defined mechanism for end-to-end security using S/MIME,
but it has failed to gain widespread deployment [RFC3923], in part but it has failed to gain widespread deployment [RFC3923], in part
because of key management challenges and because of the difficulty of because of key management challenges and in part because of the
processing S/MIME objects. difficulty of processing S/MIME objects.
The XMPP working group is in the process of developing a new end-to- The XMPP working group is in the process of developing a new
end encryption system with an encoding based on JOSE and a clearer end-to-end encryption system with an encoding based on JOSE and a
key management system [I-D.miller-xmpp-e2e]. The process of sending clearer key management system [XMPP-E2E]. The process of sending an
an encrypted message in this system involves two steps: First, the encrypted message in this system involves two steps: First, the
sender generates a symmetric Session Master Key (SMK), encrypts the sender generates a symmetric Session Master Key (SMK), encrypts the
message content (including a per-message Content Master Key), and message content (including a per-message Content Master Key), and
sends the encrypted message to the desired set of recipients. sends the encrypted message to the desired set of recipients.
Second, each recipient "dials back" to the sender, providing his Second, each recipient "dials back" to the sender, providing his
public key. The sender then responds with the relevant SMK, wrapped public key. The sender then responds with the relevant SMK, wrapped
with the recipient's public key. with the recipient's public key.
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
| Alice |<->| Server A |<->| Server B |<->| Bob | | Alice |<->| Server A |<->| Server B |<->| Bob |
+-------+ +----------+ +----------+ +-----+ +-------+ +----------+ +----------+ +-----+
| | | | | | | |
|------------Encrypted--message--------->| |------------Encrypted message---------->|
| | | | | | | |
|<---------------Public-key--------------| |<---------------Public key--------------|
| | | | | | | |
|---------------Wrapped SMK------------->| |---------------Wrapped SMK------------->|
| | | | | | | |
Figure 3: Delivering a secure XMPP message Figure 3: Delivering a Secure XMPP Message
The main thing that this system requires from the JOSE formats is The main thing that this system requires from the JOSE formats is
confidentiality protection via content encryption, plus an integrity confidentiality protection via content encryption, plus an integrity
check via a MAC derived from the same symmetric key. The separation check via a MAC derived from the same symmetric key. The separation
of the key exchange from the transmission of the encrypted content, of the key exchange from the transmission of the encrypted content,
however, requires that the JOSE encrypted object format allow wrapped however, requires that the JOSE encrypted object format allow wrapped
symmetric keys to be carried separately from the encrypted payload. symmetric keys to be carried separately from the encrypted payload.
In addition, the encrypted object will need to have a tag for the key In addition, the encrypted object will need to have a tag for the key
that was used to encrypt the content, so that the recipient (Bob) can that was used to encrypt the content, so that the recipient (Bob) can
present the tag to the sender (Alice) when requesting the wrapped present the tag to the sender (Alice) when requesting the wrapped
key. key.
Another important feature of XMPP is that it allows for the Another important feature of XMPP is that it allows for the
simultaneous delivery of a message to multiple recipients. In the simultaneous delivery of a message to multiple recipients. In the
diagrams above, Server A could deliver the message not only to Server diagrams above, Server A could deliver the message not only to Server
B (for Bob) but also to Servers C, D, E, etc. for other users. In B (for Bob) but also to Servers C, D, E, etc., for other users. In
such cases, to avoid the multiple "dial back" transactions implied by such cases, to avoid the multiple "dial back" transactions implied by
the above mechanism, XMPP systems will likely re-use a given SMK for the above mechanism, XMPP systems will likely reuse a given SMK for
multiple individual messages, refreshing the SMK on a periodic and/or multiple individual messages, refreshing the SMK on a periodic and/or
event-driven basis (e.g., when the recipient's presence changes). event-driven basis (e.g., when the recipient's presence changes).
They might also cache public keys for end recipients, so that wrapped They might also cache public keys for end recipients, so that wrapped
keys can be sent along with content on future messages. This implies keys can be sent along with content on future messages. This implies
that the JOSE encrypted object format must support the provision of that the JOSE encrypted object format must support the provision of
multiple versions of the same wrapped SMK (much as a CMS multiple versions of the same wrapped SMK (much as a CMS
EnvelopedData structure can include multiple RecipientInfo EnvelopedData structure can include multiple RecipientInfo
structures). structures).
In the current draft of the XMPP end-to-end security system, each In the current draft of the XMPP end-to-end security system, each
party is authenticated by virtue of the other party's trust in the party is authenticated by virtue of the other party's trust in the
XMPP message routing system. The sender is authenticated to the XMPP message routing system. The sender is authenticated to the
skipping to change at page 12, line 16 skipping to change at page 11, line 52
keys can be sent along with content on future messages. This implies keys can be sent along with content on future messages. This implies
that the JOSE encrypted object format must support the provision of that the JOSE encrypted object format must support the provision of
multiple versions of the same wrapped SMK (much as a CMS multiple versions of the same wrapped SMK (much as a CMS
EnvelopedData structure can include multiple RecipientInfo EnvelopedData structure can include multiple RecipientInfo
structures). structures).
In the current draft of the XMPP end-to-end security system, each In the current draft of the XMPP end-to-end security system, each
party is authenticated by virtue of the other party's trust in the party is authenticated by virtue of the other party's trust in the
XMPP message routing system. The sender is authenticated to the XMPP message routing system. The sender is authenticated to the
receiver because he can receive messages for the identifier "Alice" receiver because he can receive messages for the identifier "Alice"
(in particular, the request for wrapped keys), and can originate (in particular, the request for wrapped keys) and can originate
messages for that identifier (the wrapped key). Likewise, the messages for that identifier (the wrapped key). Likewise, the
receiver is authenticated to the sender because he received the receiver is authenticated to the sender because he received the
original encrypted message and originated the request for wrapped original encrypted message and originated the request for a wrapped
key. So the authentication here requires not only that XMPP routing key. So, the authentication here requires not only that XMPP routing
be done properly, but also that TLS be used on every hop. Moreover, be done properly, but also that TLS be used on every hop. Moreover,
it requires that the TLS channels have strong authentication, since a it requires that the TLS channels have strong authentication, since a
man in the middle on any of the three hops can masquerade as Bob and man in the middle on any of the three hops can masquerade as Bob and
obtain the key material for an encrypted message. obtain the key material for an encrypted message.
Because this authentication is quite weak (depending on the use of Because this authentication is quite weak (depending on the use of
transport-layer security on three hops) and unverifiable by the TLS on three hops) and unverifiable by the endpoints, it is possible
endpoints, it is possible that the XMPP working group will integrate that the XMPP working group will integrate some sort of credentials
some sort of credentials for end recipients, in which case there for end recipients, in which case there would need to be a way to
would need to be a way to associate these credentials with JOSE associate these credentials with JOSE objects.
objects.
Finally, it's worth noting that XMPP is based on XML, not JSON. So Finally, it's worth noting that XMPP is based on XML, not JSON. So
by using JOSE, XMPP will be carrying JSON objects within XML. It is by using JOSE, XMPP will be carrying JSON objects within XML. It is
thus a desirable property for JOSE objects to be encoded in such a thus a desirable property for JOSE objects to be encoded in such a
way as to be safe for inclusion in XML. Otherwise, an explicit CDATA way as to be safe for inclusion in XML. Otherwise, an explicit CDATA
indication must be given to the parser to indicate that it is not to indication must be given to the parser to indicate that it is not to
be parsed as XML. One way to meet this requirement would be to apply be parsed as XML. One way to meet this requirement would be to apply
base64url encoding, but for XMPP messages of medium-to-large size, base64url encoding, but for XMPP messages of medium-to-large size,
this could impose a fair degree of overhead. this could impose a fair degree of overhead.
5.5. ALTO 5.5. ALTO
Application-Layer Traffic Optimization (ALTO) is a system for Application-Layer Traffic Optimization (ALTO) is a system for
distributing network topology information to end devices, so that distributing network topology information to end devices, so that
those devices can modify their behavior to have a lower impact on the those devices can modify their behavior to have a lower impact on the
network [RFC6708]. The ALTO protocol distributes topology network [RFC6708]. The ALTO protocol distributes topology
information in the form of JSON objects carried in HTTP information in the form of JSON objects carried in HTTP [RFC2616]
[RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is [ALTO]. The basic version of ALTO is simply a client-server
simply a client-server protocol, so simple use of HTTPS suffices for protocol, so simple use of HTTPS suffices for this case [RFC2818].
this case [RFC2818]. However, there is beginning to be some However, there is beginning to be some discussion of use cases for
discussion of use cases for ALTO in which these JSON objects will be ALTO in which these JSON objects will be distributed through a
distributed through a collection of intermediate servers before collection of intermediate servers before reaching the client, while
reaching the client, while still preserving the ability of the client still preserving the ability of the client to authenticate the
to authenticate the original source of the object. Even the base original source of the object. Even the base ALTO protocol notes
ALTO protocol notes that "ALTO clients obtaining ALTO information that "ALTO Clients obtaining ALTO information through redistribution
must be able to validate the received ALTO information to ensure that must be able to validate the received ALTO information" to ensure
it was generated by an appropriate ALTO server." that it was generated by an appropriate ALTO server.
In this case, the security requirements are straightforward. JOSE In this case, the security requirements are straightforward. JOSE
objects carrying ALTO payloads will need to bear digital signatures objects carrying ALTO payloads will need to bear digital signatures
from the originating servers, which will be bound to certificates from the originating servers, which will be bound to certificates
attesting to the identities of the servers. There is no requirement attesting to the identities of the servers. There is no requirement
for confidentiality in this case, since ALTO information is generally for confidentiality in this case, since ALTO information is generally
public. public.
The more interesting questions are encoding questions. ALTO objects The more interesting questions are encoding questions. ALTO objects
are likely to be much larger than payloads in the two cases above, are likely to be much larger than payloads in the two cases above,
with sizes of up to several megabytes. Processing of such large with sizes of up to several megabytes. Processing of such large
objects can be done more quickly if it can be done in a single pass, objects can be done more quickly if it can be done in a single pass,
which may be possible if JOSE objects require specific orderings of which may be possible if JOSE objects require specific orderings of
fields within the JSON structure. fields within the JSON structure.
In addition, because ALTO objects are also encoded as JSON, they are In addition, because ALTO objects are also encoded as JSON, they are
already safe for inclusion in a JOSE object. Signed JOSE objects already safe for inclusion in a JOSE object. Signed JOSE objects
will likely carry the signed data in a string alongside the will likely carry the signed data in a string alongside the
signature. JSON objects have the property that they can be safely signature. JSON objects have the property that they can be safely
encoded in JSON strings. All they require is that unnecessary white encoded in JSON strings. All they require is that unnecessary white
space be removed, a much simpler transformation than, say base64url space be removed, a much simpler transformation than, say, base64url
encoding. This raises the question of whether it might be possible encoding. This raises the question of whether it might be possible
to optimize the JOSE encoding for certain "JSON-safe" cases. to optimize the JOSE encoding for certain "JSON-safe" cases.
Finally, it may be desirable for ALTO to have a "detached signature" Finally, it may be desirable for ALTO to have a "detached signature"
mechanism, that is, a way to encode signature information separate mechanism, that is, a way to encode signature information separate
from the protected content. This would allow the ALTO protocol to from the protected content. This would allow the ALTO protocol to
include the signature in an HTTPS header, with the signed content as include the signature in an HTTPS header, with the signed content as
the HTTPS entity body. the HTTPS entity body.
5.6. Emergency Alerting 5.6. Emergency Alerting
Emergency alerting is an emerging use case for IP networks Emergency alerting is an emerging use case for IP networks
[I-D.ietf-atoca-requirements]. Alerting systems allow authorities to [ALERT-REQ]. Alerting systems allow authorities to warn users of
warn users of impending danger by sending alert messages to connected impending danger by sending alert messages to connected devices. For
devices. For example, in the event of hurricane or tornado, alerts example, in the event of a hurricane or tornado, alerts might be sent
might be sent to all devices in the path of the storm. to all devices in the path of the storm.
The most critical security requirement for alerting systems is that The most critical security requirement for alerting systems is that
it must not be possible for an attacker to send false alerts to it must not be possible for an attacker to send false alerts to
devices. Such a capability would potentially allow an attacker to devices. Such a capability would potentially allow an attacker to
create wide-spread panic. In practice, alert systems prevent these create wide-spread panic. In practice, alert systems prevent these
attacks both by controls on sending messages at points where alerts attacks both by controls on sending messages at points where alerts
are originated, as well as by having recipients of alerts verify that are originated, and by having recipients of alerts verify that the
the alert was sent by an authorized source. The former type of alert was sent by an authorized source. The former type of control
control implemented with local security on hosts from which alerts is implemented with local security on hosts from which alerts can be
can be originated. The latter type implemented by digital signatures originated. The latter type is implemented by digital signatures on
on alert messages (using channel-based or object-based mechanisms). alert messages (using channel-based or object-based mechanisms).
With an object-based mechanism, the signature value is encoded in a With an object-based mechanism, the signature value is encoded in a
secure object. With a channel-based mechanism, the alert is "signed" secure object. With a channel-based mechanism, the alert is "signed"
by virtue of being sent over an authenticated, integrity-protected by virtue of being sent over an authenticated, integrity-protected
channel. channel.
Alerts typically reach end recipients via a series of intermediaries. Alerts typically reach end recipients via a series of intermediaries.
For example, while a national weather service might originate a For example, while a national weather service might originate a
hurricane alert, it might first be delivered to a national gateway, hurricane alert, it might first be delivered to a national gateway
and then to network operators, who broadcast it to end subscribers. and then to network operators, who broadcast it to end subscribers.
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| Originator | | Originator | | Originator | | Originator | | Originator | | Originator |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| . . | . .
+-----------------+.................. +-----------------+..................
| |
V V
+---------+ +---------+
skipping to change at page 14, line 45 skipping to change at page 14, line 35
| Network | | Network | | Network | | Network |
+---------+ +---------+ +---------+ +---------+
| | | |
+------+-----+ +------+-----+ +------+-----+ +------+-----+
| | | | | | | |
V V V V V V V V
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
| Device | | Device | | Device | | Device | | Device | | Device | | Device | | Device |
+--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+ +--------+
Figure 4: Delivering an emergency alert Figure 4: Delivering an Emergency Alert
In order to verify alert signatures, recipients must be provisioned In order to verify alert signatures, recipients must be provisioned
with the proper public keys for trusted alert authorities. This with the proper public keys for trusted alert authorities. This
trust may be "piece-wise" along the path the alert takes. For trust may be "piece-wise" along the path the alert takes. For
example, the alert relays operated by networks might have a full set example, the alert relays operated by networks might have a full set
of certificates for all alert originators, while end devices may only of certificates for all alert originators, while end devices may only
trust their local alert relay. Or devices might require that a trust their local alert relay. Or, devices might require that a
device be signed by an authorized originator and by its local device be signed by an authorized originator and by its local
network's relay. network's relay.
This scenario creates a need for multiple signatures on alert This scenario creates a need for multiple signatures on alert
documents, so that an alert can bear signatures from any or all of documents, so that an alert can bear signatures from any or all of
the entities that processed it along the path. In order to minimize the entities that processed it along the path. In order to minimize
complexity, these signatures should be "modular", in the sense that a complexity, these signatures should be "modular" in the sense that a
new signature can be added without a need to alter or recompute new signature can be added without a need to alter or recompute
previous signatures. previous signatures.
5.7. Web Cryptography 5.7. Web Cryptography
The W3C Web Cryptography API defines a standard cryptographic API for The W3C Web Cryptography API defines a standard cryptographic API for
the Web [WebCrypto]. If a browser exposes this API, then JavaScript the Web [WebCrypto]. If a browser exposes this API, then JavaScript
provided as part of a Web page can ask the browser to perform provided as part of a Web page can ask the browser to perform
cryptographic operations, such as digest, MAC, encryption, or digital cryptographic operations, such as digest, MAC, encryption, or digital
signing. signing.
One of the key reasons to have the browser perform cryptographic One of the key reasons to have the browser perform cryptographic
operations is to avoid allowing JavaScript code to access the keying operations is to avoid allowing JavaScript code to access the keying
material used for these operations. For example, this separation material used for these operations. For example, this separation
would prevent code injected through a cross-site scripting (XSS) would prevent code injected through a cross-site scripting (XSS)
attack from reading and exfiltrating keys stored within a browser. attack from reading and exfiltrating keys stored within a browser.
While the malicious code could still use the key while running in the While the malicious code could still use the key while running in the
browser, this vulnerability can only be exercised while the browser, this vulnerability can only be exercised while the malicious
vulnerable page is active in a user's browser. code is active in a user's browser.
However, the WebCryptography API also provides a key export However, the Web Cryptography API also provides a key export
functionality, which can allow JavaScript to extract a key from the functionality, which can allow JavaScript to extract a key from the
API in wrapped form. For example, the JavaScript might provide a API in wrapped form. For example, JavaScript code might provide a
public key for which the corresponding private key is held by another public key for which the corresponding private key is held by another
device. The wrapped key provided by the API could then be used to device. The wrapped key provided by the API could then be used to
safely transport the key to the new device. While this could safely transport the key to the new device. While this could
potentially allow malicious code to export a key, the need for an potentially allow malicious code to export a key, the need for an
explicit export operation provides a control point, allowing for user explicit export operation provides a control point, allowing for user
notification or consent verification. notification or consent verification.
The Web Cryptography API also allows browsers to impose limitations The Web Cryptography API also allows browsers to impose limitations
on the usage of the keys it handles. For example, a symmetric key on the usage of the keys it handles. For example, a symmetric key
might be marked as usable only for encryption, and not for MAC. When might be marked as usable only for encryption, and not for MAC. When
skipping to change at page 16, line 10 skipping to change at page 15, line 47
The Web Cryptography API thus requires formats to express several The Web Cryptography API thus requires formats to express several
forms of keys. Obviously, the public key from an asymmetric key pair forms of keys. Obviously, the public key from an asymmetric key pair
can be freely imported to and exported from the browser, so there can be freely imported to and exported from the browser, so there
needs to be a format for public keys. There is also a need for a needs to be a format for public keys. There is also a need for a
format to express private keys and symmetric keys. For non-public format to express private keys and symmetric keys. For non-public
keys, the primary need is for a wrapped form, where the keys, the primary need is for a wrapped form, where the
confidentiality and integrity of the key is assured confidentiality and integrity of the key is assured
cryptographically; these protections should also apply to any cryptographically; these protections should also apply to any
attributes of the key. It may also be useful to define a direct, attributes of the key. It may also be useful to define a direct,
unwrapped format, for use within a security boundary. unwrapped format for use within a security boundary.
5.8. Constrained Devices 5.8. Constrained Devices
This section describes use cases for constrained devices as defined This section describes use cases for constrained devices as defined
in [I-D.ietf-lwig-terminology]. Typical issues with this type of in [CONSTRAINED]. Typical issues with this type of device are
devices are limited memory, limited power supply, low processing limited memory, limited power supply, low processing power, and
power, and severe message size limitations for the communication severe message size limitations for the communication protocols.
protocols.
5.8.1. Example: MAC based on ECDH-derived key 5.8.1. Example: MAC Based on ECDH-Derived Key
Suppose a small, low power device maker has decided on using the Suppose a small, low power device maker has decided on using the
output of the JOSE working group as their encryption and output of the JOSE working group as their encryption and
authentication framework. The device maker has a limited budget for authentication framework. The device maker has a limited budget for
both gates and power. For this reason there are a number of short both gates and power. For this reason there are a number of short
cuts and design decisions that have been made in order to minimize cuts and design decisions that have been made in order to minimize
these needs. these needs.
The design team has determined that the use of message authentication The design team has determined that the use of MACs is going to be
codes (MAC) is going to be sufficient to provide the necessary sufficient to provide the necessary authentication. However,
authentication. However, although a MAC is going to be used, they do although a MAC is going to be used, they do not want to use a single
not want to use a single long term shared secret. Instead they have long-term shared secret. Instead, they have adopted the following
adopted the following proposal for computing a shared secret that can proposal for computing a shared secret that can be validated:
be validated:
o An Elliptic-Curve Diffie-Hellman (ECDH) key is generated for the o An Elliptic-Curve Diffie-Hellman (ECDH) key pair is generated for
device at the time of manufacturing. (Or as part of the the device at the time of manufacturing. (Or, as part of the
configuration process during installation.) configuration process during installation.)
o An ECDH public key for the controller is configured at the time of o An ECDH public key for the controller is configured at the time of
configuration. configuration.
o The configuration system performs the ECDH computation and o The configuration system performs the ECDH computation and
configures the device with the resulting shared secret. This configures the device with the resulting shared secret. This
process eliminates the need for the device to be able to perform process eliminates the need for the device to be able to perform
the required exponentiation processing. The security requirements the required ECDH processing. The security requirements on
on protecting this computed shared secret are the same as the protecting this computed shared secret are the same as the
requirements on protecting the private ECDH key. requirements on protecting the private ECDH key.
o A counter and an increment value are configured onto the device. o A counter and an increment value are configured onto the device.
o When a message is to be sent by the device, the counter is o When a message is to be sent by the device, the counter is
incremented and a new MAC key is computed from the ECDH secret and incremented and a new MAC key is computed from the ECDH secret and
the counter value. A custom Key Derivation Function (KDF) the counter value. A custom Key Derivation Function (KDF) based
function based on the AES-CBC is used to derive the required MAC on AES-CBC is used to derive the required MAC key. The MAC key is
key. The MAC key is then used to compute the MAC value for the then used to compute the MAC value for the message.
message.
In a similar manner the KDF function can used to compute an AEAD In a similar manner, the KDF function can be used to compute an
algorithm key when the system needs to provide confidentially for the Authenticated Encryption with Associated Data (AEAD) algorithm key
message. The controller, being a larger device will perform the when the system needs to provide confidentiality for the message.
exponentiation step and use a random number generator to generate the The controller, being a larger device, will perform the ECDH step and
sender nonce value. use a random number generator to generate the sender nonce value.
5.8.2. Object security for CoAP 5.8.2. Object Security for CoAP
This use case deals with constrained devices of class C0/C1 (see This use case deals with constrained devices of class C0/C1 (see
[I-D.ietf-lwig-terminology]). These devices communicate using [CONSTRAINED]). These devices communicate using RESTful requests and
RESTful requests and responses transferred using the CoAP protocol responses transferred using the Constrained Application Protocol
[I-D.ietf-core-coap]. To simplify matters, all communication is [CoAP]. To simplify matters, all communication is assumed to be
assumed to be unicast, i.e. these security measures don't cover unicast; i.e., these security measures don't cover multicast or
multicast or broadcast. broadcast.
In this type of setting it may be too costly to use session based In this type of setting, it may be too costly to use session-based
security (e.g. to run a 4 pass authentication protocol) since security (e.g., to run a 4-pass authentication protocol) since
receiving and in particular sending consumes a lot of power, in receiving and in particular sending consumes a lot of power,
particular for wireless devices. Therefore to just secure the CoAP especially for wireless devices. Therefore, to just secure the CoAP
payload by replacing a plain text payload of a request or response payload by replacing a plaintext payload of a request or response
with a JWE object is an important alternative solution, which allows with a JWE object is an important alternative solution, which allows
a trade-off between protection (the CoAP headers are not protected) a trade-off between protection (the CoAP headers are not protected)
and performance. and performance.
In a simple setting, consider the payload of a CoAP GET response from In a simple setting, consider the payload of a CoAP GET response from
a sensor type device. The information in a sensor reading may be a sensor type device. The information in a sensor reading may be
privacy or business sensitive and needs both integrity protection and privacy or business sensitive and needs both integrity protection and
encryption. encryption.
However some sensor readings are very short, say a few bytes, and in However, some sensor readings are very short, say, a few bytes, and
this case default encryption and integrity protection algorithms in this case, default encryption and integrity protection algorithms
(such as 128 bit AES with HMAC_SHA256) may cause a dramatic message (such as 128-bit AES-CBC with HMAC_SHA256) may cause a dramatic
expansion of the payload, even disregarding JWE headers. expansion of the payload, even disregarding JWE headers.
Also the value of certain sensor readings may decline rapidly, e.g. Also, the value of certain sensor readings may decline rapidly, e.g.,
traffic or environmental measurements, so it must be possible to traffic or environmental measurements, so it must be possible to
reduce the security overhead. reduce the security overhead.
This leads to the following requirements which could be covered by This leads to the following requirements that could be covered by
specific JWE/JWS profiles: specific JWE/JWS profiles:
o The size of the secure object shall be as small as possible. o The size of the secure object shall be as small as possible.
Receiving an object may cost orders of magnitude more in terms of Receiving an object may cost orders of magnitude more in terms of
power than performing say public key cryptography on the object, power than performing, say, public key cryptography on the object,
in particular in a wireless setting. in particular in a wireless setting.
o Integrity protection: The object shall be able to support o Integrity protection: The object shall be able to support
integrity protection, i.e. have a field containing a digital integrity protection, i.e., have a field containing a digital
signature, both public key signatures and keyed message signature, both public key signatures and keyed MACs shall be
authentication codes shall be supported. supported.
o Encryption: The object shall be able to support encryption as an o Encryption: The object shall be able to support encryption as an
optional addition to integrity protection. It shall be possible optional addition to integrity protection. It shall be possible
to exclude certain fields from encryption which are needed before to exclude certain fields from encryption, which are needed before
verifying integrity or decrypting the object. verifying integrity or decrypting the object.
o Cipher suites: It should be possible to support a variety of o Cipher suites: It should be possible to support a variety of
cipher suites to support the constrained devices use cases. For cipher suites to support the constrained devices' use cases. For
example: example:
* Block ciphers with block sizes of e.g. 96 bits, in addition to * Block ciphers with block sizes of, e.g., 96 bits, in addition
the standard 128 bits to the standard 128 bits.
* Modes of operation for block ciphers that do not expand the * Modes of operation for block ciphers that do not expand the
message size to a block boundary, such as AES-GCM. message size to a block boundary, such as AES-GCM.
* Cipher suites that support combined encryption and MAC * Cipher suites that support combined encryption and MAC
calculation (i.e., AEAD modes for block ciphers). calculation (i.e., AEAD modes for block ciphers).
6. Requirements 6. Requirements
This section summarizes the requirements from the above uses cases, This section summarizes the requirements from the above use cases and
and lists further requirements not directly derived from the above lists further requirements not directly derived from the above use
use cases. There are also some constraints that are not hard cases. There are also some constraints that are not hard
requirements, but which are still desirable properties for the JOSE requirements but that are still desirable properties for the JOSE
system to have. system to have.
6.1. Functional Requirements 6.1. Functional Requirements
F1 Define formats for secure objects that provide the following F1 Define formats for secure objects that provide the following
security properties: security properties:
* Digital signature (integrity/authentication under an asymmetric * Digital signature (integrity/authentication under an asymmetric
key pair) key pair)
skipping to change at page 19, line 16 skipping to change at page 19, line 10
F2 Define a format for public keys and private keys for asymmetric F2 Define a format for public keys and private keys for asymmetric
cryptographic algorithms, with associated attributes, including a cryptographic algorithms, with associated attributes, including a
wrapped form for private keys. wrapped form for private keys.
F3 Define a format for symmetric keys with associated attributes, F3 Define a format for symmetric keys with associated attributes,
allowing for both wrapped and unwrapped keys. allowing for both wrapped and unwrapped keys.
F4 Define a JSON serialization for each of the above objects. An F4 Define a JSON serialization for each of the above objects. An
object in this encoding must be valid according to the JSON ABNF object in this encoding must be valid according to the JSON ABNF
syntax [RFC4627]. syntax [RFC7159].
F5 Define a compact, URL-safe text serialization for the encrypted F5 Define a compact, URL-safe text serialization for the encrypted
signed object formats. and signed object formats.
F6 Allow for attributes associated to wrapped keys to be bound to F6 Allow for attributes associated to wrapped keys to be bound to
them cryptographically them cryptographically.
F7 Allow for wrapped keys to be separated from a secure object that F7 Allow for wrapped keys to be separated from a secure object that
uses a symmetric key. In such cases, cryptographic components of uses a symmetric key. In such cases, cryptographic components of
the secure object other than the wrapped key (e.g., ciphertext, the secure object other than the wrapped key (e.g., ciphertext,
MAC values) must be independent of the wrapped form of the key. MAC values) must be independent of the wrapped form of the key.
For example, if an encrypted object is prepared for multiple For example, if an encrypted object is prepared for multiple
recipients, then only the wrapped key may vary, not the recipients, then only the wrapped key may vary, not the
ciphertext. ciphertext.
F8 Do not impose more overhead than is required to meet the F8 Do not impose more overhead than is required to meet the
skipping to change at page 19, line 48 skipping to change at page 19, line 42
S1 Provide mechanisms to avoid repeated use of the same symmetric key S1 Provide mechanisms to avoid repeated use of the same symmetric key
for encryption or MAC computation. Instead, long-lived keys for encryption or MAC computation. Instead, long-lived keys
should be used only for key wrapping, not for direct encryption/ should be used only for key wrapping, not for direct encryption/
MAC. It should be possible to use any of the key management MAC. It should be possible to use any of the key management
techniques provided in CMS [RFC5652]: techniques provided in CMS [RFC5652]:
* Key transport (wrapping for a public key) * Key transport (wrapping for a public key)
* Key encipherment (wrapping for a symmetric key) * Key encipherment (wrapping for a symmetric key)
* Key agreement (wrapping for a DH public key) * Key agreement (wrapping for a Diffie-Hellman (DH) public key)
* Password-based encryption (wrapping under a key derived from a * Password-based encryption (wrapping under a key derived from a
password) password)
S2 Where long-lived symmetric keys are used directly for S2 Where long-lived symmetric keys are used directly for
cryptographic operations (i.e., where requirement S1 is not met), cryptographic operations (i.e., where requirement S1 is not met),
provide deployment guidance on key management practices, such as provide deployment guidance on key management practices, such as
the need to limit key lifetimes. the need to limit key lifetimes.
S3 Use cryptographic algorithms in a manner compatible with major S3 Use cryptographic algorithms in a manner compatible with major
skipping to change at page 20, line 24 skipping to change at page 20, line 19
purpose Y. purpose Y.
S4 Support operation with or without pre-negotiation. It must be S4 Support operation with or without pre-negotiation. It must be
possible to create or process secure objects without any possible to create or process secure objects without any
configuration beyond key provisioning. If it is possible for keys configuration beyond key provisioning. If it is possible for keys
to be derived from application context, it must be possible for a to be derived from application context, it must be possible for a
recipient to recognize when it does not have the appropriate key. recipient to recognize when it does not have the appropriate key.
6.3. Desiderata 6.3. Desiderata
D1 Maximize compatibility with the W3C WebCrypto specifications, D1 Maximize compatibility with the W3C Web Crypto specifications,
e.g., by coordinating with the WebCrypto working group to e.g., by coordinating with the Web Crypto working group to
encourage alignment of algorithms and algorithm identifiers. encourage alignment of algorithms and algorithm identifiers.
D2 Avoid JSON canonicalization to the extent possible. That is, all D2 Avoid JSON canonicalization to the extent possible. That is, all
other things being equal, techniques that rely on fixing a other things being equal, techniques that rely on fixing a
serialization of an object (e.g., by base64url encoding it) are serialization of an object (e.g., by encoding it with base64url)
preferred over those that require converting an object to a are preferred over those that require converting an object to a
canonical form. canonical form.
D3 Maximize the extent to which the inputs and outputs of JOSE D3 Maximize the extent to which the inputs and outputs of JOSE
cryptographic operations can be controlled by the applications, as cryptographic operations can be controlled by the applications, as
opposed to involving processing specific to JOSE. This allows opposed to involving processing specific to JOSE. This allows
JOSE the flexibility to address the needs of many cryptographic JOSE the flexibility to address the needs of many cryptographic
protocols. For example, in some cases, might allow JOSE objects protocols. For example, in some cases, it might allow JOSE
to be translated to legacy formats such as CMS without the need objects to be translated to legacy formats such as CMS without the
for re-encryption or re-signing. need for re-encryption or re-signing.
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations 7. Security Considerations
The primary focus of this document is the requirements for a JSON- The primary focus of this document is the requirements for a JSON-
based secure object format. At the level of general security based secure object format. At the level of general security
considerations for object-based security technologies, the security considerations for object-based security technologies, the security
considerations for this format are the same as for CMS [RFC5652]. considerations for this format are the same as for CMS [RFC5652].
The primary difference between the JOSE format and CMS is that JOSE The primary difference between the JOSE format and CMS is that JOSE
is based on JSON, which does not have a canonical representation. is based on JSON, which does not have a canonical representation.
The lack of a canonical form means that it is difficult to determine The lack of a canonical form means that it is difficult to determine
whether two JSON objects represent the same information, which could whether two JSON objects represent the same information, which could
lead to vulnerabilities in some usages of JOSE. lead to vulnerabilities in some usages of JOSE.
9. References 8. References
9.1. Normative References
[RFC4627] Crockford, D., "The application/json Media Type for 8.1. Normative References
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
RFC 4949, August 2007. 4949, August 2007.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, September 2009. RFC 5652, September 2009.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011. Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and [RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", RFC 6708, September 2012. Requirements", RFC 6708, September 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
RFC 6749, October 2012. 6749, October 2012.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[W3C.REC-xml] [W3C.REC-xml]
Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, Bray, T., Maler, E., Paoli, J., and C. Sperberg-McQueen,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC- "Extensible Markup Language (XML) 1.0 (Fifth Edition)",
xml, October 2000, <http://www.w3.org/TR/REC-xml>. W3C Recommendation, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126/>.
[WebCrypto] [WebCrypto]
Sleevi, R. and D. Dahl, "Web Cryptography API", Dahl, D. and R. Sleevi, "Web Cryptography API", W3C
January 2013. Working Draft, January 2013,
<http://www.w3.org/TR/2013/WD-WebCryptoAPI-20130108/>.
9.2. Informative References
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol
v1.1", October 2005.
[I-D.ietf-alto-protocol] 8.2. Informative References
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-21 (work in progress),
November 2013.
[I-D.ietf-atoca-requirements] [ALERT-REQ]
Schulzrinne, H., Norreys, S., Rosen, B., and H. Schulzrinne, H., Norreys, S., Rosen, B., and H.
Tschofenig, "Requirements, Terminology and Framework for Tschofenig, "Requirements, Terminology and Framework for
Exigent Communications", draft-ietf-atoca-requirements-03 Exigent Communications", Work in Progress, March 2012.
(work in progress), March 2012.
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms-18 (work in progress),
November 2013.
[I-D.ietf-jose-json-web-encryption]
Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption-18
(work in progress), November 2013.
[I-D.ietf-jose-json-web-key] [ALTO] Alimi, R., Ed., Penno, R., Ed., and Y. Yang, Ed., "ALTO
Jones, M., "JSON Web Key (JWK)", Protocol", Work in Progress, March 2014.
draft-ietf-jose-json-web-key-18 (work in progress),
November 2013.
[I-D.ietf-jose-json-web-signature] [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol,
Jones, M., Bradley, J., and N. Sakimura, "JSON Web v1.1", OASIS Standard CAP-V1.1, October 2005,
Signature (JWS)", draft-ietf-jose-json-web-signature-18 <http://www.oasis-open.org/committees/download.php/15135/
(work in progress), November 2013. emergency-CAPv1.1-Corrected_DOM.pdf>.
[I-D.ietf-lwig-terminology] [CONSTRAINED]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-05 Constrained Node Networks", Work in Progress, March 2014.
(work in progress), July 2013.
[I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-13 (work in
progress), November 2013.
[I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer-06
(work in progress), July 2013.
[I-D.ietf-oauth-saml2-bearer]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer-17
(work in progress), July 2013.
[I-D.miller-xmpp-e2e] [CoAP] Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Miller, M., "End-to-End Object Encryption and Signatures Application Protocol (CoAP)", Work in Progress, June 2013.
for the Extensible Messaging and Presence Protocol
(XMPP)", draft-miller-xmpp-e2e-06 (work in progress),
June 2013.
[ITU.X690.2002] [ITU.X690.2002]
International Telecommunications Union, "Information International Telecommunications Union, "Information
Technology - ASN.1 encoding rules: Specification of Basic Technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, 2002. X.690, July 2002.
[JWA] Jones, M., "JSON Web Algorithms (JWA)", Work in Progress,
March 2014.
[JWE] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
Work in Progress, March 2014.
[JWK] Jones, M., "JSON Web Key (JWK)", Work in Progress, March
2014.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", Work in Progress, March 2014.
[JWT-BEARER]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", Work in Progress, March 2014.
[JWT] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", Work in Progress, March 2014.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Maler, E., and R. Philpott,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocols for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", Oasis Standard, March 2005,
2.0-os, March 2005. <http://docs.oasis-open.org/security/saml/v2.0/
saml-core-2.0-os.pdf>.
[OpenID.Messages] [OpenID.Core]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Bradley, J., de Medeiros, B., Jones, M., Mortimore, C.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", and N. Sakimura, "OpenID Connect Core 1.0", December 2013,
May 2013, <http://openid.net/specs/openid-connect-core-1_0.html>.
<http://openid.net/specs/
openid-connect-messages-1_0.html>.
[Persona] Mozilla, "Mozilla Persona", April 2013. [Persona] Mozilla Developer Network, "Mozilla Persona", April 2013,
<https://developer.mozilla.org/en-US/docs/Persona>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over
Transport Layer Security", RFC 3207, February 2002. Transport Layer Security", RFC 3207, February 2002.
skipping to change at page 24, line 22 skipping to change at page 23, line 37
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
Framework: Bearer Token Usage", RFC 6750, October 2012. Framework: Bearer Token Usage", RFC 6750, October 2012.
[SAML2] Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and
Authorization Grants", Work in Progress, March 2014.
[W3C.xmldsig-core] [W3C.xmldsig-core]
Eastlake, D., Reagle , J., and D. Solo, "XML-Signature Eastlake, D., Reagle, J., and D. Solo, "XML-Signature
Syntax and Processing", W3C Recommendation xmldsig-core, Syntax and Processing", W3C Recommendation, June 2008,
October 2000, <http://www.w3.org/TR/xmldsig-core/>. <http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/>.
[W3C.xmlenc-core] [W3C.xmlenc-core]
Eastlake, D. and J. Reagle , "XML Encryption Syntax and Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", W3C Candidate Recommendation xmlenc-core, Processing", W3C Candidate Recommendation, December 2002,
August 2002, <http://www.w3.org/TR/xmlenc-core/>. <http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/>.
[WS-Federation] [WS-Federation]
Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, "Web Goodner, M., Kaler, C., McIntosh, M., and A. Nadalin, "Web
Services Federation Language (WS-Federation) Version 1.2", Services Federation Language (WS-Federation) Version 1.2",
May 2009, <http://docs.oasis-open.org/wsfed/federation/ Oasis Standard, May 2009, <http://docs.oasis-open.org/
v1.2/os/ws-federation-1.2-spec-os.html>. wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html>.
[XMPP-E2E] Miller, M., "End-to-End Object Encryption and Signatures
for the Extensible Messaging and Presence Protocol
(XMPP)", Work in Progress, June 2013.
Appendix A. Acknowledgements Appendix A. Acknowledgements
Thanks to Matt Miller for discussions related to XMPP end-to-end Thanks to Matt Miller for discussions related to the XMPP end-to-end
security model, and to Mike Jones for considerations related to security model and to Mike Jones for considerations related to
security tokens and XML security. Thanks to Mark Watson for raising security tokens and XML security. Thanks to Mark Watson for raising
the need for representing symmetric keys and binding attributes to the need for representing symmetric keys and binding attributes to
them. Thanks to Ludwig Seitz for contributing the constrained device them. Thanks to Ludwig Seitz for contributing the constrained device
use case. use case.
Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]]
-05
o Added use case text for JOSE objects without cryptographic
protection.
-04
o Updated the XMPP use case to more closely match the current XMPP
E2E spec
o Noted that applications should pick a serialization
o Adde back some functional requirements that were accidentally
deleted
-03
o Replaced the "small device" case with the "constrained device"
case
o Added S2 to cover cases where the WG decides not to implement S1
o Addressed multiple other WGLC comments
-02
o Referenced the JWS, JWE, JWK, and JWA specifications making the
"signed object format", "encrypted object format", "key format",
and algorithms resulting from these use cases concrete.
o Added "Requirements on Application Protocols" section.
o Broke former huge "Security Tokens and Authorization" Use Case
section into "Security Tokens", "OAuth", and "Federation" Use Case
sections.
o Cited Mozilla Persona as a single-sign-on (SSO) system using JWTs
and JOSE data formats.
o Spelling and grammar corrections.
-01
o Added the "Small Devices" use case
-00
o Created the initial IETF draft based upon
draft-barnes-jose-use-cases-01 with some additions.
Author's Address Author's Address
Richard Barnes Richard Barnes
BBN Technologies Mozilla
1300 N 17th St 331 E. Evelyn Ave.
Arlington, VA 22209 Mountain View, CA 94041
US US
Email: rlb@ipv.sx EMail: rlb@ipv.sx
 End of changes. 132 change blocks. 
467 lines changed or deleted 371 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/