draft-ietf-jose-use-cases-00.txt   draft-ietf-jose-use-cases-01.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational March 2013 Intended status: Informational May 26, 2013
Expires: August 29, 2013 Expires: November 27, 2013
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-00.txt draft-ietf-jose-use-cases-01.txt
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 has
provided a binary secure object format based on ASN.1. Over time, provided a binary secure object format based on ASN.1. Over time,
the use of binary object encodings such as ASN.1 has been overtaken the use of binary object encodings such as ASN.1 has been overtaken
by text-based encodings, for example JavaScript Object Notation. by text-based encodings, for example JavaScript Object Notation.
This document defines a set of use cases and requirements for a This document defines a set of use cases and requirements for a
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 August 29, 2013. This Internet-Draft will expire on November 27, 2013.
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 21 skipping to change at page 2, line 21
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 5
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Security Tokens and Authorization . . . . . . . . . . . . 6 4.1. Security Tokens and Authorization . . . . . . . . . . . . 6
4.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 11 4.4. Emergency Alerting . . . . . . . . . . . . . . . . . . . . 11
4.5. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 13 4.5. Web Cryptography . . . . . . . . . . . . . . . . . . . . . 13
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Small Devices . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Functional Requirements . . . . . . . . . . . . . . . . . 14 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Security Requirements . . . . . . . . . . . . . . . . . . 15 5.1. Functional Requirements . . . . . . . . . . . . . . . . . 15
5.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Security Requirements . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5.3. Desiderata . . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
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, which create a secure channel at the IP layer or
transport layer over which application data can flow 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 11, line 10 skipping to change at page 11, line 10
indication must be given to the parser to indicate that it is not to indication must be given to the parser to indicate that it is not to
be parsed as XML. One way to meet this requirement would be to apply be parsed as XML. One way to meet this requirement would be to apply
base64url encoding, but for XMPP messages of medium-to-large size, base64url encoding, but for XMPP messages of medium-to-large size,
this could impose a fair degree of overhead. this could impose a fair degree of overhead.
4.3. ALTO 4.3. ALTO
Application-Layer Traffic Optimization (ALTO) is a system for Application-Layer Traffic Optimization (ALTO) is a system for
distributing network topology information to end devices, so that distributing network topology information to end devices, so that
those devices can modify their behavior to have a lower impact on the those devices can modify their behavior to have a lower impact on the
network [I-D.ietf-alto-reqs]. The ALTO protocol distributes topology network [RFC6708]. The ALTO protocol distributes topology
information in the form of JSON objects carried in HTTP information in the form of JSON objects carried in HTTP
[RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is [RFC2616][I-D.ietf-alto-protocol]. The basic version of ALTO is
simply a client-server protocol, so simple use of HTTPS suffices for simply a client-server protocol, so simple use of HTTPS suffices for
this case [RFC2818]. However, there is beginning to be some this case [RFC2818]. However, there is beginning to be some
discussion of use cases for ALTO in which these JSON objects will be discussion of use cases for ALTO in which these JSON objects will be
distributed through a collection of intermediate servers before distributed through a collection of intermediate servers before
reaching the client, while still preserving the ability of the client reaching the client, while still preserving the ability of the client
to authenticate the original source of the object. Even the base to authenticate the original source of the object. Even the base
ALTO protocol notes that "ALTO clients obtaining ALTO information ALTO protocol notes that "ALTO clients obtaining ALTO information
must be able to validate the received ALTO information to ensure that must be able to validate the received ALTO information to ensure that
skipping to change at page 14, line 12 skipping to change at page 14, line 12
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.
4.6. Small Devices
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 availability of both real
estate for 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
codes (MAC) is going to be sufficient to provide the necessary
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
adopted the following proposal for computing a shared secret that can
be validated:
o An Elliptic-Curve Diffie-Hellman (ECDH) key is generated for the
device at the time of manufacturing. (Or as part of the
configuration process during installation.)
o An ECDH public key for the controller is configured at the time of
configuration.
o The configuration system performs the exponentiation and
configures the device with the resulting shared secret. This
process eliminates the need for the device to be able to perform
the required exponentiation processing. The security requirements
on protecting this computed shared secret are the same as the
requirements on protecting the private ECDH key.
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
incremented and a new MAC key is computed from the ECDH secret and
the counter value. A custom Key Derivation Function (KDF)
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
value for the message.
In a similar manner the KDF function can used to compute an AEAD
algorithm key when the system needs to provide confidentially for the
message. The controller, being a larger device will perform the
exponentiation step and use a random number generator to generate the
sender nonce value.
5. Requirements 5. 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
requrirements, but which are still desireable properties for the JOSE requrirements, but which are still desireable properties for the JOSE
system to have. system to have.
5.1. Functional Requirements 5.1. Functional Requirements
skipping to change at page 16, line 36 skipping to change at page 17, line 36
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
[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-13 (work in progress), draft-ietf-alto-protocol-16 (work in progress), May 2013.
September 2012.
[I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-16 (work in progress),
June 2012.
[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-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-06 (work in (JWT)", draft-ietf-oauth-json-web-token-07 (work in
progress), December 2012. progress), April 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 for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
draft-miller-xmpp-e2e-04 (work in progress), draft-miller-xmpp-e2e-05 (work in progress),
February 2013. February 2013.
[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 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. 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.
skipping to change at page 17, line 37 skipping to change at page 18, line 30
[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
Y. Yang, "Application-Layer Traffic Optimization (ALTO)
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.
[W3C.CR-xmldsig-core2-20120124] [W3C.CR-xmldsig-core2-20120124]
Datta, P., Hirsch, F., Eastlake, D., Cantor, S., Roessler, Eastlake, D., Reagle, J., Yiu, K., Solo, D., Datta, P.,
T., Reagle, J., Yiu, K., and D. Solo, "XML Signature Hirsch, F., Cantor, S., and T. Roessler, "XML Signature
Syntax and Processing Version 2.0", World Wide Web Syntax and Processing Version 2.0", World Wide Web
Consortium CR CR-xmldsig-core2-20120124, January 2012, Consortium CR CR-xmldsig-core2-20120124, January 2012,
<http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>. <http://www.w3.org/TR/2012/CR-xmldsig-core2-20120124>.
[W3C.CR-xmlenc-core1-20120313] [W3C.CR-xmlenc-core1-20120313]
Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch, Eastlake, D., Reagle, J., Roessler, T., and F. Hirsch,
"XML Encryption Syntax and Processing Version 1.1", World "XML Encryption Syntax and Processing Version 1.1", World
Wide Web Consortium CR CR-xmlenc-core1-20120313, Wide Web Consortium CR CR-xmlenc-core1-20120313,
March 2012, March 2012,
<http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>. <http://www.w3.org/TR/2012/CR-xmlenc-core1-20120313>.
skipping to change at page 18, line 23 skipping to change at page 19, line 19
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-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) Bearer Token Profiles for OAuth 2.0", (JWT) Profile for OAuth 2.0 Client Authentication and
draft-ietf-oauth-jwt-bearer-04 (work in progress), Authorization Grants", draft-ietf-oauth-jwt-bearer-05
December 2012. (work in progress), March 2013.
[I-D.ietf-oauth-saml2-bearer] [I-D.ietf-oauth-saml2-bearer]
Campbell, B. and C. Mortimore, "SAML 2.0 Bearer Assertion Campbell, B., Mortimore, C., and M. Jones, "SAML 2.0
Profiles for OAuth 2.0", draft-ietf-oauth-saml2-bearer-15 Profile for OAuth 2.0 Client Authentication and
(work in progress), November 2012. Authorization Grants", draft-ietf-oauth-saml2-bearer-16
(work in progress), March 2013.
[ITU.X690.1994] [ITU.X690.1994]
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, 1994.
[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,
 End of changes. 13 change blocks. 
35 lines changed or deleted 79 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/