Internet DRAFT - draft-dukhovni-using-wildcard-a-rrsets

draft-dukhovni-using-wildcard-a-rrsets






Network Working Group                                        V. Dukhovni
Internet-Draft
Intended status: BCP                                    N. Williams, Ed.
Expires: April 30, 2015                                     Cryptonector
                                                        October 27, 2014


Using Wildcard A and AAAA Resource Records in the DNS for Per-User Host-
                             Based Services
               draft-dukhovni-using-wildcard-a-rrsets-01

Abstract

   This document describes how the use of wildcard A and AAAA resource
   records (RRs) in the Domain Name System (DNS), optionally coupled
   with self-service key management for host names that match the
   wildcards, to create per-user services.  This memo describes what
   should be a best current practice.

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 April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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
   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



Dukhovni & Williams      Expires April 30, 2015                 [Page 1]

Internet-Draft            Using Wildcard A RRs              October 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.      Wildcard A/AAAA RRs in DNS for Per-User Host-Based
           Services (PUHBSs) . . . . . . . . . . . . . . . . . . . . . 3
   2.      Conventions used in this document . . . . . . . . . . . . . 3
   3.      Provisioning of Service Credentials, or Self-Service
           Key Management  . . . . . . . . . . . . . . . . . . . . . . 3
   3.1.    Requirements and Recommendations  . . . . . . . . . . . . . 4
   3.2.    Sample Use Case: per-User Web Services  . . . . . . . . . . 5
   4.      Security Considerations . . . . . . . . . . . . . . . . . . 5
   4.1.    Man-in-the-Middle Attacks by Local Users  . . . . . . . . . 5
   4.1.1.  Security Considerations for Per-User HTTP Services  . . . . 6
   5.      IANA Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.      References  . . . . . . . . . . . . . . . . . . . . . . . . 6
   6.1.    Normative References  . . . . . . . . . . . . . . . . . . . 6
   6.2.    Informative References  . . . . . . . . . . . . . . . . . . 6
           Authors' Addresses  . . . . . . . . . . . . . . . . . . . . 7






























Dukhovni & Williams      Expires April 30, 2015                 [Page 2]

Internet-Draft            Using Wildcard A RRs              October 2014


1.  Wildcard A/AAAA RRs in DNS for Per-User Host-Based Services (PUHBSs)

   Often users need to run services (often on multi-user systems) that
   need host-based service principal names.  We describe a method for
   arranging this without having to share sensitive cryptographic host
   credentials with users:

   1.  Publish in the DNS [RFC1034] [RFC1035] a wildcard A and/or AAAA
       RRset for every hostname on which self-service per-user services
       will be permitted.

       This means that for any host named, say, "foo.bar.example", one
       would publish "*.foo.bar.example.", with the same A and/or AAAA
       RRset as "foo.bar.example.".

   2.  Provision users with credentials for host-based service names on
       hostnames of the form: <username>.<hostname.fqdn>.

   This allows users to publish "<username>.<hostname-FQDN>" as their
   services' hostname.

   For the rest of this document we shorten "per-user host-based service
   principal" to "PUHBSP".

   And that's it.  The difficult part, of course, is (2), but it is
   possible to adjust existing provisioning systems and/or build new
   ones to address this.  See Section 3


2.  Conventions used in this document

   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 [RFC2119].


3.  Provisioning of Service Credentials, or Self-Service Key Management

   Existing standard and non-standard Kerberos [RFC4120] administration
   and PKIX [RFC5280] online certification authority (CA) protocols may
   be used for self-service key management of PUHBSP credentials with
   minimal changes.  The main change that is needed is an authorization
   change on the server-side.

   Example protocols whose services may be modified to suit this
   purpose:





Dukhovni & Williams      Expires April 30, 2015                 [Page 3]

Internet-Draft            Using Wildcard A RRs              October 2014


   o  The "Microsoft Windows 2000 Kerberos Change Password and Set
      Password Protocols" [RFC3244] and its non-standard predecessors.
   o  The various other non-standard Kerberos administration protocols
      that provide interfaces for creating principals and setting their
      credentials.  For example:
      *  <http://oskt.secure-endpoints.com/krb5_admin.html>
      *  <http://www.eyrie.org/~eagle/software/wallet/>
      *  and others.
   o  kx509 [RFC6717] (a kerberized online CA).
   o  Any protocol using PKCS#10 [RFC2986].

   The principle is general, applying to any authentication mechanism
   that can authenticate host-based services, not just Kerberos or PKIX.

3.1.  Requirements and Recommendations

   Three different sorts of authorization decisions are involved:

   1.  DNS zone administrators decide which hosts get wildcard A/AAAA
       RRsets.

       DNS zone administrators MAY safely publish wildcard A and AAAA
       RRsets for all hostnames in their zones, but they may also keep a
       white-list of such hostnames.

   2.  The PUHBSP's credential issuer MUST decide whether to issue
       credentials for any given sub-domain of a given hostname.

       This decision MUST be based on and constrained by the requestor's
       credentials.  For example, the issuer might require that a client
       authenticate with a user and a host-based service credential or
       that a user have opted-in any given host whose credentials will
       be used to acquire the PUHBSP's credentials, it might require
       that the username label of the PUHBSP correspond to an existing
       user, and so on.

       Credential issuers SHOULD NOT issue PUHBSP credentials for
       hostnames with more than one sub-domain label of the actual
       host's hostname.

   3.  Hosts themselves SHOULD authorize local requests by local users/
       processes for credentials for any given sub-domain of the host's
       hostname.

   For example, a host might authenticate local users using traditional
   operating system facilities (e.g., processes' credentials), then
   decide whether the local user gets to have a requested sub-domain of
   the host's hostname.



Dukhovni & Williams      Expires April 30, 2015                 [Page 4]

Internet-Draft            Using Wildcard A RRs              October 2014


3.2.  Sample Use Case: per-User Web Services

   In our deployment it is trivial for users to run their own web
   services:

   o  pick an available port number,
   o  locally request credentials (server certificates and/or Kerberos
      keys) for running a web service on "<local-username>.<hostname-
      fqdn>:<port>" (for example,
      https://jdoe.someserver.foo.example:3000/),
   o  configure the web service to start on the chosen port number and
      with the given credentials,
   o  then start the service.

   In this use case no credential acquisition protocols were modified.
   Instead their services were modified to permit clients with host-
   based service credentials to acquire credentials for PUHBSPs whose
   hostname component is a sub-domain of the actual host's.


4.  Security Considerations

   Some hostnames may be meaningful (e.g., "irc.foo.bar.example" might
   be taken to mean that an IRC [RFC2812] server is located at that
   hostname).  Users may need to be educated as to how to determine that
   a fully-qualified hostname is a per-user one.

   Credential issuers SHOULD keep white-lists of users and hostnames
   that are permitted to have PUHBSPs, though not necessarily white-
   lists of {username, hostname} that are permitted to have PUHBSPs.

   Self-service key management services for PKIX [RFC5280] SHOULD use an
   intermediate, online certification authority (CA), rather than a top-
   level CA, so as to make it possible to revoke the online CA's
   certificate.  (This is good advice for any CA anyways.)

   Note that this scheme does not support users from more than one realm
   having PUHBSPs on the same host.

4.1.  Man-in-the-Middle Attacks by Local Users

   Note that a large number of port numbers for running services are
   available to all users on most operating systems.  This means that a
   local user could start a proxy on one port and forward to another
   port on the same host, where the second port is a service run by a
   different user.  Mutual authentication generally protects against
   this attack.




Dukhovni & Williams      Expires April 30, 2015                 [Page 5]

Internet-Draft            Using Wildcard A RRs              October 2014


4.1.1.  Security Considerations for Per-User HTTP Services

   Hypertext Transfer Protocol (HTTP) [RFC2616] used with the SPNEGO-
   based [RFC4178] HTTP authentication method [RFC4559] is quite common
   in some environments.  Negotiate does not make use of session keys to
   protect HTTP data and metadata.  To safeguard against this, per-user
   HTTP services MUST use Transport Layer Security (TLS) [RFC5246], not
   just SPNEGO.


5.  IANA Considerations

   There are no IANA considerations in this document.


6.  References

6.1.  Normative References

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

6.2.  Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2812]  Kalt, C., "Internet Relay Chat: Client Protocol",
              RFC 2812, April 2000.

   [RFC2986]  Nystrom, M. and B. Kaliski, "PKCS #10: Certification
              Request Syntax Specification Version 1.7", RFC 2986,
              November 2000.

   [RFC3244]  Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows
              2000 Kerberos Change Password and Set Password Protocols",
              RFC 3244, February 2002.

   [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
              Kerberos Network Authentication Service (V5)", RFC 4120,
              July 2005.



Dukhovni & Williams      Expires April 30, 2015                 [Page 6]

Internet-Draft            Using Wildcard A RRs              October 2014


   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
              Simple and Protected Generic Security Service Application
              Program Interface (GSS-API) Negotiation Mechanism",
              RFC 4178, October 2005.

   [RFC4559]  Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
              Kerberos and NTLM HTTP Authentication in Microsoft
              Windows", RFC 4559, June 2006.

   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC6717]  Hotz, H. and R. Allbery, "kx509 Kerberized Certificate
              Issuance Protocol in Use in 2012", RFC 6717, August 2012.


Authors' Addresses

   Viktor Dukhovni

   Email: ietf-dane@dukhovni.org


   Nicolas Williams (editor)
   Cryptonector, LLC

   Email: nico@cryptonector.com



















Dukhovni & Williams      Expires April 30, 2015                 [Page 7]