Network Working Group S. Josefsson
Internet-Draft RSA Security
Expires: August 23, 2002 W. Griffin
NAI Labs
February 22, 2002
Notes on Application Key Distribution
draft-josefsson-siked-framework-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 23, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
The debate over whether to store cryptographic keys used by
applications in the Domain Name System or not has been going on for
some time. There are arguments for and against [6]. This document
tries to take a step further and provides some initial terminology,
problem statement and use cases for storing application keys in DNS,
in order to enable more substantiated input to the discussion. We
mention some proposed solutions so far. We also give some
requirements on a solution (be it DNS based or not) that would
satisfy the use cases.
Josefsson & Griffin Expires August 23, 2002 [Page 1]
Internet-Draft Notes on Application Key Distribution February 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4
4. Applications . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Survey of Proposals . . . . . . . . . . . . . . . . . . . . . 7
7. Requirements on a Solution . . . . . . . . . . . . . . . . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12
Josefsson & Griffin Expires August 23, 2002 [Page 2]
Internet-Draft Notes on Application Key Distribution February 2002
1. 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 [8], the DNSEXT mailing list [9], and the KEYDIST
mailing list [10], regarding (primarily) distributing keys for
Internet applications without additional end-user configuration.
The goal of this draft is not to advocate one single solution.
Instead, the goal is to be a first step towards more well-defined
terminology and a framework in which proposed solutions can be
discussed.
A few suggested proposals are discussed in this document.
We acknowledge that all areas discussed in this document need further
work.
Comments and feedback is requested, preferably to the keydist mailing
list [10].
2. 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 need cryptographic key material. Examples
of applications under considerations are secure IP-based
communication (IPSEC [12], SSH [13]) and secure email (OpenPGP
[4], S/MIME [14]).
A note on "infrastructure" vs "application" is appropriate as
well, as there has been some confusion about calling IPSEC an
"application". IPSEC is often considered "infrastructure", 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 provides 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
Josefsson & Griffin Expires August 23, 2002 [Page 3]
Internet-Draft Notes on Application Key Distribution February 2002
information such as an address to the security gateway.
Note that the format of the keys is not fixed, it ranges from
PKIX certificates to raw RSA public keys.
The reason for including "application" in this term is due the
DNS-centered origins of these discussions. Keys in DNS often
refer to DNSSEC [3] keys which are used by DNS itself.
Applications keys, on the other hand, are used by "applications
of DNS", thus "application keys".
"Application Key Infrastructure"
This is the mechanism that provides application key
distribution. The discussions have so far been centered around
using DNS for this purpose. One solution is to simply store
the application keys within DNS, another is to only store a
pointer in DNS, pointing to where the keys can retrieved. 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 amending 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 secure peer to peer DNS communication using
TSIG [16].
3. Problem Statement
At least the following two problems has been discussed:
"Opportunistic Encryption" or "Zero configuration security"
Certain applications have a need to find cryptographic keying
material for entities which they have no prior arrangement
with. Examples includes IPSEC and secure email. In both cases
the user only know the address of the remote machine or person,
and 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
Josefsson & Griffin Expires August 23, 2002 [Page 4]
Internet-Draft Notes on Application Key Distribution February 2002
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. Other applications have other mechanisms.
The solution to these two problems can be related to DNS. People
ultimately trust names of machines (hostnames) or persons (email
addresses). Making the trust point relate to DNS thus makes sense,
because DNS is used to lookup hostnames and mail servers for email
addresses.
4. Applications
This section discusses how some applications and how they currently
use keys/certificates.
Opportunistic Encryption in IPsec
[17] discusses a protocol for opportunistic encryption in
IPsec. That protocol currently uses a TXT record to store a
Gateway IP address and the public key associated with the
gateway. This TXT record is placed in the reverse map at the
label of the host that is authorizing the gateway to perform
opportunistic IPsec on its behalf.
Opportunistic S/MIME and OpenPGP
S/MIME uses X.509 public key certificates and OpenPGP uses
public key certificates defined by RFC2440. In practice,
S/MIME uses pre-configured CAs in mail readers and OpenPGP
implementations uses web of trust verification possibly aided
by online databases such as pgp.net or keyserver.net. However,
these models are not required by S/MIME or OpenPGP per se, but
this is what is currently deployed.
Secure Shell (SSH)
Secure Shell currently uses a client-side "local database that
associates each host name (as typed by the user) with the
corresponding public host key" [18]. [18] also describes a
heirarchy model of trust, where the clients are configured with
a trusted CA root key, and the "host name-to-key association is
certified by some trusted certification authority."
STIME
[19] defines how NTP uses Public Key Cryptography to
authenticate servers. The protocol assumes, "public encryption
Josefsson & Griffin Expires August 23, 2002 [Page 5]
Internet-Draft Notes on Application Key Distribution February 2002
keys and certificates must be retrievable directly from servers
without requiring secured channels; however, the fundamental
security of identification credentials and public values bound
to those credentials must be a function of external certificate
authorities and/or webs of trust."
5. Use cases
Opportunistic IPSEC
See [17].
Binding Updates for Mobile IP
Assuming DNSSEC is deployed, attaching KEY records for Internet
hosts to achieve secure Binding Updates in Mobile IP is
compelling. It would make it possible for a Mobile Node to
prove that it owns the IP address it claims to do, by providing
a signed statement to a Correspondent Node. The Correspondent
Node would use DNS and DNSSEC to retrieve the hosts' public key
and verify the signed statement. This needs to be combined
with DNS Dynamic Update (authorized by, e.g., a DHCP server) to
allow the Mobile Node to insert its own KEY record into the DNS
space in the visiting network.
Binding Updates for Mobile IP achieved in this manner can be
seen as a special case of Opportunistic IPSEC.
Opportunistic S/MIME and OpenPGP
Storing PGP keys in DNS would be possible using the CERT RR
[5]. 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.
SSH with improved DNS public key verification using [20]:
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
spoofing techniques. When contacting SSH hosts the first time,
instead of receiving:
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)?
Josefsson & Griffin Expires August 23, 2002 [Page 6]
Internet-Draft Notes on Application Key Distribution February 2002
which most users is not able to answer correctly, the SSH host
key is retrieved from DNS, verified using the DNSSEC or TSIG,
and the following question might be presented:
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)?
This enables the user to relate the question to something she
might already trust (the "kth.se" DNS zone). In practice,
administrators will probably configure the SSH client to always
trust certain SSH zone keys and thereby removing the user
interaction completely.
6. Survey of Proposals
"Store application keys in the CERT RR, subtyping for every
applications"
This proposal re-uses the already defined CERT RR, but
clarifies it to be used for non-certificate lookups as well.
Given that the CERT RR allows for PKIX CRLs (which isn't a
certificate), and that from the DNS software's point of view
there is no difference between a certificate and a raw key,
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 proposal may be amended with owner name guidelines, such
as [7] for email applications.
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.
Josefsson & Griffin Expires August 23, 2002 [Page 7]
Internet-Draft Notes on Application Key Distribution February 2002
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.
If raw keys are used, DNSSEC and LDAP over TLS or something
similar is required. If certs are used, plain DNS and LDAP
would work.
However, since there isn't one global PKI, the security offered
by this is not sufficient in general. Consider Alice asking
for Bob's certificate using SRV and LDAP, and receiving a
certificate signed by a CA which Alice does not know or trust.
This model does work well in situations where Alice and Bob
share the same CA or uses cross certified CAs.
"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, or use certificates (this
assumes that involved entities has a trust relationship with a
common CA).
"Define RR for each application"
This pushes everything onto application designers, forcing them
to write the specification. Then this effort would change 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 discussing
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 supported by DNS software directly,
which is unlikely to happen).
Josefsson & Griffin Expires August 23, 2002 [Page 8]
Internet-Draft Notes on Application Key Distribution February 2002
7. Requirements on a Solution
"MUST be possible to locate application keys given only IP address or
hostname, and access to standard Internet infrastructure"
Interpretation: This acknowledge that IP addresses and hostnames are
used to find application keys, not X.400 DN or OpenPGP key IDs. It
also acknowledge that user configuration (of e.g. LDAP servers)
should not be necessary. The mechanism should require "zero
configuration" by the end user.
"MUST be possible to secure locating and retrival of the key"
Interpretation: This could be achieved with DNSSEC, DNS TSIG, or
referral from DNS with a key fingerprint in DNS similar to WPKI [14],
or using CMS [14] or TLS [15] with PKIX certificates [11].
"SHOULD be efficient"
Interpretation: UDP would be an advantage, but this is subject to the
size of keying material. Raw keys might fit into UDP, but
certificates will not in general.
"MUST not create operational problems"
Interpretation: E.g., the DNS system should not have operational
problems resulting from this use.
Acknowledgement
Thanks to members of the Namedroppers, DNSSEC and KEYDIST mailing
list.
References
[1] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC
1034, November 1987.
[2] Mockapetris, P., "Domain Names - Implementation and
Specification", RFC 1035, November 1987.
[3] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[4] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP
Message Format", RFC 2440, November 1998.
[5] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the
Josefsson & Griffin Expires August 23, 2002 [Page 9]
Internet-Draft Notes on Application Key Distribution February 2002
Domain Name System (DNS)", RFC 2538, March 1999.
[6] Lewis, E., "Discussing Application Public Keys in the DNS", I-D
draft-lewis-siked-dnsargs, February 2002.
[7] Schlyter, J., Josefsson, S. and R. Arends, "Storing
certificates in DNS for email applications", I-D draft-
schlyter-mailcert-dns-00.txt, November 2001.
[8] "DNSSEC Mailing List", Email dnssec@cafax.se.
[9] "DNSEXT Mailing List", Email namedroppers@ops.ietf.org.
[10] "KEYDIST Mailing List", Email keydist@cafax.se.
[11] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and CRL Profile", RFC
2459, January 1999.
[12] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[13] "Secure Shell Working Group", WWW
http://www.ietf.org/html.charters/secsh-charter.html.
[14] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999.
[15] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[16] Vixie, P., Gudmundsson, O., Eastlake 3rd, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[17] Richardsson, M., Redelmeier, D. and H. Spencer, "A method for
doing opportunistic encryption with IKE", I-D draft-richardson-
ipsec-opportunistic-02.txt, September 2001.
[18] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S.
Lehtinen, "SSH Protocol Architecture", I-D draft-ietf-secsh-
architecture-12.txt, January 2002.
[19] Mills, D., "Public key Cryptography for the Network Time
Protocol Version 2", I-D draft-ietf-stime-ntpauth-03.txt,
February 2002.
[20] Griffin, W., "Storing SSH Host Keys in DNS", I-D draft-ietf-
Josefsson & Griffin Expires August 23, 2002 [Page 10]
Internet-Draft Notes on Application Key Distribution February 2002
secsh-dns-key-format-00.txt, May 2001.
[21] WAP Forum, "WAP Public Key Infrastructure Definition", WAP 217-
WPKI, April 2001.
Authors' Addresses
Simon Josefsson
RSA Security
Arenavgen 29
Stockholm 121 29
Sweden
Phone: +46 8 7250914
EMail: sjosefsson@rsasecurity.com
Wesley Griffin
NAI Labs
EMail: wgriffin@tislabs.com
Josefsson & Griffin Expires August 23, 2002 [Page 11]
Internet-Draft Notes on Application Key Distribution February 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson & Griffin Expires August 23, 2002 [Page 12]