draft-ietf-jose-use-cases-04.txt   draft-ietf-jose-use-cases-05.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational August 15, 2013 Intended status: Informational September 5, 2013
Expires: February 16, 2014 Expires: March 9, 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-04 draft-ietf-jose-use-cases-05
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 (CMS) transport layer. In the past, the Cryptographic Message Syntax (CMS)
has provided a binary secure object format based on ASN.1. Over has provided a binary secure object format based on ASN.1. Over
time, the use of binary object encodings such as ASN.1 has been time, the use of binary object encodings such as ASN.1 has been
overtaken by text-based encodings, for example JavaScript Object overtaken by text-based encodings, for example JavaScript Object
Notation. This document defines a set of use cases and requirements Notation. This document defines a set of use cases and requirements
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 February 16, 2014. This Internet-Draft will expire on March 9, 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 23 skipping to change at page 2, line 23
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. 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 . . . . . . . . . . . . . . . . . . . . . 15
5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 15 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix B. Document History . . . . . . . . . . . . . . . . . . 24 Appendix B. Document History . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 25 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 TLS, which create a secure channel at
the IP layer or 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
skipping to change at page 10, line 13 skipping to change at page 10, line 13
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.
o The Mozilla Persona [Persona] system is a simple single-sign-on o The Mozilla Persona [Persona] system is a simple single-sign-on
(SSO) protocol that uses JWTs that are signed JOSE JWS objects to (SSO) protocol that uses JWTs that are signed JOSE JWS objects to
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.
In the OpenID Connect context, and in some other applicaitions of
JWT, it is possible for the recipient of a JWT token to accept it
without integrity protection in the JWT itself. In such cases, the
recipient chooses to rely on transport security rather than object
security. For example, if the payload is delivered over a TLS-
protected channel, the recipient may regard the protections provided
by TLS as sufficient, so JOSE protection would not be required.
However, even in this case, it is desirable to associate some
metadata with the JWT payload (claim set), such as the content type,
or other application-specific metadata. In a signed or encrypted
object, these metadata values could be carried in a header with other
metadata required for signing or encryption. It would thus simplify
the design of OpenID Connect and similar applications if there could
be a JOSE object format that does not apply cryptographic protections
to its payload, but allows a header to be attached to the payload in
the same way as a 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), 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.
skipping to change at page 20, line 41 skipping to change at page 21, line 4
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].
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 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.
[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)
Authenticated-Enveloped-Data Content Type", RFC 5083,
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.
skipping to change at page 22, line 12 skipping to change at page 22, line 18
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] [I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18 Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013. (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-14 (work in progress), draft-ietf-jose-json-web-algorithms-15 (work in progress),
July 2013. September 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-14 Encryption (JWE)", draft-ietf-jose-json-web-encryption-15
(work in progress), July 2013. (work in progress), September 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-14 (work in progress), draft-ietf-jose-json-web-key-15 (work in progress),
July 2013. September 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-14 Signature (JWS)", draft-ietf-jose-json-web-signature-15
(work in progress), July 2013. (work in progress), September 2013.
[I-D.ietf-lwig-terminology] [I-D.ietf-lwig-terminology]
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", draft-ietf-lwig-terminology-05
(work in progress), July 2013. (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-11 (work in (JWT)", draft-ietf-oauth-json-web-token-11 (work in
progress), July 2013. progress), July 2013.
skipping to change at page 24, line 44 skipping to change at page 24, line 50
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 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 ]]
-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 -03
o Replaced the "small device" case with the "constrained device" o Replaced the "small device" case with the "constrained device"
case case
o Added S2 to cover cases where the WG decides not to implement S1 o Added S2 to cover cases where the WG decides not to implement S1
o Addressed multiple other WGLC comments 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.
 End of changes. 15 change blocks. 
19 lines changed or deleted 50 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/