Internet Draft Richard Shockey Peter C. Davis Document: draft-shockey-ddds-pki-00.txt NeuStar, Inc. Expires: April 2002 October 2002 Use of the DDDS System for Cryptographic Key Discovery and Retrieval draft-shockey-ddds-pki-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. 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 RFC-2119 [KEYWORDS]. Abstract Expires û April 2003 [Page 1] October 2002 This document discusses the use of the Dynamic Delegation Discovery System [RFC 3401-6] for the discovery and retrieval of application specific cryptographic objects. This is a work in progress. Comments are welcome on the following mail list. keydist@cfax.se To subscribe to this list send a message to keydist- request@cafax.se With subscribe in the body. Table of Contents 1. Introduction...................................................2 2. REQUIREMENTS FOR APPLICATION SPECIFIC PUBLIC KEY INFRASTRUCTURE. (NEEDS WORK)......................................................4 3. CURRENT USE OF DDDS AND NAPTR RECORDS..........................4 3.1 CURRENT EXAMPLE: ENUM [RFC2916BIS].........................6 3.2 CURRENT EXAMPLE SIP SERVER LOCATION- [RFC 3263]............7 4. POSSIBLE USES OF DDDS IN DISCOVERY AND RETRIEVAL OF PKI MATERIAL8 4.1 POSSIBLE USE: FINDING X.509 CERTIFICATES ASSOCIATED WITH A FULLY QUALIFIED DOMAIN NAME....................................8 4.2 POSSIBLE USE: S/MIME PK'S IN SMTP..........................9 4.3 PGP KEYS IN SMTP..........................................11 5. SIP, S/MIME AND MEDIA SECURITY................................11 6. Other Possible Uses...........................................13 6.1 IPSEC û TBD Larger issue Is IPSEC an application or a infrastructure issue..........................................13 6.2 UDDI Registers............................................13 7. Security Considerations.......................................13 8. References....................................................13 Acknowledgments..................................................14 Author's Addresses...............................................14 1. Introduction Considerable discussion has occurred within the IETF on the question of how or should applications use the DNS to store and retrieve a variety of cryptographic and security related objects. Discussion has centered on the desire to separate the management of the Public Key Infrastructure required for the internal security of the DNS [DNSSEC] vs. those that keys may be needed by specific applications such as S/MIME. Expires û April 2003 [Page 2] October 2002 Actions by the DNS Extensions WG in bringing forward for Proposed Standard "Limiting the Scope of the KEY Resource Record" [RESTRICT-KEY] potentially signal a consensus in the IETF that applications SHOULD NOT directly use the DNS for the storage of application specific keys. Recently a Birds of Feather meeting was held at IETF 53 in Minneapolis on the subject of how applications should store keys [SIKED]. No consensus was reached but several approaches were outlined. [LEWIS- SIKED], [JOSEFSSON-SIKED], [DAIGLE-NAPSTR] There is a growing need for the discovery and retrieval of key material in what has been referred to as "opportunistic encryption" environments. Opportunistic encryption is defined as secure communications between individuals on endpoints without any prior arrangement or knowledge of the existence of the parties before secure communications is established. A more substantial argument in favor of placing application specific keys and security objects outside the DNS infrastructure is that typically DNS queries use UDP, however since most security keys or digital certificates are large objects, which would require the use of TCP, this then places a larger burden on the DNS infrastructure that in the opinion of some observers is ônot a good thingö. The problem of DNS infrastructure over load is well known. [Randy Bush horses and saddlebags URI?] The concept of a new DNS Resource Record for applications to store public keys in was presented in [APPKEY]. DDDS offers a similar but more flexible and definable infrastructure not only for keys but other forms of cryptographic material, such as certificates by referencing to pointers through a DDDS infrastructure and not storing those keys or security material directly in the DNS. In addition DDDS offers within the NAPTR RR structure a service- parameter field that can be flexibly constructed to contain detailed data about the nature and type of security object referenced. This document outlines several examples on how the Dynamic Delegation Discovery System [RFC 3401-6] is currently used now and how DDDS could be used by specific applications to discover key material. Expires û April 2003 [Page 3] October 2002 It is recommended that readers of this document first familiarize themselves with the core DDDS documents [RFC 3401-6] . 2. REQUIREMENTS FOR APPLICATION SPECIFIC PUBLIC KEY INFRASTRUCTURE. (NEEDS WORK) A. Keys and other cryptographic materials should be stored in trusted locations other than in the DNS itself or the reverse DNS directory (IN-ADDR.ARPA ûIPV6.ARPA) B. Pointers to keys or other similar material SHOULD be flexible enough to permit descriptive parameters of the nature and application use of the key. Specifically a. Application Usage b. Key Type c. Key Type Version d. Key Length C. Multiple applications should be able to store information about keys associated with a single globally unique identifier such as a URI, SMPT address, FQDN etc. 3. CURRENT USE OF DDDS AND NAPTR RECORDS DDDS is a general purpose system for the retrieval of information based on an application specific input string and applying well known rules to transform that string until a terminal condition is reached requiring a look up into a application specific defined database or execution of a URL based on the application defined rules. DDDS defines a specific type of definable DNS Resource Record, NAPTR records, for the storage in the DNS of information necessary to apply DDDS rules. The Generic Definition of DDDS can be described as follows (adapted from [DAIGEL-SIKED]) A. Application Unique String The Application Unique String is the globally unique name for an endpoint authoritative for a particular service sought. B. First Well Known Rule Expires û April 2003 [Page 4] October 2002 The "First Well Known Rule" is the construct of an application specific sequence of transformations for which the identity or location for an authoritative server for a particular service is sought. C. Expected Output The expected output of the DDDS application transformation is the information necessary to connect to authoritative server(s) (host, port, protocol) for an application service within a given a given domain. D. Flags DDDS flags defines the scope of the transformation. Currently two flags are defined for DDDS applications Application.("S" and "A"). Both "S" and "A" are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The ôUö flag means that the output of the rule is a URL. The "S" flag means that the output of this Rule is a domain name for which one or more SRV records exist. The "A" flag means that the output of the Rule is a domain name and should be used to lookup address records for that domain. E. Services Parameters Service Parameters for DDDS can take the form of a string of characters that follow an ABNF syntax: service-parms =[ [app-service] *("+" app-protocol)] app-service = 1*32(ALPHA / DIGIT) app-protocol = token *[":" token ":" token] token = 1*32(ALPHA / DIGIT) The app-service and app-protocol fields are limited to 32 characters and must start with an alphabetic character. Thus, the Service Parameters may consist of an empty string, just an app-service, or an app-service with one or more app-protocol specifications separated by the "+" symbol. F. Application Services Expires û April 2003 [Page 5] October 2002 The "app-service" must be a registered service, in an IANA defined registry. G. Application Protocols The protocol identifiers that are valid for the "app-protocol" production are any standard, registered protocols. H. Valid Databases At present only the DNS as a valid DDDS Database has been specified in IETF protocols. [RFC 3403] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are can be encoded as domain-names. The DDDS system requires ach application wishing to use DDDS defines its application, application unique input string, rules for transformation, list of valid databases and expected final output in an RFC. Currently two IETF protocols use DDDS and NAPTR RR records for the retrieval of application specific data. ENUM [RFC 2916] and SIP - Locating SIP Servers [RFC 3263]. These applications should be considered as valid examples of DDDS in use today. 3.1 CURRENT EXAMPLE: ENUM [RFC2916BIS] RFC 2916bis takes as its input string a fully qualified E.164 telephone number and by applying well known rules, creates a Fully Qualified Domain Name which is then used to execute a lookup into the DNS for services associated with that phone number defined as NAPTR records [RFC 2915/DDDS2]. Example: A. Application Unique String = +4689761234 B. First Well Know Rule 1. Remove all characters with the exception of the digits this step would simply remove the leading "+", producing "4689761234" Expires û April 2003 [Page 6] October 2002 2. Put dots (".") between each digit. Example: 4.6.8.9.7.6.1.2.3.4 3. Reverse the order of the digits. Example: 4.3.2.1.6.7.9.8.6.4 4. Append the string ".e164.arpa" to the end. Example: 4.3.2.1.6.7.9.8.6.4.e164.arpa C. Query DNS In this example the database is DNS and the query uses the FQDN to discover the services associated with this E.164 number expressed as NAPTR Resource Records. Response from the DNS: $ORIGIN 4.3.2.1.6.7.9.8.6.4.e164.arpa. order pref flags enumservice regexp IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:info@network.foo!" . IN NAPTR 102 10 "u" "E2U+smpt" "!^.*$!mailto:info@domain.bar!" . Of particular note the NATRR flag "u" is defined as that the end result of the transformation is a URI and the service field has been defined by [RFC2916bis] through a enumservice field specific ABNF syntax defined as: service_field = "E2U" 1*("+" enum-service) enum-service = token *[":" token ":" token] token = 1*32(ALPHA / DIGIT) Where tokens represent various capabilities, descriptions or protocols supported an endpoint. 3.2 CURRENT EXAMPLE SIP SERVER LOCATION- [RFC 3263] RFC 3262 defines how SIP applications can discover the various aspects of SIP proxies in other domains. The use of DDDS by SIP is noteworthy since SIP, unlike many other protocols can run over different transport protocols, consequently is it necessary to discover and select the Expires û April 2003 [Page 7] October 2002 appropriate servers that can support those protocols before a communications session can be established. Example: Input String [URI] = sip:calledparty@example.bar First Well-known rule: A. Decompose SIP URI to find SIP domain. B. Query DNS Response from the DNS for NAPTR records in the domain example.bar ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" _sips._tcp.example.bar. IN NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.bar. IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.bar. The flag "s" is defined as the transformation of the replacement field into a further look up for SRV records. This example indicates that the domain supports TLS over TCP, TCP, and UDP, in that order of preference. 4. POSSIBLE USES OF DDDS IN DISCOVERY AND RETRIEVAL OF PKI MATERIAL DDDS offer the opportunity for a much more varied and definable infrastructure for PKI than other proposals. 4.1 POSSIBLE USE: FINDING X.509 CERTIFICATES ASSOCIATED WITH A FULLY QUALIFIED DOMAIN NAME Though the IETF has defined a Resource Record for the storage of certificates, RFC 2538 it is conceivable that different applications will have different requirements for certificates and that multiple Certificate Authorities (CA) will need to reference their certs to a single FQDN. Example: Input string [FQDN] = foobar.example.biz Response from the DNS: Expires û April 2003 [Page 8] October 2002 order pref flags service regexp IN NAPTR 100 10 "u" "5092U+di:http:s:" "!^.*$!http:pkidata.example.foo!". IN NAPTR 102 10 "u" "5092U+appfoo:ldap:" "!^.*$!ldap:pkdata1.example.bar!" . Where "di" might represent a digital identity application and ôappfooö is something else A general ABNF construct for 509 specific service fields could similar to the one used in ENUM. service_field = "5092U" 1*("+" certservice) certservice = application *[":" label ":" label ":" label] label = 1*32(ALPHA / DIGIT) The label construct of the cert-service field could contain various descriptive elements of the capabilities and character of the certificate to be retrieved such as signed or unsigned, transport mechanism. TBD .. What labels are appropriate for 509 certificates? 4.2 POSSIBLE USE: S/MIME PK'S IN SMTP The IETF has developed the S/MIME specification to permit the encryption of MIME type objects. There has been considerable interest in use of this technology in encrypting SMPT messages. The following example describes a possible way DDDS could be used to discover and retrieve PK's from an intended recipients PK repository without any prior knowledge of the recipient Public Key Infrastructure. Example Bob wishes to send secure email to Alice. Bob knows Alice's email address. Bob's mail user agent uses the email address as the input string for a DDDS query to the DNS to obtain Alice's public key. Example: A. Input String [SMTP address] = alice@example.us C. First Well Known Rule = Expires û April 2003 [Page 9] October 2002 a. Take the SMPT address and decompose it into the user part and the domain. b. Perform a DNS query requesting all NAPTR records the domain [ example.foo ] c. Search response from DNS NAPTR pkservice field records for available PK repositories supported Response from the DNS: order pref flags service regexp replacement IN NAPTR 100 10 "n" "PK2U+smime:pkcs7:https" "" ôpkinfo.example.bar/[input]ö. IN NAPTR 90 10 "n" "PK2U+smime:pkcs7:ldaps" "" ôpkinfo2.example.bar/[input]ö. d. Perform a transformation of the hostname and transport type required. e. Apply user part of the input string to the input portion of the regular expression to f. Construct the appropriate URL from the transport portion of the PK service field In this example the flag "n" is defined as the transformation of the replacement field is non-terminal and requires an additional substitution of the username "recipient" into the [input] field of the replacement the preference as well as a rewrite into a URL based on the transport in the pkservice field. One possible ABNF construct of the pkservice field could be: service_field = "PK2U" 1*("+" pkservice) pkservice = application *[":" type ":" transport ":" label] type = 1*32(ALPHA / DIGIT) transport = 1*32(ALPHA / DIGIT) label = 1*32(ALPHA / DIGIT) The final output to retrieve the pkcs7 key for alice@example.us would be: https://pkinfo.example.bar/alice Alternatively the output result should LDAP transport be selected would be Expires û April 2003 [Page 10] October 2002 ldaps://pkinfo2.example.bar// (what the heck would the string look like since I'm no LDAP guru) 4.3 PGP KEYS IN SMTP PGP uses its own infrastructure to distribute keys in trusted circles, however most PGP key exchange is out of band. A. Input String [SMTP address] = bob@example.us B. First Well Known Rule = a. Take the SMPT address and decompose it into the user part and the domain. b. Perform a DNS query requesting all NAPTR records the domain [example.us] c. Search response from DNS NAPTR pkservice field records for available PK repositories supported Response from the DNS: order pref flags service regexp replacement IN NAPTR 100 10 "n" "PK2U+pgp:rsa-x:https" "" ôpkinfo.example.foo/[input]ö. IN NAPTR 90 10 "n" "PK2U+pgp:rsax:ldaps" "" ôpkinfo2.example.foo/[input]ö. Where the application type in the pkservice field is now ôpgpö and the key type is ôrsa-xö denoting a form or RSA key and perhaps key size. Questions ..is the following examples an appropriate use of the replacement field outlined in RFC 3401-6???? 5. SIP, S/MIME AND MEDIA SECURITY SIP [RFC3261] recommends the usage of S/MIME to protect the bodies of SIP requests. Many forms of sensitive information can appear in SIP message bodies, including the Session Description Protocol [RFC 2327] and even instant messages.In order to encrypt such bodies before transmitting a SIP message, one must know the public key of the intended recipient of the request. There are a number of reasons why encrypting SDP is desirable. If arbitrary third-parties can inspect SDP, they may learn the IP addresses and ports used for media by endpoints that are participating in a SIP Expires û April 2003 [Page 11] October 2002 session, and may use this knowledge to attempt attacks such as eavesdropping on session media or denying service by flooding these resources. Also, several proposals have been made to carry session keys used for encrypting media traffic within SDP or in other SIP bodies. S/MIME can secure SDP in order to prevent these session keys from being learned by potential eavesdroppers. While S/MIME keys can be exchanged in SIP as described in RFC 3261, this method is only secure if the keys are contained in a certificate that has been issued by an authority recognized by the participants in the SIP dialog. Exchange of self-signed certificates or unsigned public keys would be vulnerable to a man-in-the-middle attack. The DNS provides one way that the public key of the destination could be ascertained before an initial SIP request is sent, one that potentially has a higher degree of security than the exchange of self-signed certificates in SIP. The Request-URI of a SIP request could be resolved via the DNS to discover a NAPTR record specific to the user in question. Note that the SIP specificationÆs mechanism for locating SIP servers [RFC3263] already entails support for NAPTR records (as do popular SIP applications such as ENUM). As an example, given a Request-URI of æsip:joe@example.fooÆ, when the NAPTR RRs for æexample.fooÆ are returned, they might contain the following: order pref flags service regexp IN NAPTR 100 10 "u" "5092U+di:sip:http:" "!^joe(.*)$!https:pkidata.example.foo!" . Once this NAPTR record has been received by the client, it can make a secure HTTP connection to pkidata.example.foo in order to download the key for joe. Once the key has been learned, it can be used to apply security properties to the body of the first SIP request sent to joe. This sort of access to public keys is most secure when the keys are distributed within certificates. Otherwise, the host from the which the public key is downloaded (in the example above, pkidata.example.foo) must have some other reference integrity with the URI that the originator is attempting to reach. For example, if the originator is attempting to reach æsip:joe@example.fooÆ, the host from which the key is downloaded must be in the domain of æexample.fooÆ. In order for this Expires û April 2003 [Page 12] October 2002 process to be secure, both DNSSEC and strong security on the HTTP download (such as TLS, which is prescribed by the HTTPS URI scheme) are necessary. 6. Other Possible Uses 6.1 IPSEC û TBD Larger issue Is IPSEC an application or a infrastructure issue. 6.2 UDDI Registers UDDI is an emerging technology for the discovery of services associated with a business or enterprise. There has been some suggestion that DNS TXT files could be used to discovery of UDDI directories. DDDS offers a more robust and flexible method for the discovery of these servers. Input String: business.biz Response to query in DNS for NAPTR records for business.biz: order pref flags service regexp IN NAPTR 100 10 "u" "UDDI2U+https" ô!^.*$!https://business.biz/commerce/WebServDir!" . IN NAPTR 100 10 "u" "UDDI2U+ldaps" ô!^.*$!ldaps:uddiweb.business.biz!" . 7. Security Considerations No unique security considerations are associated with application specific PKI using DDDS or NAPTR records over and above those already associated with the DNS infrastructure itself. Well-known attacks, such as man-in-the-middle are possible against any of these examples in the absence of DNSSEC and other methods. Attack against the security object servers themselves is also possible. A variety of security issues are involved in multiple roundtrips for the discovery of data. TBD 8. References Expires û April 2003 [Page 13] October 2002 [RFC 2916bis] Faltstrom,P.and Mealling,M. ôThe E.164 to URI DDDS Applicationsö,draft-ietf-enum-rfc2916bis-01.txt, (work in progress), May 2002 [RFC 3263] Rosenberg,J.and Schulzrinne,H., ôSession Initiation Protocol (SIP) : Locating SIP Serversö, RFC 3263, June 2002 [SIKED] Secure Internet Key Distribution BOF (siked) Agenda IETF 53; http://www.ietf.org/mail-archive/ietf- announce/Current/msg17495.html [LEWIS-SIKED] Lewis,E. ôDiscussing Application Public Keys in the DNSö, http://www.ietf.org/internet-drafts/draft-lewis-siked- dnsargs-00.txt (work in progress), February 2002 [DAIGEL-SIKED] Daigel,L.and Newton,A., ôNAPSTR: A constrained use of NAPTR and SRV RRs for domain-based service locationö, http://www.ietf.org/internet-drafts/draft-daigle-napstr- 00.txt,(work-in-progress),Feburary 2002 [JOSEFSSON-SIKED] Josefsson,S.and Griffin,W., ôNotes on Application Key Distributionö, http://www.ietf.org/internet-drafts/draft- josefsson-siked-framework-00.txt (work in progress),Feburary 2002 [APPKEY] Schlyter,J., ôStoring application public keys in the DNSö, draft-schlyter-appkey-02.txt (work in progress) Feburary 2002 [RFC 3401-6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) RFC 3401-6 inclusive, October 2002. [KEYWORDS] Bradner,S., "KEY WORDS FOR USE IN RFCS TO INDICATE REQUIREMENT LEVELS", RFC 2119, March 1997. [RESTRICT-KEY] Massey,D.and Rose,S., ôLimiting the Scope of the KEY Resource Recordö, draft-ietf-dnsext-restrict-key-for-dnssec-04.txt (work in progress), September 2002 Acknowledgments The author(s) gratefully acknowledges the comments and suggestions of Jon Peterson on issues involving S/MIME and SIP and William Sylvester both of NeuStar. That said, the numerous errors and omissions in this document are the sole responsibility author(s) Shockey in particular. Author's Addresses Expires û April 2003 [Page 14] October 2002 Richard Shockey NeuStar, Inc. 4600 Center Oak Plaza Sterling, VA 20166 US Phone: + 1 571.434.5651 EMail: richard.shockey@neustar.biz http://www.neustar.biz/ Peter C Davis NeuStar, Inc. 4600 Center Oak Plaza Sterling, VA 20166 US Phone: + 1 571.434.5516 EMail: peter.davis@neustar.biz http://www.neustar.biz/ 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. Expires û April 2003 [Page 15] October 2002 Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Expires û April 2003 [Page 16]