draft-ietf-jose-use-cases-05.txt   draft-ietf-jose-use-cases-06.txt 
JOSE R. Barnes JOSE R. Barnes
Internet-Draft BBN Technologies Internet-Draft BBN Technologies
Intended status: Informational September 5, 2013 Intended status: Informational December 27, 2013
Expires: March 9, 2014 Expires: June 30, 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-05 draft-ietf-jose-use-cases-06
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. For many years, the Cryptographic Message Syntax
has provided a binary secure object format based on ASN.1. Over (CMS) has provided a binary secure object format based on ASN.1.
time, the use of binary object encodings such as ASN.1 has been Over time, binary object encodings such as ASN.1 have become less
overtaken by text-based encodings, for example JavaScript Object common than 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
for a secure object format encoded using JavaScript Object Notation for a secure object format encoded using JavaScript Object Notation
(JSON), drawn from a variety of application security mechanisms (JSON), drawn from a variety of application security mechanisms
currently in 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 March 9, 2014. This Internet-Draft will expire on June 30, 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 3, line 35 skipping to change at page 3, line 35
apply channel-based security protections to their interactions (e.g., apply channel-based security protections to their interactions (e.g.,
STARTTLS [RFC3207]), these protections do not prevent the MTAs from STARTTLS [RFC3207]), these protections do not prevent the MTAs from
interfering with the message. In order to provide end-to-end interfering with the message. In order to provide end-to-end
security protections in the presence of untrusted MTAs, mail users security protections in the presence of untrusted MTAs, mail users
can use S/MIME to embed message bodies in a secure object format that can use S/MIME to embed message bodies in a secure object format that
can provide confidentiality, integrity, and data origin can provide confidentiality, integrity, and data origin
authentication. authentication.
S/MIME is based on the Cryptographic Message Syntax for secure S/MIME is based on the Cryptographic Message Syntax 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 typically 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.2002]. 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) [W3C.REC-xml] or the JavaScript Object Notation (JSON) (XML) [W3C.REC-xml] or the JavaScript Object Notation (JSON)
[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;
skipping to change at page 4, line 17 skipping to change at page 4, line 17
applications and the resulting requirements for security mechanisms applications and the resulting requirements for security mechanisms
and object encodings. and object encodings.
Some systems that use XML have specified the use of XML-based Some systems that use XML have specified the use of XML-based
security mechanisms for object security, namely XML Digital security mechanisms for object security, namely XML Digital
Signatures and XML Encryption [W3C.xmldsig-core][W3C.xmlenc-core]. Signatures and XML Encryption [W3C.xmldsig-core][W3C.xmlenc-core].
These mechanisms are defined for use with several security token These mechanisms are defined for use with several security token
systems (e.g., SAML [OASIS.saml-core-2.0-os] and WS-Federation systems (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 (e.g., due to the need for XML
motivation to handle ASN.1 aren't likely to use XML security either. canonicalization), so developers that lack the tools or motivation to
This situation motivates the creation of a JSON-based secure object handle ASN.1 aren't likely to use XML security either. This
format that is simple enough to implement and deploy that it can be situation motivates the creation of a JSON-based secure object format
easily adopted by developers with minimal effort and tools. that is simple enough to implement and deploy that it can be easily
adopted by developers with minimal effort and tools.
2. Definitions 2. Definitions
This document makes extensive use of standard security terminology This document makes extensive use of standard security terminology
[RFC4949]. In addition, because the use cases for JOSE and CMS are [RFC4949]. In addition, because the use cases for JOSE and CMS are
similar, we will sometimes make analogies to some CMS concepts similar, we will sometimes make analogies to some CMS concepts
[RFC5652]. [RFC5652].
The JOSE working group charter calls for the group to define three The JOSE working group charter calls for the group to define three
basic JSON object formats: basic JSON object formats:
1. Confidentiality-protected object format 1. Confidentiality-protected object format
2. Integrity-protected object format 2. Integrity-protected object format
3. A format for expressing keys 3. A format for expressing keys
In this document, we will refer to these as the "signed object In this document, we will refer to these as the "encrypted object
format", the "encrypted object format", and the "key format", format", the "signed 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 (JWA) 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
skipping to change at page 5, line 20 skipping to change at page 5, line 22
entity that creates the object (e.g., encrypting or signing a entity that creates the object (e.g., encrypting or signing a
payload), and an entity that uses the object (decrypting, verifying). payload), and an entity that uses the object (decrypting, verifying).
We will refer to these roles as "sender" and "recipient", We will refer to these roles as "sender" and "recipient",
respectively. Note that while some requirements and use cases may respectively. Note that while some requirements and use cases may
refer to these as single entities, each object may have multiple refer to these as single entities, each object may have multiple
entities in each role. For example, a message may be signed by entities in each role. For example, a message may be signed by
multiple senders, or decrypted by multiple recipients. multiple senders, or decrypted by multiple recipients.
3. Basic Requirements 3. Basic Requirements
Obviously, for the encrypted and signed object formats, the necessary For the encrypted and signed object formats, the necessary
protections will be created using appropriate cryptographic protections will be created using appropriate cryptographic
mechanisms: symmetric or asymmetric encryption for confidentiality mechanisms: symmetric or asymmetric encryption for confidentiality
and MACs or digital signatures for integrity protection. In both and MACs or digital signatures for integrity protection. In both
cases, it is necessary for the JOSE format to support both symmetric cases, it is necessary for the JOSE format to support both symmetric
and asymmetric operations. and asymmetric operations.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
the case where the sender and receiver share a symmetric key. the case where the sender and receiver share a symmetric key.
o The JOSE encrypted object format must support object encryption in o The JOSE encrypted object format must support object encryption in
skipping to change at page 7, line 9 skipping to change at page 7, line 9
o How application protocol entities establish keys o How application protocol entities establish keys
o Whether keys are to be explicitly indicated in JOSE objects, or o Whether keys are to be explicitly indicated in JOSE objects, or
associated by application context associated by application context
o What serializations of JOSE objects are to be used o What serializations of JOSE objects are to be used
5. Use Cases 5. Use Cases
Several working groups developing application-layer protocols have Several IETF working groups developing application-layer protocols
expressed a desire to use the JOSE data formats in their designs for have expressed a desire to use the JOSE data formats in their designs
end-to-end security features. In this section, we summarize the use for end-to-end security features. In this section, we summarize the
cases proposed by these groups and discuss the requirements that they use cases proposed by these groups and discuss the requirements that
imply for the JOSE object formats. they imply for the JOSE object formats.
5.1. Security Tokens 5.1. Security Tokens
Security tokens are a common use case for object-based security, for Security tokens are a common use case for object-based security, for
example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens example, SAML assertions [OASIS.saml-core-2.0-os]. Security tokens
are used to convey information about a subject entity ("claims" or are used to convey information about a subject entity ("claims" or
"assertions") from an issuer to a recipient. The security features "assertions") from an issuer to a recipient. The security features
of a token format enable the recipient to verify that the claims came of a token format enable the recipient to verify that the claims came
from the issuer and, if the object is confidentiality-protected, that from the issuer and, if the object is confidentiality-protected, that
they were not visible to other parties. they were not visible to other parties.
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 In the OpenID Connect context, and in some other applications of JWT,
JWT, it is possible for the recipient of a JWT token to accept it it is possible for the recipient of a JWT to accept it without
without integrity protection in the JWT itself. In such cases, the integrity protection in the JWT itself. In such cases, the recipient
recipient chooses to rely on transport security rather than object chooses to rely on transport security rather than object security.
security. For example, if the payload is delivered over a TLS- For example, if the payload is delivered over a TLS-protected
protected channel, the recipient may regard the protections provided channel, the recipient may regard the protections provided by TLS as
by TLS as sufficient, so JOSE protection would not be required. sufficient, so JOSE protection would not be required.
However, even in this case, it is desirable to associate some However, even in this case, it is desirable to associate some
metadata with the JWT payload (claim set), such as the content type, metadata with the JWT payload (claim set), such as the content type,
or other application-specific metadata. In a signed or encrypted or other application-specific metadata. In a signed or encrypted
object, these metadata values could be carried in a header with other object, these metadata values could be carried in a header with other
metadata required for signing or encryption. It would thus simplify metadata required for signing or encryption. It would thus simplify
the design of OpenID Connect and similar applications if there could the design of OpenID Connect and similar applications if there could
be a JOSE object format that does not apply cryptographic protections 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 to its payload, but allows a header to be attached to the payload in
the same way as a signed or encrypted object. the same way as a signed or encrypted object.
skipping to change at page 17, line 8 skipping to change at page 17, line 8
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
the counter value. A custom Key Derivation Function (KDF) the counter value. A custom Key Derivation Function (KDF)
function is used when is based on the AES-CBC is used to derive function based on the AES-CBC is used to derive the required MAC
the required MAC key. The MAC key is then used to compute the MAC key. The MAC key is then used to compute the MAC value for the
value for the message. message.
In a similar manner the KDF function can used to compute an AEAD In a similar manner the KDF function can 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.
5.8.2. Object security for CoAP 5.8.2. Object security for CoAP
This use case deals with constrained devices of class C0/C1 (see This use case deals with constrained devices of class C0/C1 (see
skipping to change at page 20, line 11 skipping to change at page 20, line 11
* Password-based encryption (wrapping under a key derived from a * Password-based encryption (wrapping under a key derived from a
password) password)
S2 Where long-lived symmetric keys are used directly for S2 Where long-lived symmetric keys are used directly for
cryptographic operations (i.e., where requirement S1 is not met), cryptographic operations (i.e., where requirement S1 is not met),
provide deployment guidance on key management practices, such as provide deployment guidance on key management practices, such as
the need to limit key lifetimes. the need to limit key lifetimes.
S3 Use cryptographic algorithms in a manner compatible with major S3 Use cryptographic algorithms in a manner compatible with major
validation processes. For example, if a FIPS standard allows validation processes. For example, if typical validation
algorithm A to be used for purpose X but not purpose Y, then JOSE standards allow algorithm A to be used for purpose X but not
should not recommend using algorithm A for purpose Y. purpose Y, then JOSE should not recommend using algorithm A for
purpose Y.
S4 Support operation with or without pre-negotiation. It must be S4 Support operation with or without pre-negotiation. It must be
possible to create or process secure objects without any possible to create or process secure objects without any
configuration beyond key provisioning. If it is possible for keys configuration beyond key provisioning. If it is possible for keys
to be derived from application context, it must be possible for a to be derived from application context, it must be possible for a
recipient to recognize when it does not have the appropriate key. recipient to recognize when it does not have the appropriate key.
6.3. Desiderata 6.3. Desiderata
D1 Maximize compatibility with the W3C WebCrypto specifications, D1 Maximize compatibility with the W3C WebCrypto specifications,
skipping to change at page 21, line 50 skipping to change at page 21, line 50
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-17 (work in progress), July 2013. draft-ietf-alto-protocol-21 (work in progress),
November 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] [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-15 (work in progress), draft-ietf-jose-json-web-algorithms-18 (work in progress),
September 2013. November 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-15 Encryption (JWE)", draft-ietf-jose-json-web-encryption-18
(work in progress), September 2013. (work in progress), November 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-15 (work in progress), draft-ietf-jose-json-web-key-18 (work in progress),
September 2013. November 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-15 Signature (JWS)", draft-ietf-jose-json-web-signature-18
(work in progress), September 2013. (work in progress), November 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-13 (work in
progress), July 2013. progress), November 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-06 Authorization Grants", draft-ietf-oauth-jwt-bearer-06
(work in progress), July 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
 End of changes. 18 change blocks. 
46 lines changed or deleted 49 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/