idnits 2.17.1 draft-hoff-cloudaudit-00.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 : ---------------------------------------------------------------------------- ** There are 23 instances of too long lines in the document, the longest one being 249 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: A domain name (e.g. example.com) under the control of the party is broken into its components (e.g. example, com), reversed (e.g. com, example) and recombined (e.g. com.example). That party "owns" this namespace so long as the domain is registered to them and they may subdivide it with components in order to reference and/or categorise glossary definitions and service assertions. These MAY or MAY NOT represent valid hosts in the DNS. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The content of CloudAudit repositories MAY NOT be secure, private or integrity-guaranteed, and due caution should be exercised. Clients SHOULD use Transport Layer Security (TLS) [RFC5246] or equivalent to ensure confidentiality and integrity when accessing CloudAudit repositories over a public network such as the Internet. -- The document date (July 5, 2010) is 5034 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Hoff 3 Internet-Draft Cisco Systems 4 Intended status: Experimental S. Johnston 5 Expires: January 6, 2011 Google 6 G. Reese 7 enStratus 8 B. Sapiro 9 TELUS 10 July 5, 2010 12 CloudAudit 1.0 - Automated Audit, Assertion, Assessment, and Assurance 13 API (A6) 14 draft-hoff-cloudaudit-00 16 Abstract 18 CloudAudit provides an open, extensible and secure interface that 19 allows cloud computing providers to expose Audit, Assertion, 20 Assessment, and Assurance (A6) information for cloud infrastructure 21 (IaaS), platform (PaaS), and application (SaaS) services to 22 authorized clients. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 6, 2011. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3 65 3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1. Repository . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Enumeration . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 5.1. Glossary namespace . . . . . . . . . . . . . . . . . . . . 5 71 5.1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 5 72 5.2. Service namespace . . . . . . . . . . . . . . . . . . . . 6 73 5.2.1. Local Assertions . . . . . . . . . . . . . . . . . . . 6 74 5.2.2. Remote Assertions . . . . . . . . . . . . . . . . . . 9 75 5.2.3. Third-party Assertions . . . . . . . . . . . . . . . . 10 76 6. Digital Signatures . . . . . . . . . . . . . . . . . . . . . . 10 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Initial Registry Contents . . . . . . . . . . . . . . 12 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 CloudAudit provides a common interface, naming convention, set of 89 processes and technologies utilizing the HTTP protocol to enable 90 cloud service providers to automate the collection and assertion of 91 operational, security, audit, assessment, and assurance information. 92 This provides duly authorized and authenticated consumers and brokers 93 of cloud computing services to automate requests for this data and 94 metadata. 96 CloudAudit supports the notion of requests for both structured and 97 unstructured data and metadata aligned to compliance and audit 98 frameworks. Specific compliance framework definitions and namespaces 99 ("compliance packs")) will be made available incrementally. 101 The first CloudAudit release is designed to be as simple as possible 102 so as it can be implemented by creating a consistent namespace and 103 directory structure and placement of files to a standard web server 104 that implements HTTP [RFC2616]. Subsequent releases may add the 105 ability to write definitions and assertions, and to request new 106 assertions be generated (e.g. a network scan). That is, while 1.x 107 versions are read-only, subsequent releases may be read-write. 109 A duly authorized and authenticated client will typically interrogate 110 the service and verify compliance with local policy before making use 111 of it. It may do so by checking certain pre-defined parameters (for 112 example, the geographical location of the servers, compliance with 113 prevailing security standards, etc.) or it may enumerate some/all of 114 the information available and present it to an operator for a manual 115 decision. This process may be fully automated, for example when 116 searching for least cost services or for an alternative service for 117 failover. 119 As it is impossible to tell in advance what information will be of 120 interest to clients and what service providers will be willing to 121 expose, a safely extensible mechanism has been devised which allows 122 any domain name owner to publish both definitions and assertions. 124 2. Notational Conventions 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in BCP 14, [RFC2119], as 129 scoped to those conformance targets. 131 This document uses the Augmented Backus-Naur Form (ABNF) notation of 132 [RFC2616]. 134 Additionally, the following rules are included from [RFC3986]: URI. 136 3. Discovery 138 3.1. Repository 140 Clients SHOULD detect support for CloudAudit by verifying that a HTTP 141 GET or HEAD for the repository root (e.g. /.well-known/cloudaudit) is 142 successful (e.g. "200 OK"). Clients MAY also verify that requests 143 for invalid URLs (e.g. /.well-known/) return an error (e.g. 144 "404 Not Found"). 146 If clients do not confirm the existence of a CloudAudit repository 147 then they may be susceptible to false negatives (e.g. falsely 148 assuming an assertion is absent when in fact the entire repository is 149 absent) and if they do not confirm the absence of errors for invalid 150 URLs then they may be susceptible to false positives (e.g. falsely 151 assuming an assertion is present when in fact any assertion is 152 present). 154 3.2. Links 156 Servers MAY specify the root of a CloudAudit repository in the HTTP 157 Link: header and/or HTML LINK element with 158 rel="http://cloudaudit.org". This allows one or more services to 159 delgate requests to a single local or remote/third-party server. 160 Clients SHOULD check for the presence of these links before assuming 161 that there is a local CloudAudit repository. 162 164 HTML Discovery 166 Link: ; rel="http://cloudaudit.org" 168 HTTP Discovery 170 4. Enumeration 172 Servers MAY render a HyperText Markup Language (HTML) response to a 173 HTTP request for a directory containing an A or LINK element for 174 every child with a HREF attribute containing the relative URL of the 175 child. Clients MUST NOT rely on this functionality, which will vary 176 from server to server. 178 5. Namespaces 180 CloudAudit defines two namespaces; the glossary namespace which 181 contains definitions and the service namespace which contains 182 assertions. It relies on the Domain Name Service (DNS) to divide the 183 glossary and service namespaces in an extensible fashion without 184 relying on registries. 186 A domain name (e.g. example.com) under the control of the party is 187 broken into its components (e.g. example, com), reversed (e.g. com, 188 example) and recombined (e.g. com.example). That party "owns" this 189 namespace so long as the domain is registered to them and they may 190 subdivide it with components in order to reference and/or categorise 191 glossary definitions and service assertions. These MAY or MAY NOT 192 represent valid hosts in the DNS. 194 URI schemes and paths are NOT supported (e.g. 195 https://example.com/cloud), however it is possible for a service to 196 advertise an alternate name (e.g. cloud.example.com) via the HTTP 197 Link header and/or HTML LINK element (Section 3). 199 5.1. Glossary namespace 201 The glossary allows clients to enumerate and/or resolve definitions, 202 and to obtain additional documentation. Servers MUST provide a plain 203 text representation and MAY provide alternative representations (such 204 as HTML) via HTTP content negotiation. 206 5.1.1. Examples 208 5.1.1.1. Generic 210 The following shows a client obtaining a definition for 211 org.iso.3166-1. 212 < GET /.well-known/cloudaudit/glossary/org/iso/3166-1 HTTP/1.1 213 < Host: iso.org 214 < 215 > HTTP/1.1 200 OK 216 > Content-Length: 24 217 > Content-Type: text/plain 218 > 219 > ISO 3166-1 Country Codes 221 5.1.1.2. Compliance 223 The following shows a client obtaining a defintion for 224 gov.nist.crc.sp800-53.r2. 226 < GET /.well-known/cloudaudit/glossary/gov/nist/crc/sp800-53/r2 HTTP/1.1 227 < Host: nist.gov 228 < 229 > HTTP/1.1 200 OK 230 > Content-Length: 102 231 > Content-Type: text/plain 232 > 233 > NIST SP800-53 (Rev. 2) Recommended Security Controls for Federal Information Systems and Organizations 235 5.2. Service namespace 237 Assertions can be made about the local service and/or remote 238 service(s). 240 5.2.1. Local Assertions 242 Local assertions refer to the service(s) sharing the same URL end- 243 point as the CloudAudit repository. They can be identified by the 244 absence of a '/-/' component in the URL (which is used as a 245 delineator for Remote Assertions Section 5.2.2) and can normally be 246 implemented using symbolic links or web server configuration. 248 5.2.1.1. Examples 250 5.2.1.1.1. Generic 252 This example shows a client retrieving the ISO 3166-1 country code(s) 253 from which the cloud.example.com service is being provided. 254 < GET /.well-known/cloudaudit/service/org/iso/3166-1 HTTP/1.1 255 < Host: cloud.example.com 256 < 257 > HTTP/1.1 200 OK 258 > Content-Length: 3 259 > Content-Type: text/plain 260 > 261 > US 263 5.2.1.1.2. Compliance - Human Readable Response 265 This example shows a client retrieving a response to a control 266 section 15.3.1 of ISO 27002 (v2005) from which the cloud.example.com 267 service is being provided. The response is valid HTML and intended 268 to be human readable. 270 < GET /.well-known/cloudaudit/service//org/iso/27002/v2005/15/3/1 HTTP/1.1 271 < Host: cloud.example.com 272 < 273 > HTTP/1.1 200 OK 274 > Content-Length: 822 275 > Content-Type: text/html 276 > 277 > 278 > 279 > 280 > ISO 27002 v2005 15.3.1 281 > 282 >

Information systems audit controls

283 > 288 > 289 > 291 5.2.1.1.3. Compliance - Atom Response 293 This example shows a client retrieving a response to a control 294 section 15.3.1 of ISO 27002 (v2005) from which the cloud.example.com 295 service is being provided. The response is in an ATOM format 296 [RFC4287] and intended to be machine processed. 297 < GET /.well-known/cloudaudit/service//org/iso/27002/v2005/15/3/1/manifest.xml HTTP/1.1 298 < Host: cloud.example.com 299 < 300 > HTTP/1.1 200 OK 301 > Content-Length: 3432 302 > Content-Type: text/xml 303 > 304 > 305 > 306 > ISO 27002 v2005 15.3.1 307 > 308 > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/ 309 > Information systems audit controls 310 > 2010-01-13T18:30:02Z 311 > Cloud Audit Manual Bootstrap Package 312 > 313 > Jon James 314 > jonjames@cloudhosting.com 315 > 316 > Copyright (c) 2009, Cloud Hosting Inc. 317 > 318 > 319 > 320 > Audit Schedule 321 > 322 > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditschedule.xls 323 > 2009-12-28T12:24:02Z 324 > the 2010 audit schedule for cloud hosting inc. 325 > 326 > Eric Smith 327 > ericsmith@cloudhosting.com 328 > 329 > 330 > Mary Huxley 331 > maryhuxley@kpwey.com 332 > http://www.kpwey.com 333 > 334 > 335 > 336 > 337 > KPWEY LLP Audit Contract 338 > 339 > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/contract.pdf 340 > 2009-01-12T11:45:02Z 341 > The audit contract with KPWEY for external audit services 342 > 343 > The document details the services procured to support the audit plan; see page 14 for specific details. 344 > 345 > 346 > Eric Smith 347 > ericsmith@cloudhosting.com 348 > 349 > 350 > Mary Huxley 351 > maryhuxley@kpwey.com 352 > http://www.kpwey.com 353 > 354 > 355 > 356 > 357 > Audit Scope 358 > 359 > http://www.cloudhosting.com/.well-known/cloudaudit/org/iso/27002/v2005/15/3/1/auditscope.zip 360 > 2009-12-28T12:25:02Z 361 > The audit scope for the planned audits in 2010 362 > 363 > Sarah Chan 364 > sarahchan@cloudhosting.com 365 > 366 > 367 > David Kohl 368 > davidkohl@kpwey.com 369 > 370 > 371 > Mary Huxley 372 > maryhuxley@kpwey.com 373 > http://www.kpwey.com 374 > 375 > 376 > 378 5.2.1.1.4. Compliance - Non-Existent 380 This example shows a client atempting to retrieve a non existent 381 response to a control section of NIST SP800-53 (Rev 2) from which the 382 cloud.example.com service is being provided. 383 < GET /.well-known/cloudaudit/glossary/gov/nist/crc/sp800-53/r2/cp-2 HTTP/1.1 384 < Host: cloud.example.com 385 < 386 > HTTP/1.1 404 Not Found 387 > Content-Length: 148 388 > Content-Type: text/html 389 > 390 > 391 > 392 > 404 Not Found 393 >

Error: Not Found

394 >

The requested URL was not found on this server.

395 > 396 > 398 5.2.2. Remote Assertions 400 There are a number of scenarios where it is necessary to answer 401 CloudAudit queries on behalf of others, including: 403 o Responding to queries on behalf of multiple servers 405 o Responding to queries from multiple clients 407 o Proxying in order to supplement or override assertions 409 o Incompatibilities with existing systems and software that prevents 410 co-location 412 Remote assertions are supported by embedding both the name (e.g. 413 cloud.example.com) and the assertion queried (e.g. 3166-1.iso.org) in 414 the URL. The name and assertion MUST be delineated with a '/-/' URL 415 component as they may vary in length. 417 5.2.2.1. Examples 419 This example shows a client retrieving the ISO 3166-1 country code(s) 420 from which the cloud.example.com service is being provided, from the 421 remote server cloudaudit.net. 422 < GET /.well-known/cloudaudit/service/com/example/cloud/-/org/iso/3166-1 HTTP/1.1 423 < Host: cloudaudit.net 424 < 425 > HTTP/1.1 200 OK 426 > Content-Length: 3 427 > Content-Type: text/plain 428 > 429 > US 431 5.2.3. Third-party Assertions 433 It may be necessary for third-parties to make assertions, for example 434 where an auditor certifies compliance with a given standard at a 435 given time. This can be achieved either by retrieving a trusted 436 representation (for example, an image containing a physical 437 signature, or a digitally signed document) from the first-party or by 438 being redirected to a third-party and retrieving the assertion 439 directly from them. 441 6. Digital Signatures 443 Digital signatures allow clients to verify the integrity of the 444 assertions (both first-party and third-party). 446 7. IANA Considerations 448 This document makes no request of IANA. 450 Note to RFC Editor: this section may be removed on publication as an 451 RFC. 453 8. Security Considerations 455 The content of CloudAudit repositories MAY NOT be secure, private or 456 integrity-guaranteed, and due caution should be exercised. Clients 457 SHOULD use Transport Layer Security (TLS) [RFC5246] or equivalent to 458 ensure confidentiality and integrity when accessing CloudAudit 459 repositories over a public network such as the Internet. 461 The Domain Name System (DNS) MAY be susceptible to attacks and care 462 should be taken to authenticate servers, for example by verifying the 463 chain of trust and infromation contained in SSL certificates 464 provided, by using a Virtual Private Network (VPN) service, by 465 relying on DNSSEC [RFC4033], etc. 467 Malicious clients MAY seek to obtain sensitive information via 468 CloudAudit which could then be used to launch an attack. Such 469 information should only be made available to authorised clients who 470 have been authenticated via HTTP authentication [RFC2617] or 471 equivalent. 473 Servers may make false first-party assertions or may refer to third- 474 party assertions that do not apply to them, or that expand the scope 475 of the intended meaning. Clients that do not trust servers may 476 choose only to rely on trusted third-party assertions, in which case 477 the integrity of the assertion SHOULD be verified by transferring it 478 over Transport Layer Security (TLS) [RFC5246] or equivalent or by 479 verifying a digital signature applied to the assertion using OpenPGP 480 [RFC4880] or equivalent 482 9. Acknowledgements 484 The authors would like to acknowledge all members of the CloudAudit 485 Working Group, editors of framework specification documents 486 (including Doug Barbin, Mike Versace, James Arlen and Dave Lewis), 487 the publishers of frameworks (including ISACA, HHS, ISO, NIST and 488 PCI) and early adopters of the standard. 490 10. References 492 10.1. Normative References 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 498 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 499 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 501 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 502 Leach, P., Luotonen, A., and L. Stewart, "HTTP 503 Authentication: Basic and Digest Access Authentication", 504 RFC 2617, June 1999. 506 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 507 Resource Identifier (URI): Generic Syntax", STD 66, 508 RFC 3986, January 2005. 510 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 511 Rose, "DNS Security Introduction and Requirements", 512 RFC 4033, March 2005. 514 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 515 Syndication Format", RFC 4287, December 2005. 517 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 518 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 520 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 521 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 523 [W3C.REC-html401-19991224] 524 Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 525 Specification", World Wide Web Consortium 526 Recommendation REC-html401-19991224, December 1999, 527 . 529 10.2. Informative References 531 Appendix A. Initial Registry Contents 533 The CloudAudit registry's initial contents are: 535 o Assertion Name: org.iso.3166-1 537 o Description: Codes for the representation of names of countries 538 and their subdivisions -- Part 1: Country codes 540 o Reference: http://www.iso.org/iso/iso-3166-1_decoding_table 542 Authors' Addresses 544 Christofer Hoff 545 Cisco Systems 546 200 Beaver Brook Road 547 Building 200 548 Boxborough, MA 01719 549 USA 551 Phone: +1.9786310302 552 Email: hoffc@cisco.com 554 Sam Johnston 555 Google 556 Brandschenkestrasse 110 557 Zurich, 8002 558 Switzerland 560 Phone: +41.446681679 561 Email: sj@google.com 563 George Reese 564 enStratus 565 1201 Marquette Ave 566 Suite 150 567 Minneapolis, MN 55403 568 USA 570 Phone: +1.6127463091 571 Email: george.reese@enstratus.com 573 Ben Sapiro 574 TELUS Security Labs 575 25 York Street 576 Toronto M5J 2V5 577 Canada 579 Phone: +1.6478899432 580 Email: ben@sapiro.net