idnits 2.17.1 draft-jennings-perpass-secure-rai-cloud-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.barnes-pervasive-problem]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2014) is 3754 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-barnes-pervasive-problem-00 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Jennings 3 Internet-Draft S. Nandakumar 4 Intended status: Informational January 15, 2014 5 Expires: July 19, 2014 7 Trustable Cloud Systems - Strategies and Recommendations 8 draft-jennings-perpass-secure-rai-cloud-01 10 Abstract 12 The Internet technical community is looking at ways to address 13 pervasive attacks as described in several other internet drafts. 14 [I-D.barnes-pervasive-problem] describes threat model to characterize 15 various pervasive attacks on the Internet communications. There are 16 many systems that need to be secured against such attacks but this 17 paper considers one possible way to secure cloud based collaborations 18 systems. At a high level, this paper sugests that users or 19 enterprises could run a key server that manages the keys to access 20 their content. The cloud service provider would not have access to 21 decrypt the data stored in the cloud but various users of the cloud 22 service could get the keys to encrypt and decrypt the contents of 23 collaboration sessions facilitated by the cloud service. This does 24 not protect the meta data of who is talking to who but can help 25 protect the content of the conversations. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on July 19, 2014. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 1. Introduction 61 The problem with today's cloud services is that a whole bunch of data 62 is kept by the cloud service providers and that provides a target for 63 attackers to collect and analyze the data. The strategy laid out in 64 this document is to minimize the amount of data exposed to service 65 providers by combining encryption and anonymization techniques. A 66 user trusted Identity Provider (IdP) facilitates user key access and 67 key management between devices. Such a solution must meet the 68 following criteria to be usable at a larger scale. 70 o Housley Criteria: Be able to detect if your communications have 71 been compromised 73 o Support voice, video, instant message, stored messages, file 74 sharing and more 76 2. Trustable Cloud Services 78 The basic approach can be described as the following: 80 o Cloud Service sees only the encrypted data and envelope 81 information. 83 o All users have public/private key. 85 o The user's Identity Provider manages the user's private keys and 86 provides public keys to others. 88 o Identity providers authenticate to others using Certificate from 89 the Certificate Authority. 91 o Content is encrypted by clients and the information to decrypt it 92 is encrypted with the public keys of all the users authorized to 93 view it. 95 3. Data Protection 97 The approach to stop the attacker from obtaining user data from 98 service provider are: 100 o Each piece of content belongs to a group. Each group has one 101 content owner. 103 o Data touched by the cloud is encrypted. 105 o The content encryptions keys are encrypted using the public keys 106 of all users authorized to read this content. 108 o If others user can modify this data, the signature key for this 109 content is encrypted with the public key of all users authorized 110 to write this content. 112 o The content is encrypted and signed and bundled with all the 113 relevant meta data. 115 o List of authorized users to read/write a piece of given content is 116 managed by identity server for the content owner. 118 The goal is to encrypt as much as of the information as possible and 119 then try to anonymizing un-encrypted data as much as possible. 121 o Encryption: TLS Everywhere 123 o Anonymization: Overlay routing (eg. TOR, P2P with RELOAD) 125 4. Trust - Roles of IdP and CA 127 This section outlines the guiding principles that define the roles of 128 Identity Providers and Certificate Authorities in establishing end to 129 end trust relationship and key management issues. 131 Its very hard to design systems where you do not trust your Identity 132 Provider (IdP). The approach here is to separate the Identity 133 Provider from the cloud provider and allow the Identity Provider to 134 be run by someone you can trust. For example, an enterprise may run 135 it's own IdP for it's employees. 137 o One has to trust their Identity Provider. 139 o Each user's device authenticates to IdP to get that users' private 140 key. 142 o IdP provides public keys to others. 144 o IdP authenticates by having certificate for domain it serves. 146 o IdP for a user is discovered using domain name of the user 147 identity. 149 o Each device talks to IdP to find out list of public keys for any 150 groups that users owns. 152 o IdP provides API to manage group membership. 154 The security of the IdP discovery relies on having Certificate 155 Authority (CA) that we can trust. The CA 157 o Provides TLS style certificates. 159 o Provides an audit log enabling list of certificates generated by a 160 CA. 162 o If the CA creates bad certificates, which it can, the security of 163 the whole system can be compromised but the goal is to be able to 164 detect this. 166 Things do go wrong, devices get lost, and any practical system need 167 to be able to deal with this. The approach for Key Revocation is: 169 o Relies on the Identity Providers and Cloud Service cooperating to 170 get rid of the old key 172 o If a private key for a user is compromised, it is replaced with a 173 new key by the IdP and the Cloud Service is informed to deprecate 174 old key 176 o For any content that the old compromised private key could access, 177 the Cloud Service asks the Identity Provider that owns that 178 content to provide new meta data for that content with the new 179 private key. 181 There is also the ability to check Key Continuity as follows: 183 o Any times a client detects a key has changed for a user, it can 184 inform the user, Identity Provider, and Cloud Service to try and 185 detect compromises 187 o Any time the Certificate changes for an Identity Provider or Cloud 188 Service the Client can inform the user and the Identity provider. 190 5. Content Freshness 192 A common problem for encrypted cloud system is around how to find 193 current content. 195 o Any time that the Cloud Service gets new content, it provides that 196 content to all the Identity providers for users that can read that 197 content along with an URL to be associated with the content. 199 o Each Identity Provider can index that content for future search as 200 it has the private keys to decode it. 202 o Clients can perform a search using their Identity Provider based 203 on the URI matching to retrieve set of Cloud Service URIs that 204 matches the search. 206 6. Summary 208 Thus the proposed recommendation can be considered as guidelines to 209 build a more elaborate architecture for building cloud services that 210 are trustable based on the ideas of 212 o End to End Encryption Techniques based on Strong Cryptographic 213 Algorithms 215 o Anonymization of metadata and un-encrypted data 217 o IdP and CA based Trust Certificate chain establishment 219 6.1. Possible Standardization 221 Following are some of the areas where more work needs to be done as 222 far as standardization is concerned: 224 o Verification of all CA certifications issued 226 o IdP Discovery 228 o IdP Authentication of Client 230 o IdP API for management of IdP 232 o IdP API for public/private keys 234 o IdP API for search 236 o KeyRevocation API 238 o Key Continuity API 240 o Formats for encrypted objects and metadata 242 o Crypto Recommendations 244 7. Acknowledgements 246 o Design motivated by SiRiUS (Goh, Shacham, Modadugu & Boneh) 248 o Thanks to Eric Rescorla, Richard Barnes 250 8. Informative References 252 [I-D.barnes-pervasive-problem] 253 Barnes, R., Schneier, B., Jennings, C., and T. Hardie, 254 "Pervasive Attack: A Threat Model and Problem Statement", 255 draft-barnes-pervasive-problem-00 (work in progress), 256 January 2014. 258 Authors' Addresses 260 Cullen Jennings 262 Email: fluffy@cisco.com 264 Suhas Nandakumar 266 Email: snandaku@cisco.com