[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          Johansson
Internet-Draft                                                     SUNET
Intended status: Informational                              July 6, 2009
Expires: January 7, 2010


                  Simple Public Key Trust Alternatives
                    draft-johansson-pk-trust-alts-00

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 7, 2010.

Copyright Notice

   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Johansson                Expires January 7, 2010                [Page 1]

Internet-Draft            PK Trust Alternatives                July 2009


Abstract

   This document describes often used patterns for establishing
   technical trust for public key-based security architectures other
   than traditional PKIX-based public key infrastructure.  The intent is
   that this document be useful as a reference for protocol
   specification authors who use technology like PKIX, PGP or S/MIME as
   part of their protocols.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction and motiviation . . . . . . . . . . . . . . . . .  4
   3.  PKIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Simple Public Key Trust Alternatives . . . . . . . . . . . . .  7
     4.1.  The role of X.509 certificates . . . . . . . . . . . . . .  7
     4.2.  Manually Shared Public Keys  . . . . . . . . . . . . . . .  7
     4.3.  Leap-of-faith Shared Public Keys . . . . . . . . . . . . .  8
     4.4.  Authenticated Bag-of-Keys  . . . . . . . . . . . . . . . .  8
   5.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.1.  SAML Metadata  . . . . . . . . . . . . . . . . . . . . . . 10
     5.2.  DNSSEC Trust Bridge  . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informational References . . . . . . . . . . . . . . . . . 13
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14






















Johansson                Expires January 7, 2010                [Page 2]

Internet-Draft            PK Trust Alternatives                July 2009


1.  Terminology

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
   and "MAY" that appear in this document are to be interpreted as
   described in [RFC2119]














































Johansson                Expires January 7, 2010                [Page 3]

Internet-Draft            PK Trust Alternatives                July 2009


2.  Introduction and motiviation

   Several protocols introduced by the IETF aswell as by by other SDOs
   employ public key-based technology in various ways - notably in order
   to protect messages or channels, eg using security technology like
   S/MIME, PGP or TLS.  Notable examples include SIP, XMPP aswell as
   calendaring and scheduling protocols and several WebSSO technologies
   including SAML and OpenID.

   A common problem facing these protocols is how to establish technical
   trust between protocol endpoints in the absence of a canonical
   internet-wide PKI.

   This document only deals with technical trust, i.e artifacts and
   entities used to establish secure channels between protocol
   endpoints.  Arguably there are larger issues involved in the general
   concept of "trust" but this falls outside the scope of this document.

   Furthermore this document does not attempt to describe new design for
   technical trust but rather focuses on what can be achieved using
   common existing protocols, implementations and toolchains.

   Quite often the problem of establishing technical trust for public-
   key technologies is presented as a simple market problem.  The theory
   is that since public Certificate Authorities (CAs) exist and are
   readily available, their products are a simple answer to the question
   of how to establish technical trust between (say) TLS endpoints.

   Economy does play a role in trust.  Most commercial CAs sell several
   products where the price of the certificate is related to the cost of
   identity vetting that is performed so clearly there is a relationship
   between the amount of work that is spent on vetting and due diligence
   and the value of the trust represented by the technical trust bearer
   (eg X.509 certificate) that is produced.

   Quite often it is desirable to establish technical trust between a
   small group of entities, excluding all others with a high degree of
   certainty.  This is also known as a "ring of trust".  For instance a
   private CA could be used to represent trust in a set of properties
   shared by all entities issued keys from the CA - for instance that
   all key holders represent the same type of organization or that they
   all represent the same class of service.  The value of the CA is in
   the vetting and due diligence done to insure that the set of of
   certificates issued from the CA is isomorphic to a proper subset of
   entities having the given property.

   Rather than being a simple question of "how much" vetting/due
   diligence was done before signing a certificate we see that trust



Johansson                Expires January 7, 2010                [Page 4]

Internet-Draft            PK Trust Alternatives                July 2009


   often depends on specific contextual validation ("does this endpoint
   have property X?") for which no market exists in general since the
   size of these rings of trust are often small compared to the number
   of customers of most commercial CAs.

   One problem with the single PKI model is that entities often need to
   participate in transactions within multiple contexts joining multiple
   rings of trust.  The various ways in which multiple contexts can be
   represented using PKIX (eg naming constraints or 'bridge' CAs) are
   either not widely implemented or suffer from interoperability
   problems making them somewhat impractical.

   This is not to say that traditional PKIX technology does not have a
   role to play still.  Some of the strategies described in this
   protocol can be seen as extensions building on top of traditional PKI
   which remain an important tool.



































Johansson                Expires January 7, 2010                [Page 5]

Internet-Draft            PK Trust Alternatives                July 2009


3.  PKIX

   TODO: Overview of bridge/cross PKI.
















































Johansson                Expires January 7, 2010                [Page 6]

Internet-Draft            PK Trust Alternatives                July 2009


4.  Simple Public Key Trust Alternatives

4.1.  The role of X.509 certificates

   An X.509 certificate can carry lots of semantics using its names and
   extensions.  It is also possible to treat an X.509 certificate as a
   simple public key container, disregarding any other element in the
   certificate.  Validation for such "raw key" certificates MUST be
   limited to comparing the public key or key fingerprint with a copy of
   the public key received from a trusted source.  Used this way an
   X.509 certificate can be used with most existing PKIX implementations
   by altering the way certificate validation is performed.

   While it may seem easier (and cleaner) to handle raw keys directly
   this is seldom supported in existing implementations.

4.2.  Manually Shared Public Keys

   Arguably the simplest form of trust is derived from manually sharing
   keys.  This can easily implemented using any X.509 certificates
   (which do not necessarily have to be self-signed) serving as public
   key bearers.  In order to support this model it MUST be possible to
   validate endpoints using key values or key fingerprints.  Exactly how
   the keys are established and updated is out of scope for this simple
   model.

   An example is RADIUS over TCP.  Traditionally RADIUS uses a shared-
   secret model where RADIUS clients and servers are each given (out of
   band) a secret which must be shared among parties who need to
   communicate with each other.  RADIUS uses UDP.  Recent work has
   extended RADIUS to use TCP ([I-D.ietf-radext-radsec]) and TLS for
   securing communication between RADIUS endpoints.

   Distributing self-signed X.509 certificates and validating peers
   using their raw keys or key fingerprints is in this context
   semantically equivalent to managing traditional RADIUS shared
   secrets.

   This begs the question of why a PKI isn't a better alternative than
   self-signed X.509 certificates used as raw key bearers.  From a
   theoretical perspective a PKI might be preferable to manually sharing
   keys but practical deployment experience shows that it is very
   uncommon for RADIUS servers only to be part of a single business
   relationship which would lead to the requirement to deploy bridge or
   cross CA between the PKIX PKIs representing the various relationships
   a RADIUS server may be part of.

   Deploying bridge CAs constitutes overhead which may be difficult to



Johansson                Expires January 7, 2010                [Page 7]

Internet-Draft            PK Trust Alternatives                July 2009


   justify when the scale of the business relationships (number of
   relationships and number of members in each ring of trust) is small.
   By comparison manually sharing (possibly self-signed) certificate is
   good enough for many situations.

4.3.  Leap-of-faith Shared Public Keys

   Certain protocols such as Secure Shell ([RFC4251] and [RFC4253]) and
   BTNS ([RFC5386]) allow security associations to be established by the
   so called leap-of-faith model where an initial association is
   established with little or no prior trust.  Subsequent associations
   to the same endpoint is by contrast required to be authenticated
   using keys or other artifacts exchanged during the first association.

   For instance Secure Shell associates endpoints (Secure Shell servers)
   with key fingerprints.  When an SSH client opens a connection to the
   server fingerprints MUST match or the user is notified and forced to
   take action to manually authenticate the (possibly valid) new key.

   The Secure Shell leap-of-faith authentication can be generalized to a
   pattern for public key sharing: Protocols implementing this pattern
   MUST provide mechanisms for endpoints to publish their keys or key
   fingerprints or include them in protocol messages.

   The first time a trust relationship is needed the keys or
   fingerprints are associated with a representation of the endpont (eg
   URL or hostname).  If the endpoint subsequently publishes a different
   (set of) keys or fingerprints the trust relationship MUST be
   invalidated and a manual process MUST resolve if this was a valid key
   roll-over or an attack.

4.4.  Authenticated Bag-of-Keys

   A variation of manually shared public keys, the bag-of-keys approach
   is similar to a traditional X.509 Certificate Authority but with a
   few important operational differences.

   The bag-of-keys is a data structure (eg XML, DNS resource records,
   ASN.1, etc) containing encoded representation of keys (either raw
   keys, X.509 certificates or in some cases fingerprints of keys).  The
   data structure MUST be authenticated for instance using one or more
   digital signatures and it is from this authentication that trust in
   the contained keys is derived.

   Trust in the authentication (eg the signing keys) can be established
   using manually sharing the corresponding public keys (cf above) or by
   any other means, including the mechanisms described in this document.
   Below we'll see how DNSSEC fits into this picture.



Johansson                Expires January 7, 2010                [Page 8]

Internet-Draft            PK Trust Alternatives                July 2009


   By including a time-to-live parameter for the embedded keys or
   fingerprints in the data structure itself the consumer of the keys
   can easily determine for how long it is safe to cache the keys in the
   data structure.

   There are several operationally significant differences between a
   authenticated bag-of-keys and a traditional CA:

   o  The data structure can describe its own validity to consumers
      which eliminates the need for revocation infrastructure (eg CRLs
      or OCSP) - the bag-of-keys is both a CA and a CRL of sorts.
      Regular updates of the bag-of-keys replaces the need for validity
      checks.

   o  Most signature representation (eg XML-DSig or CMS) allows for
      multiple separate signatures on a single object.  Using this
      mechanism to authenticate the bag-of-keys data structure it is
      possible to represent multiple trust relationships on single bag-
      of-keys.

   o  It is possible to assign multiple keys (with different life-times
      for instance) to a given entity in the bag-of-keys allowing for a
      simple roll-over mechanism.

   o  Keys contained in the bag-of-keys can be used to configure the
      validation-engine at a time separate from when these keys are used
      - i.e validation is done at configure-time rather than at run-
      time.  This may seem like a relatively minor point but deployment
      experience from web federated identity shows this to be an
      important simplification.





















Johansson                Expires January 7, 2010                [Page 9]

Internet-Draft            PK Trust Alternatives                July 2009


5.  Examples

5.1.  SAML Metadata

   The Security Assertion Markup Language (SAML) is a set of protocols
   and protocol bindings used to communicate information about
   authentication and authorization between peers.  Communication is in
   the form of XML-based messages.  Security is either derived from
   security at the message-transport layer (eg TLS) or XML digital
   signatures of the XML messages.  In both cases SAML employs various
   means of establishing technical trust between peers.

   Information about SAML entities (protocol endpoints and bindings) is
   sometimes described using SAML metadata which is used by protocol
   endpoints and supporting infrastructure.  An important part of SAML
   metadata is to describe the entity-to-key mapping which can be done
   either by giving the name of a key (eg the name of a certificate) or
   by embedding the key itself.

   Embedding keys in metadata (which is then signed using XML-DSig) is
   an example of the bag-of-keys pattern described above.

5.2.  DNSSEC Trust Bridge

   DNSSEC [RFC4033], [RFC4034], [RFC4035] is a mechanism for securing
   data in the domain name system (DNS).  By introducing new (or reusing
   existing) resource records it is possible to use DNSSEC to provide a
   measure of authentication for any data than can be represented stored
   and queried from the DNS.

   For instance [RFC4255] describes a way to store Secure Shell (
   [RFC4251] and [RFC4253]) fingerprints in DNS and a semantics for the
   trust derived from such fingerprints when stored in Secure DNS.
   Other examples include [RFC4398] (certificates in the DNS) and
   [RFC4025] (IPSec keying material).

   We can think of these cases as examples of the authenticated bag-of-
   keys pattern where DNSSEC authenticates the keys (or fingerprints of
   keys) represented as DNS resource records.












Johansson                Expires January 7, 2010               [Page 10]

Internet-Draft            PK Trust Alternatives                July 2009


6.  Security Considerations

   Revocation is an important part of key management.  Experience shows
   that it is sometimes quite difficult to achieve large-scale
   deployment of revocation infrastructure.  The authentication bag-of-
   keys pattern does not include revocation but instead relies on the
   consumer regularly refreshing the data structure.  Should the
   consumer fail to do that there is an increased risk of key
   compromise.

   Leap-of-faith key sharing is vulnerable to user fatigue - presenting
   a user with questions about security associations when the user only
   wants to "get to his/her stuff" clearly hasn't worked so far.

   Implementors of leap-of-faith patterns should strongly consider not
   allowing users to make decisions about security associations at all
   or at least not to present such decisions as problems to be overcome
   before the user can access resources.

































Johansson                Expires January 7, 2010               [Page 11]

Internet-Draft            PK Trust Alternatives                July 2009


7.  IANA Considerations

   None
















































Johansson                Expires January 7, 2010               [Page 12]

Internet-Draft            PK Trust Alternatives                July 2009


8.  References

8.1.  Normative References

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

8.2.  Informational References

   [I-D.ietf-radext-radsec]
              Winter, S., McCauley, M., Venaas, S., and K. Wierenga,
              "TLS encryption for RADIUS over TCP (RadSec)",
              draft-ietf-radext-radsec-04 (work in progress),
              March 2009.

   [RFC4025]  Richardson, M., "A Method for Storing IPsec Keying
              Material in DNS", RFC 4025, March 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4251]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Protocol Architecture", RFC 4251, January 2006.

   [RFC4253]  Ylonen, T. and C. Lonvick, "The Secure Shell (SSH)
              Transport Layer Protocol", RFC 4253, January 2006.

   [RFC4255]  Schlyter, J. and W. Griffin, "Using DNS to Securely
              Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
              January 2006.

   [RFC4398]  Josefsson, S., "Storing Certificates in the Domain Name
              System (DNS)", RFC 4398, March 2006.

   [RFC5386]  Williams, N. and M. Richardson, "Better-Than-Nothing
              Security: An Unauthenticated Mode of IPsec", RFC 5386,
              November 2008.





Johansson                Expires January 7, 2010               [Page 13]

Internet-Draft            PK Trust Alternatives                July 2009


Author's Address

   Leif Johansson
   SUNET

   Email: leifj@sunet.se
   URI:   http://www.sunet.se












































Johansson                Expires January 7, 2010               [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/