Internet DRAFT - draft-jennings-perpass-secure-rai-cloud
draft-jennings-perpass-secure-rai-cloud
Network Working Group C. Jennings
Internet-Draft S. Nandakumar
Intended status: Informational January 15, 2014
Expires: July 19, 2014
Trustable Cloud Systems - Strategies and Recommendations
draft-jennings-perpass-secure-rai-cloud-01
Abstract
The Internet technical community is looking at ways to address
pervasive attacks as described in several other internet drafts.
[I-D.barnes-pervasive-problem] describes threat model to characterize
various pervasive attacks on the Internet communications. There are
many systems that need to be secured against such attacks but this
paper considers one possible way to secure cloud based collaborations
systems. At a high level, this paper sugests that users or
enterprises could run a key server that manages the keys to access
their content. The cloud service provider would not have access to
decrypt the data stored in the cloud but various users of the cloud
service could get the keys to encrypt and decrypt the contents of
collaboration sessions facilitated by the cloud service. This does
not protect the meta data of who is talking to who but can help
protect the content of the conversations.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 19, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jennings & Nandakumar Expires July 19, 2014 [Page 1]
Internet-Draft Trustable Cloud January 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Jennings & Nandakumar Expires July 19, 2014 [Page 2]
Internet-Draft Trustable Cloud January 2014
1. Introduction
The problem with today's cloud services is that a whole bunch of data
is kept by the cloud service providers and that provides a target for
attackers to collect and analyze the data. The strategy laid out in
this document is to minimize the amount of data exposed to service
providers by combining encryption and anonymization techniques. A
user trusted Identity Provider (IdP) facilitates user key access and
key management between devices. Such a solution must meet the
following criteria to be usable at a larger scale.
o Housley Criteria: Be able to detect if your communications have
been compromised
o Support voice, video, instant message, stored messages, file
sharing and more
Jennings & Nandakumar Expires July 19, 2014 [Page 3]
Internet-Draft Trustable Cloud January 2014
2. Trustable Cloud Services
The basic approach can be described as the following:
o Cloud Service sees only the encrypted data and envelope
information.
o All users have public/private key.
o The user's Identity Provider manages the user's private keys and
provides public keys to others.
o Identity providers authenticate to others using Certificate from
the Certificate Authority.
o Content is encrypted by clients and the information to decrypt it
is encrypted with the public keys of all the users authorized to
view it.
Jennings & Nandakumar Expires July 19, 2014 [Page 4]
Internet-Draft Trustable Cloud January 2014
3. Data Protection
The approach to stop the attacker from obtaining user data from
service provider are:
o Each piece of content belongs to a group. Each group has one
content owner.
o Data touched by the cloud is encrypted.
o The content encryptions keys are encrypted using the public keys
of all users authorized to read this content.
o If others user can modify this data, the signature key for this
content is encrypted with the public key of all users authorized
to write this content.
o The content is encrypted and signed and bundled with all the
relevant meta data.
o List of authorized users to read/write a piece of given content is
managed by identity server for the content owner.
The goal is to encrypt as much as of the information as possible and
then try to anonymizing un-encrypted data as much as possible.
o Encryption: TLS Everywhere
o Anonymization: Overlay routing (eg. TOR, P2P with RELOAD)
Jennings & Nandakumar Expires July 19, 2014 [Page 5]
Internet-Draft Trustable Cloud January 2014
4. Trust - Roles of IdP and CA
This section outlines the guiding principles that define the roles of
Identity Providers and Certificate Authorities in establishing end to
end trust relationship and key management issues.
Its very hard to design systems where you do not trust your Identity
Provider (IdP). The approach here is to separate the Identity
Provider from the cloud provider and allow the Identity Provider to
be run by someone you can trust. For example, an enterprise may run
it's own IdP for it's employees.
o One has to trust their Identity Provider.
o Each user's device authenticates to IdP to get that users' private
key.
o IdP provides public keys to others.
o IdP authenticates by having certificate for domain it serves.
o IdP for a user is discovered using domain name of the user
identity.
o Each device talks to IdP to find out list of public keys for any
groups that users owns.
o IdP provides API to manage group membership.
The security of the IdP discovery relies on having Certificate
Authority (CA) that we can trust. The CA
o Provides TLS style certificates.
o Provides an audit log enabling list of certificates generated by a
CA.
o If the CA creates bad certificates, which it can, the security of
the whole system can be compromised but the goal is to be able to
detect this.
Things do go wrong, devices get lost, and any practical system need
to be able to deal with this. The approach for Key Revocation is:
o Relies on the Identity Providers and Cloud Service cooperating to
get rid of the old key
Jennings & Nandakumar Expires July 19, 2014 [Page 6]
Internet-Draft Trustable Cloud January 2014
o If a private key for a user is compromised, it is replaced with a
new key by the IdP and the Cloud Service is informed to deprecate
old key
o For any content that the old compromised private key could access,
the Cloud Service asks the Identity Provider that owns that
content to provide new meta data for that content with the new
private key.
There is also the ability to check Key Continuity as follows:
o Any times a client detects a key has changed for a user, it can
inform the user, Identity Provider, and Cloud Service to try and
detect compromises
o Any time the Certificate changes for an Identity Provider or Cloud
Service the Client can inform the user and the Identity provider.
Jennings & Nandakumar Expires July 19, 2014 [Page 7]
Internet-Draft Trustable Cloud January 2014
5. Content Freshness
A common problem for encrypted cloud system is around how to find
current content.
o Any time that the Cloud Service gets new content, it provides that
content to all the Identity providers for users that can read that
content along with an URL to be associated with the content.
o Each Identity Provider can index that content for future search as
it has the private keys to decode it.
o Clients can perform a search using their Identity Provider based
on the URI matching to retrieve set of Cloud Service URIs that
matches the search.
Jennings & Nandakumar Expires July 19, 2014 [Page 8]
Internet-Draft Trustable Cloud January 2014
6. Summary
Thus the proposed recommendation can be considered as guidelines to
build a more elaborate architecture for building cloud services that
are trustable based on the ideas of
o End to End Encryption Techniques based on Strong Cryptographic
Algorithms
o Anonymization of metadata and un-encrypted data
o IdP and CA based Trust Certificate chain establishment
6.1. Possible Standardization
Following are some of the areas where more work needs to be done as
far as standardization is concerned:
o Verification of all CA certifications issued
o IdP Discovery
o IdP Authentication of Client
o IdP API for management of IdP
o IdP API for public/private keys
o IdP API for search
o KeyRevocation API
o Key Continuity API
o Formats for encrypted objects and metadata
o Crypto Recommendations
Jennings & Nandakumar Expires July 19, 2014 [Page 9]
Internet-Draft Trustable Cloud January 2014
7. Acknowledgements
o Design motivated by SiRiUS (Goh, Shacham, Modadugu & Boneh)
o Thanks to Eric Rescorla, Richard Barnes
Jennings & Nandakumar Expires July 19, 2014 [Page 10]
Internet-Draft Trustable Cloud January 2014
8. Informative References
[I-D.barnes-pervasive-problem]
Barnes, R., Schneier, B., Jennings, C., and T. Hardie,
"Pervasive Attack: A Threat Model and Problem Statement",
draft-barnes-pervasive-problem-00 (work in progress),
January 2014.
Jennings & Nandakumar Expires July 19, 2014 [Page 11]
Internet-Draft Trustable Cloud January 2014
Authors' Addresses
Cullen Jennings
Email: fluffy@cisco.com
Suhas Nandakumar
Email: snandaku@cisco.com
Jennings & Nandakumar Expires July 19, 2014 [Page 12]
