draft-ietf-jose-use-cases-03.txt   draft-ietf-jose-use-cases-04.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational July 14, 2013 Intended status: Informational August 15, 2013
Expires: January 15, 2014 Expires: February 16, 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-03 draft-ietf-jose-use-cases-04
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 January 15, 2014. This Internet-Draft will expire on February 16, 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 30 skipping to change at page 2, line 30
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. Constrained Devices . . . . . . . . . . . . . . . . . . . 15 5.8. Constrained Devices . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . . 19 6.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 20
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
skipping to change at page 7, line 5 skipping to change at page 7, line 5
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
5. Use Cases 5. Use Cases
Several working groups developing application-layer protocols have Several working groups developing application-layer protocols have
expressed a desire to use the JOSE data formats in their designs for expressed a desire to use the JOSE data formats in their designs for
end-to-end security features. In this section, we summarize the use end-to-end security features. In this section, we summarize the use
cases proposed by these groups and discuss the requirements that they cases proposed by these groups and discuss the requirements that they
imply for the JOSE object formats. imply for the JOSE object formats.
5.1. Security Tokens 5.1. Security Tokens
skipping to change at page 10, line 43 skipping to change at page 10, line 43
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 because of the difficulty of
processing S/MIME objects. 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-to-
end encryption system with an encoding based on JOSE and a clearer end encryption system with an encoding based on JOSE and a clearer
key management system [I-D.miller-xmpp-e2e]. The process of sending key management system [I-D.miller-xmpp-e2e]. The process of sending
an encrypted message in this system involves two steps: First, the an encrypted message in this system involves two steps: First, the
sender generates a symmetric Content Encryption Key (CEK), encrypts sender generates a symmetric Session Master Key (SMK), encrypts the
the message content, and sends the encrypted message to the desired message content (including a per-message Content Master Key), and
set of recipients. Second, each recipient "dials back" to the sends the encrypted message to the desired set of recipients.
sender, providing his public key; the sender then responds with the Second, each recipient "dials back" to the sender, providing his
relevant CEK, wrapped with the recipient's public key. public key. The sender then responds with the relevant SMK, wrapped
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 CEK------------->| |---------------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 cache public keys for the above mechanism, XMPP systems will likely re-use a given SMK for
end recipients, so that wrapped keys can be sent along with content multiple individual messages, refreshing the SMK on a periodic and/or
on future messages. This implies that the JOSE encrypted object event-driven basis (e.g., when the recipient's presence changes).
format must support the provision of multiple versions of the same They might also cache public keys for end recipients, so that wrapped
wrapped CEK (much as a CMS EnvelopedData structure can include keys can be sent along with content on future messages. This implies
multiple RecipientInfo structures). that the JOSE encrypted object format must support the provision of
multiple versions of the same wrapped SMK (much as a CMS
EnvelopedData structure can include multiple RecipientInfo
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 wrapped
key. So the authentication here requires not only that XMPP routing key. So the authentication here requires not only that XMPP routing
skipping to change at page 18, line 29 skipping to change at page 18, line 29
6. Requirements 6. Requirements
This section summarizes the requirements from the above uses cases, This section summarizes the requirements from the above uses cases,
and lists further requirements not directly derived from the above and lists further requirements not directly derived from the above
use cases. There are also some constraints that are not hard use cases. There are also some constraints that are not hard
requirements, but which are still desirable properties for the JOSE requirements, but which 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
security properties:
* Digital signature (integrity/authentication under an asymmetric
key pair)
* Message authentication (integrity/authentication under a
symmetric key)
* Authenticated encryption
F2 Define a format for public keys and private keys for asymmetric
cryptographic algorithms, with associated attributes, including a
wrapped form for private keys.
F3 Define a format for symmetric keys with associated attributes,
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 [RFC4627].
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. 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
skipping to change at page 21, line 41 skipping to change at page 22, line 12
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-12 (work in progress), draft-ietf-jose-json-web-algorithms-14 (work in progress),
July 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-12 Encryption (JWE)", draft-ietf-jose-json-web-encryption-14
(work in progress), July 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-12 (work in progress), draft-ietf-jose-json-web-key-14 (work in progress),
July 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-12 Signature (JWS)", draft-ietf-jose-json-web-signature-14
(work in progress), July 2013. (work in progress), July 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-09 (work in (JWT)", draft-ietf-oauth-json-web-token-11 (work in
progress), July 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-06
(work in progress), March 2013. (work in progress), July 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-17
(work in progress), March 2013. (work in progress), July 2013.
[I-D.miller-xmpp-e2e] [I-D.miller-xmpp-e2e]
Miller, M., "End-to-End Object Encryption and Signatures Miller, M., "End-to-End Object Encryption and Signatures
for the Extensible Messaging and Presence Protocol for the Extensible Messaging and Presence Protocol
(XMPP)", draft-miller-xmpp-e2e-06 (work in progress), (XMPP)", draft-miller-xmpp-e2e-06 (work in progress),
June 2013. 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
 End of changes. 17 change blocks. 
28 lines changed or deleted 52 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/