idnits 2.17.1 draft-farrell-pkng-swig-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 8, 2010) is 4917 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force S. Farrell 3 Internet-Draft Trinity College Dublin 4 Intended status: Experimental L. Johansson 5 Expires: May 12, 2011 SUNET/NORDUnet 6 November 8, 2010 8 Sign What I'm Given (SWIG) 9 draft-farrell-pkng-swig-00 11 Abstract 13 Current Internet protocols tend to be based on either X.509 based 14 PKI, or Kerberos. Both have limitations and age-related issues. In 15 this draft, we outline a possible approach to providing similar, and 16 additional, functionality based on an abstract device that always 17 signs whatever its given, and that may additionally annotate or 18 modify its input in order to fulfill the security needs of other 19 protocols. This draft describes a SWIG service and how it can be 20 used to conduct research into a number of important problems in 21 Internet trust and identity management today. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on May 12, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. SWIG Service Overview . . . . . . . . . . . . . . . . . . . . . 3 59 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. X.509-like Infrastructure . . . . . . . . . . . . . . . . . 4 61 3.2. Application Layer Signing . . . . . . . . . . . . . . . . . 5 62 3.3. Privacy Enhancing SWIGs . . . . . . . . . . . . . . . . . . 5 63 3.4. SAML Metadata Publisher . . . . . . . . . . . . . . . . . . 5 64 4. SWIG Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4.1. REST . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1.1. SWIG HTTP Headers . . . . . . . . . . . . . . . . . . . 6 67 5. SWIG Standard Transformations . . . . . . . . . . . . . . . . . 6 68 5.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 71 8. Normative References . . . . . . . . . . . . . . . . . . . . . 6 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The Internet of today is a low-trust environment. The IRTF has 77 identified a need to support research in this area. This draft 78 attempts to describe a new protocol that is intended as a tool for 79 experimentation and research in this field. While some current 80 protocols (eg X.509 or kerberos) could be adopted to provide similar 81 capabilities as SWIG, here we present a clean-slate approach to some 82 of those problems. 84 Current protocols and solutions in this space often focuses on the 85 credentials used to perform basic functions (eg signing or 86 encryptions). The operation of signing and returning a signed 87 representation of an object is at the heart of many protocols. SWIG 88 attemts to bring together experience from (arguably) successful 89 security protocols while refocusing on the signing operation rather 90 than on key and credentials formats. The authors hope that this will 91 inspire research into a few problems that we believe are important to 92 the future of the Internet: 94 o How can we build a trust-model for the Internet that takes 95 multiple overlapping rings-of-trust into account? 97 o How can applications become involved with and informed about 98 trust-related decisions made by lower layers? 100 o Internet networking today is driven by the process managing 101 peering relationships in combination with the applicationof local 102 policy. Is there a way to build a trust infrastructure for the 103 Internet that mimics this model? 105 o How can privacy-protection be supported by default, rather than as 106 an add-on to protocols? 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. SWIG Service Overview 114 The reader will undoubtedly notice that the SWIG model is 115 conceptually similar to a lot of protocols that have been proposed, 116 implemented and even in some cases widely deployed. That is entierly 117 reasonable and indeed is an important aspect of SWIG: it does not 118 fundamentally break the model for signing that is assumed by 119 applications, but attempts to enhance those models. 121 Furthermore the authors hope that by providing a simple extensible 122 architecture it will be easier in the future for sites and 123 individuals to consolidate signing operations to use a smaller set of 124 well-managed keys. In a way SWIG can be considered a very simple 125 protocol-version of such ABIs as PKCS#11 or CSP. 127 A SWIG is an abstract service endpoint that observes a set of simple 128 semantics. An instance of a SWIG service MUST sign what it is given, 129 so the basic mode of interaction is that a client sends some data, 130 and receives in return a signed representation of that data signed by 131 the SWIG instance private key. 133 The response MAY include additional data or MAY include a transformed 134 version (e.g. encrypted) of the request data. How a given instance 135 handles this is specific to the instance however it is expected that 136 implementations of SWIG allow for easy deployment of new 137 transformations through some form of plugin architecture. 139 It is important to understand that most common instances of SWIG will 140 not sign a 1-1 representation of the input request. Instead a SWIG 141 instance will probably sign a representation of the request, eg by 142 resolving the request as an identifier referencing some internal 143 datastore. 145 Every SWIG instance MUST respond to certain specific requests, e.g. 146 to provide its public key, or identifiers for the transformations it 147 supports on input data. 149 If a requestor wishes a SWIG service to apply a specific transform to 150 its input data, then it identifies that transform in its request, 151 using an identifier, that can be retrieved as described in the 152 previous paragraph. Specific transforms and their identifiers SHOULD 153 be defined in open specifications. 155 3. Use Cases 157 This section explains how various use-cases can be suppored via SWIG. 159 3.1. X.509-like Infrastructure 161 An X.509-like infrastructure could be built from a set of SWIG 162 instances by having SWIG instances issue responses that are simlar to 163 (or contain) public key certificates. Chains of certificate-like 164 things can be built in the same manner, as can OCSP-like responders, 165 and LDAP-like schemes for finding public keys. In ways, SWIG could 166 resemble XKMS, in how it maps to X.509 based PKI. 168 3.2. Application Layer Signing 170 If a message source requires an application-layer signature that can 171 be verified by a relying party, then it can send the application 172 layer message to a SWIG instance, and the SWIG instance's signature 173 can be directly used in the application layer protocol. 175 3.3. Privacy Enhancing SWIGs 177 A SWIG instance could support a transform that enhances privacy, for 178 example, if personally identifying input data is encrypted by the 179 SWIG, using a key known only to the SWIG, and the relying party has 180 to request that from the SWIG (if necessary, for application 181 purposes). The SWIG instance could also provide the RP with a 182 "fuzzed" version of the identiying information, for example, only 183 identifying the country of the original requestor. 185 3.4. SAML Metadata Publisher 187 A SAML Metadata aggregator/publisher can be described as a SWIG 188 instance that accepts requests that contain as input a set of 189 entityID strings and returns a signed element 190 containing the corresponding set of metadata as known by the SWIG 191 instance. 193 4. SWIG Protocol 195 There may well turn out to be a need for multiple bindings of the 196 SWIG protocol. This section describes a very simple RESTful HTTP- 197 based approach: 199 4.1. REST 201 A SWIG endpoint is identified by a URI. The URI may contain a public 202 identifier representing the public key used in signing responses (eg 203 a key hash). A SWIG endpoint is an HTTP server that understands the 204 SWIG headers. 206 A SWIG request is an HTTP request (POST or GET) that contains at 207 least the SWIG-Version header and optionally the SWIG-Transform 208 header. Each SWIG endpoint MUST support the set of standard 209 transformations listed in the following section. A special case is 210 the Capabilities transform: a SWIG endpoint MUST treat the absense of 211 a SWIG-Transform header as if the SWIG-Transform contained only the 212 'capabilities' string. 214 A SWIG response is an HTTP response that contains at least the SWIG- 215 Version and optionally (if the 'capabilities' transform was invoked) 216 the SWIG-Transform header. The response will also include a signed 217 representation of the requested data which will be communicated in 218 the HTTP response body. 220 4.1.1. SWIG HTTP Headers 222 SWIG-Transform: each value of this multivalued header identifies a 223 transform that is to be applied in order to produce the result that 224 the SWIG instance will sign and return in the response. This header 225 is also used to return the set of supported transforms for the 226 'capabilities' transform. TODO: figure out if we need mime-types 227 and/or mime-type options for this. 229 SWIG-Version: a version identifying the version of the SWIG protocol. 230 This MUST be the literal string "1.0" for this version of the SWIG 231 protocol. 233 5. SWIG Standard Transformations 235 Transformations are identified using strings that are compared as 236 case-insensitive UTF-8 strings. 238 5.1. Capabilities 240 The 'cababilities' transform MUST cause the SWIG endpoint to return a 241 response containing the signer public key (TBD: figure out how to 242 determine which representation to return to the requestor) along with 243 a list of supported transforms. 245 6. IANA Considerations 247 This memo includes no request to IANA so far. But if it doesn't die, 248 we'll want a port, maybe an SRV name and a registry for transform 249 identifiers. 251 7. Security Considerations 253 There will be a bunch, no doubt. 255 8. Normative References 257 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 258 Requirement Levels", BCP 14, RFC 2119, March 1997. 260 Authors' Addresses 262 Stephen Farrell 263 Trinity College Dublin 264 Trinity College 265 Dublin, 2 266 Ireland 268 Phone: +353-1-896-2354 269 Email: stephen.farrell@cs.tcd.ie 271 Leif Johansson 272 SUNET/NORDUnet 273 Tulegatan 11 274 Stockholm, 275 Sweden 277 Phone: +46703419886 278 Fax: 279 Email: leifj@sunet.se 280 URI: