draft-ietf-jose-use-cases-02.txt   draft-ietf-jose-use-cases-03.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational May 29, 2013 Intended status: Informational July 14, 2013
Expires: November 30, 2013 Expires: January 15, 2014
Use Cases and Requirements for JSON Object Signing and Encryption (JOSE) Use Cases and Requirements for JSON Object Signing and Encryption (JOSE)
draft-ietf-jose-use-cases-02 draft-ietf-jose-use-cases-03
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. In the past, the Cryptographic Message Syntax has transport layer. In the past, the Cryptographic Message Syntax (CMS)
provided a binary secure object format based on ASN.1. Over time, has provided a binary secure object format based on ASN.1. Over
the use of binary object encodings such as ASN.1 has been overtaken time, the use of binary object encodings such as ASN.1 has been
by text-based encodings, for example JavaScript Object Notation. overtaken by text-based encodings, for example JavaScript Object
This document defines a set of use cases and requirements for a Notation. This document defines a set of use cases and requirements
secure object format encoded using JavaScript Object Notation, drawn for a secure object format encoded using JavaScript Object Notation
from a variety of application security mechanisms currently in (JSON), drawn from a variety of application security mechanisms
development. currently in development.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2013. This Internet-Draft will expire on January 15, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
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. Federation . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 14 5.7. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 14
5.8. Small Devices . . . . . . . . . . . . . . . . . . . . . . 15 5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 15
6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.8.1. Example: MAC based on ECDH-derived key . . . . . . . . 16
6.1. Functional Requirements . . . . . . . . . . . . . . . . . 17 5.8.2. Object security for CoAP . . . . . . . . . . . . . . . 17
6.2. Security Requirements . . . . . . . . . . . . . . . . . . 18 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Functional Requirements . . . . . . . . . . . . . . . . . 18
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.2. Security Requirements . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
Appendix B. Document History . . . . . . . . . . . . . . . . . . 23 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix B. Document History . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25
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, which create a secure channel at the IP layer or technologies such as IPsec and TLS, which create a secure channel at
transport layer over which application data can flow the IP layer or transport layer over which application data can flow
[RFC4301][RFC5246]. These mechanisms, however, cannot provide end- [RFC4301][RFC5246]. These mechanisms, however, cannot provide end-
to-end security in some cases. For example, in protocols with to-end security in some cases. For example, in protocols with
application-layer intermediaries, channel-based security protocols application-layer intermediaries, channel-based security protocols
would protect messages from attackers between intermediaries, but not would protect messages from attackers between intermediaries, but not
from the intermediaries themselves. These cases require object-based from the intermediaries themselves. These cases require object-based
security technologies, which embed application data within a secure security technologies, which embed application data within a secure
object that can be safely handled by untrusted entities. 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.,
[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 for secure
objects (CMS) [RFC5652]. CMS is defined using Abstract Syntax objects (CMS) [RFC5652]. CMS is defined using Abstract Syntax
Notation 1 (ASN.1) and traditionally encoded using the ASN.1 Notation 1 (ASN.1) and traditionally encoded using the ASN.1
Distinguished Encoding Rules (DER), which define a binary encoding of Distinguished Encoding Rules (DER), which define a binary encoding of
the protected message and associated parameters [ITU.X690.1994]. In the protected message and associated parameters [ITU.X690.2002]. In
recent years, usage of ASN.1 has decreased (along with other binary recent years, usage of ASN.1 has decreased (along with other binary
encodings for general objects), while more applications have come to encodings for general objects), while more applications have come to
rely on text-based formats such as the Extensible Markup Language rely on text-based formats such as the Extensible Markup Language
(XML) or the JavaScript Object Notation (JSON) (XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON)
[W3C.REC-xml-1998][RFC4627]. [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 Signatures and XML Encryption [W3C.xmldsig-core][W3C.xmlenc-core].
[W3C.CR-xmldsig-core2-20120124][W3C.CR-xmlenc-core1-20120313]. These These mechanisms are defined for use with several security token
mechanisms are defined for use with several security token systems systems (e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation
(e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation
[WS-Federation]) and the CAP emergency alerting format [CAP]. In [WS-Federation]) and the CAP emergency alerting format [CAP]. In
practice, however, XML-based secure object formats introduce similar practice, however, XML-based secure object formats introduce similar
levels of complexity to ASN.1, so developers that lack the tools or levels of complexity to ASN.1, so developers that lack the tools or
motivation to handle ASN.1 aren't likely to use XML security either. motivation to handle ASN.1 aren't likely to use XML security either.
This situation motivates the creation of a JSON-based secure object This situation motivates the creation of a JSON-based secure object
format that is simple enough to implement and deploy that it can be format that is simple enough to implement and deploy that it can be
easily adopted by developers with minimal effort and tools. easily adopted by developers with minimal effort and tools.
2. Definitions 2. Definitions
skipping to change at page 4, line 48 skipping to change at page 4, line 47
3. A format for expressing keys 3. A format for expressing keys
In this document, we will refer to these as the "signed object In this document, we will refer to these as the "signed object
format", the "encrypted 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
[I-D.ietf-jose-json-web-signature] [I-D.ietf-jose-json-web-signature]
[I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key]. [I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-key].
Algorithms and algorithm identifiers used by JWS, JWE, and JWK are Algorithms and algorithm identifiers used by JWS, JWE, and JWK are
defined in JSON Web Algorithms (JWS) defined in JSON Web Algorithms (JWA)
[I-D.ietf-jose-json-web-algorithms]. [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 using
symmetric keys (MACs). symmetric keys (MACs).
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
skipping to change at page 5, line 45 skipping to change at page 5, line 43
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 Message Authentication Codes (MACs), for the case where the
sender and receiver share only a symmetric key. sender and receiver share only 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 confusing endpoints that lack the object. However, in order to avoid confusion, endpoints that lack
necessary context need to be able to recognize this and fail cleanly. the necessary context need to be able to recognize this and fail
Other than keys, JOSE objects do not support pre-negotiation; all cleanly. Other than keys, JOSE objects do not support pre-
cryptographic parameters must be expressed directly in the JOSE negotiation; all cryptographic parameters must be expressed directly
object. in the JOSE object.
o The JOSE signed and encrypted object formats must define the o The JOSE signed and encrypted object formats must define the
process by which an implementation recognizes whether it has the process by which an implementation recognizes whether it has the
key required to process a given object. key required to process a given object, whether the key is
specified by the object or by some out-of-band mechanism.
o Each algorithm used for JOSE must define which parameters are o Each algorithm used for JOSE must define which parameters are
required to be present in a JOSE object using that algorithm. required to be present in a JOSE object using that algorithm.
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.
skipping to change at page 6, line 43 skipping to change at page 6, line 41
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 an object is
able to properly decrypt an encrypted object or verify a signature. able to properly decrypt an encrypted object or verify a signature.
In order to make use of JOSE, however, applications will need to In order to make use of JOSE, however, applications will need to
specify several aspects of how JOSE is to be used: specify several aspects of how JOSE is to be used:
o What application data are 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
5. Use Cases 5. Use Cases
skipping to change at page 8, line 35 skipping to change at page 8, line 35
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). So again we have a case
where an application object is transported via untrusted 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. Data origin authentication is required so that encoded in the token. Although the Resource Owner is ultimately the
the Resource Server can verify that the token was issued by a trusted entity that grants authorization, it is not trusted to modify the
Authorization Server. Confidentiality protection may also be needed, authorization token, since this could, for example, grant access to
if the Authorization Server is concerned about the visibility of resources not owned by the Resource Owner.
permissions information to the Resource Owner or Client. For
example, permissions related to social networking might be considered Data origin authentication is required so that the Resource Server
private information. Note, however, that OAuth already requires that can verify that the token was issued by a trusted Authorization
the underlying HTTP transactions be protected by TLS, so Server.
confidentiality protection is not strictly necessary for this use
case. Confidentiality protection may also be needed, if the Authorization
Server is concerned about the visibility of permissions information
to the Resource Owner or Client. For example, permissions related to
social networking might be considered private information. Note,
however, that OAuth already requires that the underlying HTTP
transactions be protected by TLS, so tokens are already
confidentiality-protected from entities other than the Resource Owner
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 JWT, the "client_id" parameter public or symmetric key. In OAuth, the "client_id" parameter
identifies the key to be used. 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.
skipping to change at page 9, line 36 skipping to change at page 9, line 43
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. For
some mobile browsers, this limit is even smaller. So this use case some mobile browsers, this limit is even smaller. So this use case
requires that a JOSE object have sufficiently small size even after requires that a JOSE object have sufficiently small size even after
signing, possibly encrypting, while still being simple to include in signing, possibly encrypting, while still being simple to include in
an HTTP URI query parameter. an HTTP URI query parameter.
5.3. Federation 5.3. Federation
Security tokens and OAuth are used in two federated identity Security tokens are used in two federated identity protocols, which
protocols, which have similar requirements to the general have similar requirements to the general considerations discussed
considerations discussed above: above:
o The OpenID Connect protocol [OpenID.Messages] is a simple, REST/ o The OpenID Connect protocol [OpenID.Messages] is a simple, REST/
JSON-based identity federation protocol layered on OAuth 2.0. It JSON-based identity federation protocol layered on OAuth 2.0. It
uses the JWT and JOSE formats both to represent security tokens uses the JWT and JOSE formats both to represent security tokens
and to provide security for other protocol messages (performing and to provide security for other protocol messages (performing
signing and optionally encryption). OpenID Connect negotiates the signing and optionally encryption). OpenID Connect negotiates the
algorithms to be used and distributes information about the keys algorithms to be used and distributes information about the keys
to be used using protocol elements that are not part of the JWT to be used using protocol elements that are not part of the JWT
and JOSE header parameters. and JOSE header parameters.
skipping to change at page 10, line 12 skipping to change at page 10, line 19
represent information about identities, applications, and keys for represent information about identities, applications, and keys for
participating entities. Persona distributes the keys used as participating entities. Persona distributes the keys used as
claims in JWT messages and not by using JOSE header parameters. claims in JWT messages and not by using JOSE header parameters.
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
(B) 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), then delivers the message to
that server. Server B then routes the message to Bob. 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
skipping to change at page 13, line 15 skipping to change at page 13, line 15
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"
mechanism, that is, a way to encode signature information separate
from the protected content. This would allow the ALTO protocol to
include the signature in an HTTPS header, with the signed content as
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 [I-D.ietf-atoca-requirements]. Alerting systems allow authorities to
warn users of impending danger by sending alert messages to connected warn users of impending danger by sending alert messages to connected
devices. For example, in the event of hurricane or tornado, alerts devices. For example, in the event of hurricane or tornado, alerts
might be sent to all devices in the path of the storm. might be sent 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, as well as by having recipients of alerts verify that
the alert was sent by an authorized source. The former type of the alert was sent by an authorized source. The former type of
control implemented with local security on hosts from which alerts control implemented with local security on hosts from which alerts
can be originated. The latter type implemented by digital signatures can be originated. The latter type implemented by digital signatures
on alert messages (using channel-based or object-based mechanisms). on alert messages (using channel-based or object-based mechanisms).
With an object-based mechanism, the signature value is encoded in a
secure object. With a channel-based mechanism, the alert is "signed"
by virtue of being sent over an authenticated, integrity-protected
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 |
+------------+ +------------+ +------------+ +------------+ +------------+ +------------+
| . . | . .
skipping to change at page 15, line 44 skipping to change at page 15, line 44
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. Small Devices 5.8. Constrained Devices
A small, low power device maker has decided on using the output of This section describes use cases for constrained devices as defined
the JOSE working group as their encryption and authentication in [I-D.ietf-lwig-terminology]. Typical issues with this type of
framework. The device maker has a limited availability of both real devices are limited memory, limited power supply, low processing
estate for gates and power. For this reason there are a number of power, and severe message size limitations for the communication
short cuts and design decisions that have been made in order to protocols.
minimize these needs.
5.8.1. Example: MAC based on ECDH-derived key
Suppose a small, low power device maker has decided on using the
output of the JOSE working group as their encryption and
authentication framework. The device maker has a limited budget for
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
these needs.
The design team has determined that the use of message authentication The design team has determined that the use of message authentication
codes (MAC) is going to be sufficient to provide the necessary codes (MAC) is going to be sufficient to provide the necessary
authentication. However, although a MAC is going to be used, they do authentication. However, although a MAC is going to be used, they do
not want to use a single long term shared secret. Instead they have not want to use a single long term shared secret. Instead they have
adopted the following proposal for computing a shared secret that can adopted the following 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 is generated for the
device at the time of manufacturing. (Or as part of 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 exponentiation 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 exponentiation processing. The security requirements
on protecting this computed shared secret are the same as the on 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
skipping to change at page 16, line 41 skipping to change at page 17, line 5
function is used when is based on the AES-CBC is used to derive function is used when is based on the AES-CBC is used to derive
the required MAC key. The MAC key is then used to compute the MAC the required MAC key. The MAC key is then used to compute the MAC
value for the message. value for the message.
In a similar manner the KDF function can used to compute an AEAD In a similar manner the KDF function can used to compute an AEAD
algorithm key when the system needs to provide confidentially for the algorithm key when the system needs to provide confidentially for the
message. The controller, being a larger device will perform the message. The controller, being a larger device will perform the
exponentiation step and use a random number generator to generate the exponentiation step and use a random number generator to generate the
sender nonce value. sender nonce value.
6. Requirements 5.8.2. Object security for CoAP
This section summarizes the requirements from the above uses cases, This use case deals with constrained devices of class C0/C1 (see
and lists further requirements not directly derived from the above [I-D.ietf-lwig-terminology]). These devices communicate using
use cases. There are also some constraints that are not hard RESTful requests and responses transferred using the CoAP protocol
requirements, but which are still desirable properties for the JOSE [I-D.ietf-core-coap]. To simplify matters, all communication is
system to have. assumed to be unicast, i.e. these security measures don't cover
multicast or broadcast.
6.1. Functional Requirements 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
receiving and in particular sending consumes a lot of power, in
particular for wireless devices. Therefore to just secure the CoAP
payload by replacing a plain text payload of a request or response
with a JWE object is an important alternative solution, which allows
a trade-off between protection (the CoAP headers are not protected)
and performance.
F1 Define formats for secure objects that provide the following In a simple setting, consider the payload of a CoAP GET response from
security properties: a sensor type device. The information in a sensor reading may be
privacy or business sensitive and needs both integrity protection and
encryption.
* Digital signature (integrity/authentication under an asymmetric However some sensor readings are very short, say a few bytes, and in
key pair) this case default encryption and integrity protection algorithms
(such as 128 bit AES with HMAC_SHA256) may cause a dramatic message
expansion of the payload, even disregarding JWE headers.
* Message authentication (integrity/authentication under a Also the value of certain sensor readings may decline rapidly, e.g.
symmetric key) traffic or environmental measurements, so it must be possible to
reduce the security overhead.
* Encryption This leads to the following requirements which could be covered by
specific JWE/JWS profiles:
* Authenticated encryption 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
power than performing say public key cryptography on the object,
in particular in a wireless setting.
That is, the secure objects defined by this working group should o Integrity protection: The object shall be able to support
provide equivalent security properties to the CMS SignedData, integrity protection, i.e. have a field containing a digital
AuthenticatedData, EnvelopedData, and AuthEnveloped data objects signature, both public key signatures and keyed message
[RFC5652] [RFC5083]. authentication codes shall be supported.
F2 Define a format for public keys and private keys for asymmetric o Encryption: The object shall be able to support encryption as an
cryptographic algorithms, with associated attributes, including a optional addition to integrity protection. It shall be possible
wrapped form for private keys. to exclude certain fields from encryption which are needed before
verifying integrity or decrypting the object.
F3 Define a format for symmetric keys with associated attributes, o Cipher suites: It should be possible to support a variety of
allowing for both wrapped and unwrapped keys. cipher suites to support the constrained devices use cases. For
example:
F4 Define a JSON serialization for the above objects. An object in * Block ciphers with block sizes of e.g. 96 bits, in addition to
this encoding must be valid according to the JSON ABNF syntax the standard 128 bits
[RFC4627]
F5 Define a compact, URL-safe text serialization for the above * Modes of operation for block ciphers that do not expand the
objects. message size to a block boundary, such as AES-GCM.
* Cipher suites that support combined encryption and MAC
calculation (i.e., AEAD modes for block ciphers).
6. Requirements
This section summarizes the requirements from the above uses cases,
and lists further requirements not directly derived from the above
use cases. There are also some constraints that are not hard
requirements, but which are still desirable properties for the JOSE
system to have.
6.1. Functional Requirements
F4 Define a JSON serialization for each of the above objects. An
object in this encoding must be valid according to the JSON ABNF
syntax [RFC4627].
F5 Define a compact, URL-safe text serialization for the encrypted
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
requirements in this document, especially when a large amount of
application content is being protected.
6.2. Security Requirements 6.2. Security Requirements
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 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 Use cryptographic algorithms in a manner compatible with major S2 Where long-lived symmetric keys are used directly for
cryptographic operations (i.e., where requirement S1 is not met),
provide deployment guidance on key management practices, such as
the need to limit key lifetimes.
S3 Use cryptographic algorithms in a manner compatible with major
validation processes. For example, if a FIPS standard allows validation processes. For example, if a FIPS standard allows
algorithm A to be used for purpose X but not purpose Y, then JOSE algorithm A to be used for purpose X but not purpose Y, then JOSE
should not recommend using algorithm A for purpose Y. should not recommend using algorithm A for purpose Y.
S3 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 WebCrypto specifications,
e.g., by coordinating with the WebCrypto working group to e.g., by coordinating with the WebCrypto 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 base64url encoding it) are
preferred over those that require converting an object to a 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
cryptographic operations can be controlled by the applications, as
opposed to involving processing specific to JOSE. This allows
JOSE the flexibility to address the needs of many cryptographic
protocols. For example, in some cases, might allow JOSE objects
to be translated to legacy formats such as CMS without the need
for re-encryption or re-signing.
7. IANA Considerations 7. IANA Considerations
This document makes no request of IANA. This document makes no request of IANA.
8. Security Considerations 8. 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].
skipping to change at page 19, line 24 skipping to change at page 20, line 36
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 9. References
9.1. Normative References 9.1. Normative References
[RFC4627] Crockford, D., "The application/json Media Type for [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) [RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
Authenticated-Enveloped-Data Content Type", RFC 5083, Authenticated-Enveloped-Data Content Type", RFC 5083,
November 2007. November 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 6749, October 2012. RFC 6749, October 2012.
[RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization [W3C.REC-xml]
Framework: Bearer Token Usage", RFC 6750, October 2012. Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-
[W3C.CR-xmldsig-core2-20120124] xml, October 2000, <http://www.w3.org/TR/REC-xml>.
Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
"XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium CR CR-xmlenc-core1-20120313,
March 2012,
<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
[W3C.REC-xml-1998]
Bray, T., Paoli, J., and C. Sperberg-McQueen, "Extensible
Markup Language (XML) 1.0", W3C REC-xml-1998,
February 1998,
<http://www.w3.org/TR/1998/REC-xml-19980210/>.
[WebCrypto] [WebCrypto]
Sleevi, R. and D. Dahl, "Web Cryptography API", Sleevi, R. and D. Dahl, "Web Cryptography API",
January 2013. January 2013.
9.2. Informative References 9.2. Informative References
[CAP] Botterell, A. and E. Jones, "Common Alerting Protocol [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol
v1.1", October 2005. v1.1", October 2005.
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-16 (work in progress), May 2013. draft-ietf-alto-protocol-17 (work in progress), July 2013.
[I-D.ietf-atoca-requirements] [I-D.ietf-atoca-requirements]
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", draft-ietf-atoca-requirements-03
(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] [I-D.ietf-jose-json-web-algorithms]
Jones, M., "JSON Web Algorithms (JWA)", Jones, M., "JSON Web Algorithms (JWA)",
draft-ietf-jose-json-web-algorithms-11 (work in progress), draft-ietf-jose-json-web-algorithms-12 (work in progress),
May 2013. July 2013.
[I-D.ietf-jose-json-web-encryption] [I-D.ietf-jose-json-web-encryption]
Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web
Encryption (JWE)", draft-ietf-jose-json-web-encryption-11 Encryption (JWE)", draft-ietf-jose-json-web-encryption-12
(work in progress), May 2013. (work in progress), July 2013.
[I-D.ietf-jose-json-web-key] [I-D.ietf-jose-json-web-key]
Jones, M., "JSON Web Key (JWK)", Jones, M., "JSON Web Key (JWK)",
draft-ietf-jose-json-web-key-11 (work in progress), draft-ietf-jose-json-web-key-12 (work in progress),
May 2013. July 2013.
[I-D.ietf-jose-json-web-signature] [I-D.ietf-jose-json-web-signature]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", draft-ietf-jose-json-web-signature-11 Signature (JWS)", draft-ietf-jose-json-web-signature-12
(work in progress), May 2013. (work in progress), July 2013.
[I-D.ietf-lwig-terminology]
Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained Node Networks", draft-ietf-lwig-terminology-05
(work in progress), July 2013.
[I-D.ietf-oauth-json-web-token] [I-D.ietf-oauth-json-web-token]
Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", draft-ietf-oauth-json-web-token-08 (work in (JWT)", draft-ietf-oauth-json-web-token-09 (work in
progress), May 2013. progress), July 2013.
[I-D.ietf-oauth-jwt-bearer] [I-D.ietf-oauth-jwt-bearer]
Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token
(JWT) Profile for OAuth 2.0 Client Authentication and (JWT) Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-jwt-bearer-05 Authorization Grants", draft-ietf-oauth-jwt-bearer-05
(work in progress), March 2013. (work in progress), March 2013.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0 Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profile for OAuth 2.0 Client Authentication and Profile for OAuth 2.0 Client Authentication and
Authorization Grants", draft-ietf-oauth-saml2-bearer-16 Authorization Grants", draft-ietf-oauth-saml2-bearer-16
(work in progress), March 2013. (work in progress), March 2013.
[I-D.miller-xmpp-e2e] [I-D.miller-xmpp-e2e]
Miller, M., "End-to-End Object Encryption for the Miller, M., "End-to-End Object Encryption and Signatures
Extensible Messaging and Presence Protocol (XMPP)", for the Extensible Messaging and Presence Protocol
draft-miller-xmpp-e2e-05 (work in progress), (XMPP)", draft-miller-xmpp-e2e-06 (work in progress),
February 2013. June 2013.
[ITU.X690.1994] [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, 1994. X.690, 2002.
[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., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005. 2.0-os, March 2005.
[OpenID.Messages] [OpenID.Messages]
Sakimura, N., Bradley, J., Jones, M., de Medeiros, B., Sakimura, N., Bradley, J., Jones, M., de Medeiros, B.,
Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0", Mortimore, C., and E. Jay, "OpenID Connect Messages 1.0",
skipping to change at page 22, line 26 skipping to change at page 23, line 30
[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.
[RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption
for the Extensible Messaging and Presence Protocol for the Extensible Messaging and Presence Protocol
(XMPP)", RFC 3923, October 2004. (XMPP)", RFC 3923, October 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[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
Framework: Bearer Token Usage", RFC 6750, October 2012.
[W3C.xmldsig-core]
Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
Syntax and Processing", W3C Recommendation xmldsig-core,
October 2000, <http://www.w3.org/TR/xmldsig-core/>.
[W3C.xmlenc-core]
Eastlake, D. and J. Reagle , "XML Encryption Syntax and
Processing", W3C Candidate Recommendation xmlenc-core,
August 2002, <http://www.w3.org/TR/xmlenc-core/>.
[WS-Federation] [WS-Federation]
Kaler, C., McIntosh, M., Goodner, M., and A. Nadalin, "Web Kaler, C., McIntosh, M., Goodner, 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/ May 2009, <http://docs.oasis-open.org/wsfed/federation/
v1.2/os/ws-federation-1.2-spec-os.html>. v1.2/os/ws-federation-1.2-spec-os.html>.
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 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. them. Thanks to Ludwig Seitz for contributing the constrained device
use case.
Appendix B. Document History Appendix B. Document History
[[ to be removed by the RFC editor before publication as an RFC ]] [[ to be removed by the RFC editor before publication as an RFC ]]
-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 -02
o Referenced the JWS, JWE, JWK, and JWA specifications making the o Referenced the JWS, JWE, JWK, and JWA specifications making the
"signed object format", "encrypted object format", "key format", "signed object format", "encrypted object format", "key format",
and algorithms resulting from these use cases concrete. and algorithms resulting from these use cases concrete.
o Added "Requirements on Application Protocols" section. o Added "Requirements on Application Protocols" section.
o Broke former huge "Security Tokens and Authorization" Use Case o Broke former huge "Security Tokens and Authorization" Use Case
section into "Security Tokens", "OAuth", and "Federation" Use Case section into "Security Tokens", "OAuth", and "Federation" Use Case
 End of changes. 56 change blocks. 
140 lines changed or deleted 237 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/