Re: looking for draft volunteers

[Simon Josefsson <simon+keydist@josefsson.org>]

On Thu, 10 Jan 2002, Edward Lewis wrote:

> I think that a draft summarizing the arguements on being exhibited on the
> "From whence we came" thread would be important document.

I agree.  I found five minutes and put together the text below.  I
probably missed half of what has been discussed here, and I can't write
english, and it isn't even in IETF draft format.  But at least it wastes
bandwidth. ;-)




		Notes on Application Key Distribution

- Introduction

The intention of this draft is to document some of the discussions
that have taken place on a number of mailing lists, including the
DNSSEC mailing list [1], the DNSEXT mailing list [2], and the KEYDIST
mailing list [3].

The goal of this draft is not to advocate one single solution.
Instead, the goal is to document a more well-defined framework in
which several solutions have been suggested, and to briefly discuss
the merits of a couple of suggested solutions.

Since the discussions have been lacking an agreed upon terminology,
problem statement and requirements, we also try to discuss these.
However, we admit that these areas need further work.  This draft does
not claim to reflect all views that have been expressed, and is thus
inconclusive.  Comments and feedback is requested.

- Terminology

  "Application" or "Internet Application"

	Network software that uses Domain names or IP addresses to
	communicate with other entities.  To operate securely, these
	applications usually needs cryptographic key material.
	Examples of applications under considerations are secure
	IP-based communication (IPSEC [4], SSH [5]) and secure email
	(OpenPGP [6], S/MIME [7]).

	A note on "infrastructure" vs "application" is appropriate as
	well.  IPSEC is often considered as "infrastructure" instead
	of an application, and applications are something you build on
	top of IPSEC.  However, from the point of view of looking up
	keys for use with IPSEC, IPSEC behaves like all other clients
	to the "lookup keys" system.  Hence, we consider the system
	that provide lookup and retrieval of application keys the
	"infrastructure" and all clients of this infrastructure are
	"applications".  From this point of view, IPSEC is an
	application.

   "Application Keys"

        The piece of information an application needs to establish
        secure communication with an entity.  This usually includes
        cryptographic (public) keys, but may also include other
        information such as an address to the security gateway.

	Note that the format of the keys is not fixed, it ranges from
	PKIX certificates, over PKIX CRLs [8] to raw RSA public keys
	[9].

	The reason for including "application" in this term is due the
	DNS-centered origins of these discussions.  Keys in DNS often
	refer to DNSSEC [10] keys which are used by DNS itself.
	Applications keys, on the other hand, are used by
	"applications of DNS", thus "application keys".

   "Infrastructure"

	The mechanism that provides application key distribution.  The
	discussions have so far been centered around using DNS for
	this purpose, either by storing the keys within DNS itself or
	storing a pointer to the where the keys can located within
	DNS.  The rationale behind this is that DNS provides name to
	address mapping on the Internet, and most applications need to
	find keys based on such names.  Involving DNS is natural,
	unless one aims at replacing or ammending the DNS name space.

	Note that the infrastructure is in general not assumed to be
	secured.  That is, e.g., DNSSEC is not assumed to be deployed.
	However, some problems and use cases may assume partial or
	full deployment of DNSSEC.  Also, some problems and use cases
	may assume usage of TSIG [11].

- Problem Statement

  Several problems have been stated:

  "Opportunistic Encryption" or "Global application key distribution"

  Certain applications have a need to find cryptographic keying
  material for entities which they have no prior arrangement with.
  Examples includes IPSEC, but also secure email.  In both situation
  you only know the address of the remote machine or person, and you
  need to locate and retrieve the keying material for this entity.

  "Campus-based application key distribution"

  Secure remote machine administration requires that keys are
  distributed somehow.  Mechanisms used by, e.g., SSH include
  retrieving the key from the remote machine and asking the user if
  she wants to trust it or not (including a fingerprint of the key for
  verification purposes), and later store the keys in a local file.

  "Inter-campus application key distribution"

  This is when two campus wants to communicate seceurely (via
  e.g. SSH), and similar to the previous proposal.  The difference is
  that they do not trust the communication to the DNS servers, so this
  must be protected by e.g. TSIG.  This requires exchange of TSIG keys
  between the two campus.

- Use cases

  Opportunistic IPSEC [12]

  OpenPGP

       Storing PGP keys in DNS would be possible using the CERT RR
       [10].  The naming standard used could be the suggested one (SOA
       translation of email address), or based on the PGP KeyId, e.g.,
       0x47114711.dnskeys.net.

  Two use cases for SSH has been presented, both could use the
  proposal on how to store SSH keys in DNS defined in [13]:

      In SSH, I have a host at my home institution named "beagle."
      When I go to the IETF, I carry beagle's SSH host key configured
      in my client.  But while I am away, beagle crashes and is down
      for some time.  But since my home institution uses NIS, I could
      log into "retriever" with the same name and password and still
      get to my home directory.  The problem is that I don't have
      retriever's SSH host key configured because I didn't cover my
      bases in the event of a crash on beagle.

      How do I make SSH's "trust" robust in the light of beagle's
      crash?

  The second use case for SSH:

      A campus runs SSH and either DNSSEC or TSIG (clients configured
      with DNSSEC key or TSIG key) to protect from people that plug in
      their laptops and tries to gain unauthorized access using
      sniffers, spoofing or whatever.  When contacting SSH hosts the
      first time, instead of getting

      The authenticity of host 'cc (195.42.214.244)' can't be established.
      RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
      Are you sure you want to continue connecting (yes/no)? 

      which basicly asks the user if she wants to shoot herself in the
      foot or not (I'm assuming not even 5% checks the fingerprint
      before typing 'yes' here, which probably is optimistic), the SSH
      host key is retrieved from DNS, verified using the DNSSEC or
      TSIG, and you get this question instead:

      The host key of 'cc (195.42.214.244)' authenticated by DNSSEC root 'kth.se'.
      RSA key fingerprint is 6b:9a:84:7b:1c:8f:a2:7c:51:e9:2a:a4:04:86:6d:b2.
      Are you sure you want to continue connecting (yes/no)? 

      which is alot better.  Users or administrators might even want
      to configure their SSH client to always trust SSH host keys
      which can be chained back to a certain DNSSEC root (e.g., the
      university DNSSEC key).

Survey of Proposals

  "Store application keys in the CERT RR, subtyping for every applications"

      This proposal re-uses the already defined CERT RR, but wants to
      make it clear that also non-certificate looking application keys
      is valid.  Given that the CERT RR allows for PKIX CRLs, this
      interpretation have some bearing in the specification.

      This would not require any changes to DNS software.  It would
      make it easy for applications that support more than one format
      of applications keys, e.g. both raw key and X.509 certificate.

      This may be ammended with owner name guidelines.

      For certificates, no additional security infrastructure is
      required, for raw keys DNSSEC, TSIG or similar is required.

  "Use APPKEY for raw keys and CERT for certificates, subtyping for
  every application"

      This is similar to the previous, but that it separates raw keys
      from certificate like formats.

      This has the same advantages and disadvantages than the previous
      proposal, but it does add complexity in case software supports
      both raw keys and certificates.  It also requires that DNS
      administrators and DNS software knows if a certain blob is a key
      or certificate when storing it in DNS.

      All APPKEYs must be protected with DNSSEC, TSIG or similar.  All
      CERT RR do not in principle require DNSSEC, TSIG or similar but
      may benefit from it.

   "Store referral in DNS, retrieve keys via other protocols"

      This is possible now using, e.g., SRV and LDAP.

      Requires LDAP over TLS or similar.

   "Store referral with fingerprint in DNS, retrieve keys via other
   protocols"

      This is similar to the previous proposal, but it makes it
      possible to chose the security infrastructure that should be
      used.  Either leverage on DNSSEC, TSIG or similar, or protect
      the other protocol with, e.g., TLS.

   "Define RR for each application"

      This pushes everything onto application designers, forcing them
      to write the specification. This effort changes into simply
      giving recommendations on how to write such specifications.

      Security-wise it gives total flexibility, however each
      application need to write a document similar to this deciding if
      they need raw keys, certificates etc, and if they will store the
      key or certificate in DNS or use a separate protocol.  It also
      requires that DNS software handles unknown RRs correctly (or
      that all new RRs are implemented, which is unlikely to happen).

Requirements on a Solution

  "MUST be possible to locate application keys given only IP address
  or hostname"

  "MUST be possible to secure locating and retrival of the key"

  Interpretation: Either via DNSSEC, TSIG, or referral from DNS with a
  key fingerprint in DNS similar to WPKI [14], CMS [7], TLS [15] or
  something completely different.

  "SHOULD be efficient"

  Interpretation: UDP would be an advantage.

  "MUST not create operational problems"

  Interpretation: DNS should not go kablonk.

[1] dnssec@cafax.se

[2] namedroppers@ops.ietf.org

[3] keydist@cafax.se

[4] RFC 2401

[5] http://www.ietf.org/html.charters/secsh-charter.html

[6] RFC 2440

[7] RFC 2630-2633

[8] RFC 2459

[9] See SSH [5]

[10] RFC 2535

[11] RFC 2845

[12] draft-richardson-ipsec-opportunistic-04.txt

[13] draft-ietf-secsh-dns-key-format-00.txt

[14] WAP Forum, WPKI. http://www.wapforum.org/

[15] RFC 2246

[16] draft-schlyter-pkix-dns-00.txt

[17] draft-josefsson-pkix-dns-00.txt