Internet DRAFT - draft-farrell-pkng-swig

draft-farrell-pkng-swig






Internet Research Task Force                                  S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Experimental                               L. Johansson
Expires: May 12, 2011                                     SUNET/NORDUnet
                                                        November 8, 2010


                       Sign What I'm Given (SWIG)
                       draft-farrell-pkng-swig-00

Abstract

   Current Internet protocols tend to be based on either X.509 based
   PKI, or Kerberos.  Both have limitations and age-related issues.  In
   this draft, we outline a possible approach to providing similar, and
   additional, functionality based on an abstract device that always
   signs whatever its given, and that may additionally annotate or
   modify its input in order to fulfill the security needs of other
   protocols.  This draft describes a SWIG service and how it can be
   used to conduct research into a number of important problems in
   Internet trust and identity management today.

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 May 12, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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



Farrell & Johansson       Expires May 12, 2011                  [Page 1]

Internet-Draft                  PKNG SWIG                  November 2010


   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.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  SWIG Service Overview . . . . . . . . . . . . . . . . . . . . . 3
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
     3.1.  X.509-like Infrastructure . . . . . . . . . . . . . . . . . 4
     3.2.  Application Layer Signing . . . . . . . . . . . . . . . . . 5
     3.3.  Privacy Enhancing SWIGs . . . . . . . . . . . . . . . . . . 5
     3.4.  SAML Metadata Publisher . . . . . . . . . . . . . . . . . . 5
   4.  SWIG Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  REST  . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
       4.1.1.  SWIG HTTP Headers . . . . . . . . . . . . . . . . . . . 6
   5.  SWIG Standard Transformations . . . . . . . . . . . . . . . . . 6
     5.1.  Capabilities  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 7


























Farrell & Johansson       Expires May 12, 2011                  [Page 2]

Internet-Draft                  PKNG SWIG                  November 2010


1.  Introduction

   The Internet of today is a low-trust environment.  The IRTF has
   identified a need to support research in this area.  This draft
   attempts to describe a new protocol that is intended as a tool for
   experimentation and research in this field.  While some current
   protocols (eg X.509 or kerberos) could be adopted to provide similar
   capabilities as SWIG, here we present a clean-slate approach to some
   of those problems.

   Current protocols and solutions in this space often focuses on the
   credentials used to perform basic functions (eg signing or
   encryptions).  The operation of signing and returning a signed
   representation of an object is at the heart of many protocols.  SWIG
   attemts to bring together experience from (arguably) successful
   security protocols while refocusing on the signing operation rather
   than on key and credentials formats.  The authors hope that this will
   inspire research into a few problems that we believe are important to
   the future of the Internet:

   o  How can we build a trust-model for the Internet that takes
      multiple overlapping rings-of-trust into account?

   o  How can applications become involved with and informed about
      trust-related decisions made by lower layers?

   o  Internet networking today is driven by the process managing
      peering relationships in combination with the applicationof local
      policy.  Is there a way to build a trust infrastructure for the
      Internet that mimics this model?

   o  How can privacy-protection be supported by default, rather than as
      an add-on to protocols?

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].


2.  SWIG Service Overview

   The reader will undoubtedly notice that the SWIG model is
   conceptually similar to a lot of protocols that have been proposed,
   implemented and even in some cases widely deployed.  That is entierly
   reasonable and indeed is an important aspect of SWIG: it does not
   fundamentally break the model for signing that is assumed by
   applications, but attempts to enhance those models.




Farrell & Johansson       Expires May 12, 2011                  [Page 3]

Internet-Draft                  PKNG SWIG                  November 2010


   Furthermore the authors hope that by providing a simple extensible
   architecture it will be easier in the future for sites and
   individuals to consolidate signing operations to use a smaller set of
   well-managed keys.  In a way SWIG can be considered a very simple
   protocol-version of such ABIs as PKCS#11 or CSP.

   A SWIG is an abstract service endpoint that observes a set of simple
   semantics.  An instance of a SWIG service MUST sign what it is given,
   so the basic mode of interaction is that a client sends some data,
   and receives in return a signed representation of that data signed by
   the SWIG instance private key.

   The response MAY include additional data or MAY include a transformed
   version (e.g. encrypted) of the request data.  How a given instance
   handles this is specific to the instance however it is expected that
   implementations of SWIG allow for easy deployment of new
   transformations through some form of plugin architecture.

   It is important to understand that most common instances of SWIG will
   not sign a 1-1 representation of the input request.  Instead a SWIG
   instance will probably sign a representation of the request, eg by
   resolving the request as an identifier referencing some internal
   datastore.

   Every SWIG instance MUST respond to certain specific requests, e.g.
   to provide its public key, or identifiers for the transformations it
   supports on input data.

   If a requestor wishes a SWIG service to apply a specific transform to
   its input data, then it identifies that transform in its request,
   using an identifier, that can be retrieved as described in the
   previous paragraph.  Specific transforms and their identifiers SHOULD
   be defined in open specifications.


3.  Use Cases

   This section explains how various use-cases can be suppored via SWIG.

3.1.  X.509-like Infrastructure

   An X.509-like infrastructure could be built from a set of SWIG
   instances by having SWIG instances issue responses that are simlar to
   (or contain) public key certificates.  Chains of certificate-like
   things can be built in the same manner, as can OCSP-like responders,
   and LDAP-like schemes for finding public keys.  In ways, SWIG could
   resemble XKMS, in how it maps to X.509 based PKI.




Farrell & Johansson       Expires May 12, 2011                  [Page 4]

Internet-Draft                  PKNG SWIG                  November 2010


3.2.  Application Layer Signing

   If a message source requires an application-layer signature that can
   be verified by a relying party, then it can send the application
   layer message to a SWIG instance, and the SWIG instance's signature
   can be directly used in the application layer protocol.

3.3.  Privacy Enhancing SWIGs

   A SWIG instance could support a transform that enhances privacy, for
   example, if personally identifying input data is encrypted by the
   SWIG, using a key known only to the SWIG, and the relying party has
   to request that from the SWIG (if necessary, for application
   purposes).  The SWIG instance could also provide the RP with a
   "fuzzed" version of the identiying information, for example, only
   identifying the country of the original requestor.

3.4.  SAML Metadata Publisher

   A SAML Metadata aggregator/publisher can be described as a SWIG
   instance that accepts requests that contain as input a set of
   entityID strings and returns a signed <EntityDescriptors/> element
   containing the corresponding set of metadata as known by the SWIG
   instance.


4.  SWIG Protocol

   There may well turn out to be a need for multiple bindings of the
   SWIG protocol.  This section describes a very simple RESTful HTTP-
   based approach:

4.1.  REST

   A SWIG endpoint is identified by a URI.  The URI may contain a public
   identifier representing the public key used in signing responses (eg
   a key hash).  A SWIG endpoint is an HTTP server that understands the
   SWIG headers.

   A SWIG request is an HTTP request (POST or GET) that contains at
   least the SWIG-Version header and optionally the SWIG-Transform
   header.  Each SWIG endpoint MUST support the set of standard
   transformations listed in the following section.  A special case is
   the Capabilities transform: a SWIG endpoint MUST treat the absense of
   a SWIG-Transform header as if the SWIG-Transform contained only the
   'capabilities' string.

   A SWIG response is an HTTP response that contains at least the SWIG-



Farrell & Johansson       Expires May 12, 2011                  [Page 5]

Internet-Draft                  PKNG SWIG                  November 2010


   Version and optionally (if the 'capabilities' transform was invoked)
   the SWIG-Transform header.  The response will also include a signed
   representation of the requested data which will be communicated in
   the HTTP response body.

4.1.1.  SWIG HTTP Headers

   SWIG-Transform: each value of this multivalued header identifies a
   transform that is to be applied in order to produce the result that
   the SWIG instance will sign and return in the response.  This header
   is also used to return the set of supported transforms for the
   'capabilities' transform.  TODO: figure out if we need mime-types
   and/or mime-type options for this.

   SWIG-Version: a version identifying the version of the SWIG protocol.
   This MUST be the literal string "1.0" for this version of the SWIG
   protocol.


5.  SWIG Standard Transformations

   Transformations are identified using strings that are compared as
   case-insensitive UTF-8 strings.

5.1.  Capabilities

   The 'cababilities' transform MUST cause the SWIG endpoint to return a
   response containing the signer public key (TBD: figure out how to
   determine which representation to return to the requestor) along with
   a list of supported transforms.


6.  IANA Considerations

   This memo includes no request to IANA so far.  But if it doesn't die,
   we'll want a port, maybe an SRV name and a registry for transform
   identifiers.


7.  Security Considerations

   There will be a bunch, no doubt.


8.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.



Farrell & Johansson       Expires May 12, 2011                  [Page 6]

Internet-Draft                  PKNG SWIG                  November 2010


Authors' Addresses

   Stephen Farrell
   Trinity College Dublin
   Trinity College
   Dublin,   2
   Ireland

   Phone: +353-1-896-2354
   Email: stephen.farrell@cs.tcd.ie


   Leif Johansson
   SUNET/NORDUnet
   Tulegatan 11
   Stockholm,
   Sweden

   Phone: +46703419886
   Fax:
   Email: leifj@sunet.se
   URI:





























Farrell & Johansson       Expires May 12, 2011                  [Page 7]