--- /dev/null
+
+
+Network Working Group L. Daigle
+Internet-Draft A. Newton
+Expires: May 5, 2003 VeriSign, Inc.
+ November 4, 2002
+
+
+ Domain-based Application Service Location Using SRV RRs and the
+ Dynamic Delegation Discovery Service (DDDS)
+ draft-daigle-napstr-01.txt
+
+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 May 5, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2002). All Rights Reserved.
+
+Abstract
+
+ This memo defines a Dynamic Delegation Discovery System (DDDS) [3]
+ Application for domain name based discovery of application services.
+ Essentially, this uses DNS NAPTR resource records [4] to provide one
+ more layer of redirection for service lookup than is feasible with
+ SRV ([2]) records. It is proposed because real-life use is
+ demonstrating a need for something slightly more substantial than
+ SRV, and alternatively SRV usage may become twisted out of its
+ intended shape.
+
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 1]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+1. Introduction
+
+ Increasingly, application protocol standards are using domain names
+ to identify server targets, and stipulating that clients should look
+ up SRV ([2]) resource records to determine the host and port
+ providing the server. This enables a distinction between naming an
+ application service target and actually hosting the server. It also
+ increases flexibility in hosting the target service -- the server may
+ be operated by a completely different organization without having to
+ delegate some portion of the zone, multiple instances can be set up
+ (e.g., for load balancing or secondaries), it can be moved from time
+ to time without disrupting clients' access, etc. This is quite
+ useful, but Section 4 outlines some of the limitations inherent in
+ the approach.
+
+ To address some of the limitations, this document defines a DDDS [3]
+ Application to map service+protocol+domain to specific server
+ addresses using both NAPTR [4] and SRV DNS resource records. This
+ can be viewed as a more general version of the use of SRV and/or a
+ very restricted application of the use of NAPTR resource records.
+
+ That is, while SRV records can be used to map from a specific service
+ name and protocol for a specific domain to a specific server, SRV
+ records are limited to one layer of indirection, and are focused on
+ server administration rather than on application naming. And, while
+ the DDDS specification and use of NAPTR allows multiple levels of
+ redirection before locating the target server machine with an SRV
+ record, this proposal requires only a subset of NAPTR strictly bound
+ to domain names, without making use of the REGEXP field of NAPTR.
+ These restrictions make the client's resolution process much more
+ predictable (prefetchable, cachable) than with some uses of NAPTR
+ records.
+
+ This form of naming indirection (using just SRV records, or DDDS) has
+ implications for application protocols attempting to validate
+ security credentials. This is discussed in Section 6.
+
+ For the purposes of this document:
+
+ o an "application service" is a generic term for some generic type
+ of application, independent of the protocol that may be used to
+ offer it.
+
+ o an "application protocol" is a standard protocol used to
+ implementone or several services
+
+ For example, "e-mail" is an application service; "SMTP" is the
+ protocol that is used to implement it. "Instant Messaging" is an
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 2]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ application service, for which there are several existing and
+ proposed application protocols ("jabber", "simple", etc). "LDAP" is
+ an application protocol which can be used to implement several
+ different application services (e.g., a "whitepages" service,
+ directory enabled networking service, etc).
+
+1.1 What this document means for application protocol developers
+
+ The purpose of this document is to provide application standards
+ developers with a more powerful framework (than SRV RRs alone) for
+ naming service targets, without requiring each application protocol
+ (or service) standard to define a separate DDDS application.
+
+ Note that this approach is intended specifically for use when it
+ makes sense to associate services with particular domain names (e.g.,
+ e-mail addresses, SIP addresses, etc). A non-goal is having all
+ manner of label mapped into domain names in order to use this.
+
+ Specifically not addressed in this document is how to select the
+ domain for which the service+protocol is being sought. It is up to
+ other conventions to define how that might be used (e.g., instant
+ messaging standards can define what domain to use from IM URIs, how
+ to step down from foobar.example.com to example.com, and so on, if
+ that is applicable).
+
+ Although this document proposes a DDDS application that does not use
+ all the features of NAPTR resource records, it does not mean to imply
+ that DNS resolvers should fail to implement all aspects of the NAPTR
+ RR standard. A DDDS application is a client use convention.
+
+2. Basic Proposal
+
+ The precise details of the specification of this DDDS application are
+ given in Appendix A. In general, the proposal is to store
+ application service and protocol descriptions in NAPTR records for
+ individual domains. This will enable domain administrators to
+ provide redirection to other domains that provision individual
+ services, with appropriate weightings and preferences.
+
+ Each "application service" will be associated with an IANA-registered
+ tag. For example, instant messaging is a type of application, which
+ is implemented by many different application-layer protocols, and the
+ tag "IM" (used as an illustration here) could be registered for it.
+
+ An "application protocol" is a standard protocol used to implement
+ the application service (as defined... ??).
+
+ The intention is that the combination of application service and
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 3]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ protocol tags should be specific enough that finding a known pair
+ (e.g., "IM+SIMPLE") is sufficient for a client to identify a server
+ with which it can communicate.
+
+3. Examples
+
+3.1 Instant Messaging Services
+
+ As it stands, there are several different protocols proposed for
+ offering "instant message" services. Assuming that "IM" was
+ registered as an application service, this DDDS application could be
+ used to determine the available services for delivering to a target.
+
+ Two particular features of instant messaging should be noted:
+
+ 1. gatewaying is expected to bridge communications across protocols
+
+ 2. instant messaging servers are likely to be operated out of a
+ different domain than the instant messaging address, and servers
+ of different protocols may be offered by independent
+ organizations
+
+ For example, "thinkingcat.com" may support its own servers for the
+ "apex" instant messaging protocol, but rely on outsourcing from
+ "example.com" for "simple" and "prim" servers.
+
+ Using this DDDS-based approach, thinkingcat.com can indicate a
+ preference ranking for the different types of servers for the instant
+ messaging service, and yet the out-sourcer can independently rank the
+ preference and ordering of servers. This independence is not
+ achievable through the use of SRV records alone.
+
+ Thus, to find the IM services for thinkingcat.com, the NAPTR records
+ for thinkingcat.com are retrieved:
+
+ thinkingcat.com.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "IM+apex" "" _apex._tcp.thinkingcat.com.
+ IN NAPTR 100 20 "s" "IM+prim" "" _prim._tcp.example.com.
+ IN NAPTR 100 30 "s" "IM+simple" "" _simple._tcp.example.com.
+
+ and then the administrators at example.com can manage the preference
+ rankings of the servers they use to support the prim service:
+
+
+
+
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 4]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ _prim._tcp.example.com.
+ ;; Pref Weight Port Target
+ IN SRV 10 0 10001 bigiron.example.com
+ IN SRV 20 0 10001 backup.im.example.com
+ IN SRV 30 0 10001 nuclearfallout.example.com.au
+
+
+3.2 Application Key Storage
+
+ There is growing discussion of having a generic mechanism for
+ locating the keys or certificates associated with particular
+ application (servers) operated in (or for) a particular domain.
+ Here's a hypothetical case for storing Application key or certificate
+ data for a given domain. The premise is that some AppKey service has
+ been defined to be a leaf node service holding the keys/certs for the
+ servers operated by (or for) the domain. This DDDS-based approach is
+ used to find the AppKey server that holds the information.
+
+ thinkingcat.com.
+ ;; order pref flags service regexp replacement
+ IN NAPTR 100 10 "s" "AppKey+LDAP" "" _ldap._tcp.thinkingcat.com
+ IN NAPTR 100 20 "s" "AppKey+LDAP" "" _ldap._tcp.example.com
+
+
+4. So, why not just SRV records?
+
+ An expected question at this point is: this is so similar in
+ structure to SRV records, why are we doing this with DDDS/NAPTR?
+
+ Limitations of SRV include:
+
+ o SRV provides a single layer of indirection -- the outcome of an
+ SRV lookup is a new domain name for which the A RR is to be found.
+
+ o the purpose of SRV is focused on individual server administration,
+ not application naming: as stated in [2] "The SRV RR allows
+ administrators to use several servers for a single domain, to move
+ services from host to host with little fuss, and to designate some
+ hosts as primary servers for a service and others as backups."
+
+ o target servers by "service" (e.g., "ldap") and "protocol" (e.g.,
+ "tcp") in a given domain. The definition of these terms implies
+ specific things (e.g., that protocol should be one of UDP or TCP)
+ without being precise. Restriction to UDP and TCP is insufficient
+ for the uses described here.
+
+ The basic answer is that SRV records provide mappings from protocol
+ names to host and port. The use cases described herein require an
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 5]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ additional layer -- from some service label to servers that may in
+ fact be hosted within different administrative domains. We could
+ tweak SRV to say that the next lookup could be something other than
+ an address record, but that is more complex than is necessary for
+ most applications of SRV.
+
+5. So, why not just NAPTR records?
+
+ That's a trick question. NAPTR records cannot appear in the wild --
+ see [3]. They must be part of a DDDS application.
+
+ The purpose here is to define a single, common mechanism (the DDDS
+ application) to use NAPTR when all that is desired is simple DNS-
+ based location of services. This should be easy for applications to
+ use -- some simple IANA registrations and it's done.
+
+ Also, NAPTR has very powerful tools for expressing "rewrite" rules.
+ That power (==complexity) makes some protocol designers and service
+ administrators nervous. The concern is that it can translate into
+ unintelligle, noodle-like rule sets that are difficult to test and
+ administer.
+
+ This proposed DDDS application specifically uses a subset of NAPTR's
+ abilities. Only "replacement" expressions are allowed, not "regular
+ expressions".
+
+6. Transiting Trust
+
+ One issue to be considered in the use of SRV records in general, and
+ this proposal in particular, is the matter of trusting an end server
+ once resolution of the end server's IP address is completed. This
+ can pose a problem when used with the popular model of trusting an
+ end server in use on the Internet today, TLS. Consider the following
+ example of electronic commerce for which a user must make a trust
+ association to an end server.
+
+ 1. The end-user types into the browser the name of the server, for
+ example "www.thinkingcat.com".
+
+ 2. The server sends to the client its certificate and certificate
+ chain information.
+
+ 3. The client verifies the server's certificate via the certificate
+ chain.
+
+ 4. The client compares the domain name in the server's certificate
+ to the domain name it was given.
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 6]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ 5. The client sends the session key encrypted with the server's
+ public key back to the server.
+
+ 6. If the server is really the server it claims to be, then it will
+ possess the corresponding private key to use in decrypting the
+ session key.
+
+ 7. The server and client communicate using encrypted means via the
+ session key.
+
+ However, the necessity for the client to compare the domain it was
+ given with the domain name found in the certificate (step 4) can be
+ problematic when the name resolution process changes the domain name
+ being sought. This problem can be solved using one of the two
+ methods outlined below. For full transition of trust using TLS, each
+ method requires the use of DNSSEC [1] to insure the SRV and NAPTR
+ records have not been compromised. Neither method requires any
+ change to either the TLS or DNSSEC protocols.
+
+6.1 Using the Translated Name
+
+ The first method is a simple modification of the client's use of the
+ domain name in comparison with the name present in the certificate.
+ The following is a modification of the process outlined above.
+
+ 1. The end-user types into the client application the name of the
+ server. For this example, the client application is a PRIM
+ client and the name of the server is "thinkingcat.com".
+
+ 2. During the name resolution process for the PRIM service of
+ "thinkingcat.com", the NAPTR record will yield the name
+ "_prim._tcp.example.com". The client must remember "example.com"
+ (i.e., the label without the SRV-style service and protocol
+ portions) as the translated name.
+
+ 3. The server, bigiron.example.com, sends to the client its
+ certificate for "example.com" and certificate chain information.
+
+ 4. The client verifies the server's certificate via the certificate
+ chain.
+
+ 5. The client compares the translated name from the resolution
+ process, "example.com", with the name found in the certificate,
+ "example.com".
+
+ 6. The client sends the session key encrypted with the server's
+ public key back to the server.
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 7]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ 7. If the server is really one of the servers for
+ "_prim._tcp.example.com", then it will possess the corresponding
+ private key to use in decrypting the session key.
+
+ 8. The server and client communicate using encrypted means via the
+ session key.
+
+ Note that the translated name is taken from the NAPTR record and not
+ the SRV record. This is done because the use-case is such that the
+ user is interested in the PRIM service for "thinkingcat.com" and not
+ the particular server where it is hosted.
+
+ Note also that this requires that the operator of the service must
+ have the certificate for the service's domain. This may cause
+ problems when the final server is operated in a different realm of
+ administrative control (for example, if it is outsourced to an ISP).
+
+6.2 Trusting the DNS Signer
+
+ Due to the fact that DNSSEC must already be used to trust this name
+ resolution process, another method is to simply use the certificate
+ chain for the certificate that is present in DNS. The following
+ steps illustrate this process.
+
+ 1. The end-user types into the PRIM application the name
+ "thinkingcat.com".
+
+ 2. The final outcome of the name resolution process will yield an A
+ record containing the IP address for "bigiron.example.com".
+
+ 3. The server sends to the client its certificate. The certificate
+ chain for this certificate leads to the signer for the A record
+ (the certificate is signed using the same private key as the A
+ record).
+
+ 4. The client verifies the server's certificate using the same
+ public key of the A record for "bigiron.example.com".
+
+ 5. The client sends the session key encrypted with the server's
+ public key back to the server.
+
+ 6. If the server is really bigiron.example.com, then it will possess
+ the corresponding private key to use in decrypting the session
+ key.
+
+ 7. The server and client communicate using encrypted means via the
+ session key.
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 8]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ The key premise in this case is that DNSSEC ensures the resolution
+ yields trustable data in naming the final target server, and
+ therefore only that server's named certificate must be validated
+ (against the same chain of trust) in order to trust the server
+ itself. This approach does not require that the final server have a
+ certificate for the named service, and it works for NAPTR, NAPTR+SRV,
+ or just SRV name redirection.
+
+7. IANA Considerations
+
+ ?? Fill out with specifics for registering "application service" tags
+ (and "application protocols", if this is something other than the
+ existing port registry).
+
+8. Security Considerations
+
+ This is primarily addressed in the "Transiting Trust" section,Section
+ 6.
+
+9. Acknowledgements
+
+ Many thanks to Patrik Faltstrom and Sally Floyd for discussion and
+ input that has (hopefully!) provoked clarifying revisions of this
+ document.
+
+References
+
+ [1] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [2] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
+ specifying the location of services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ One: The Comprehe nsive DDDS", RFC 3401, October 2002.
+
+ [4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ Three: The Domain Name System (DNS) Database", RFC 3403, October
+ 2002.
+
+ [5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
+ Four: The Uniform Resource Identifiers (URI)", RFC 3404, October
+ 2002.
+
+
+
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 9]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+Authors' Addresses
+
+ Leslie Daigle
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ EMail: leslie@verisignlabs.com; leslie@thinkingcat.com
+
+
+ Andrew Newton
+ VeriSign, Inc.
+ 21355 Ridgetop Circle
+ Dulles, VA 20166
+ US
+
+ EMail: anewton@verisignlabs.com
+
+Appendix A. Application Service Location Application of DDDS
+
+ This section defines the DDDS application, as described in [3].
+
+A.1 Application Unique String
+
+ The Application Unique String is the name of the domain in which an
+ authoritative server for a particular service is sought.
+
+A.2 First Well Known Rule
+
+ The "First Well Known Rule" is identity -- that is, the output of the
+ rule is the Application Unique String, the domain for which the
+ authoritative server for a particular service is sought.
+
+A.3 Expected Output
+
+ The expected output of this Application is the information necessary
+ to connect to authoritative server(s) (host, port, protocol) for an
+ application service within a given a given domain.
+
+A.4 Flags
+
+ This DDDS Application uses only 3 of the Flags defined for the
+ URI/URN Resolution Application ([5]): "S", "A" and "U". No other
+ Flags are valid.
+
+ All three are for terminal lookups. This means that the Rule is the
+ last one and that the flag determines what the next stage should be.
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 10]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ The "S" flag means that the output of this Rule is a domain label for
+ which one or more SRV [2] records exist. "A" means that the output
+ of the Rule is a domain name and should be used to lookup address
+ records for that domain. "U" means that the output of the Rule is a
+ URI which should be resolved.
+
+A.5 Service Parameters
+
+ Service Parameters for this Application take the form of a string of
+ characters that follow this ABNF ([3]):
+
+ service-parms = [ [app-service] *("+" app-protocol)]
+ app-service = ALPHA *31ALPHANUM
+ app-protocol = ALPHA *31ALPHANUM
+ ; 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.
+
+A.5.1 Application Services
+
+ The "app-service" must be a registered service [this will be an IANA
+ registry; this is not the IANA port registry, because we want to
+ define services for which there is no single protocol, and we don't
+ want to use up port space for nothing].
+
+A.5.2 Application Protocols
+
+ The protocol identifiers that are valid for the "app-protocol"
+ production are any standard, registered protocols [IANA registry
+ again -- is this the list of well known/registered ports?].
+
+A.6 Valid Rules
+
+ Only substitution Rules are permitted for this application. That is,
+ no regular expressions are allowed.
+
+A.7 Valid Databases
+
+ At present only one DDDS Database is specified for this Application.
+ [4] specifies a DDDS Database that uses the NAPTR DNS resource record
+ to contain the rewrite rules. The Keys for this database are encoded
+ as domain-names.
+
+ The First Well Known Rule produces a domain name, and this is the Key
+ that is used for the first lookup -- the NAPTR records for that
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 11]
+\f
+Internet-Draft draft-daigle-napstr-01 November 2002
+
+
+ domain are requested.
+
+ DNS servers MAY interpret Flag values and use that information to
+ include appropriate NAPTR, SRV or A records in the Additional
+ Information portion of the DNS packet. Clients are encouraged to
+ check for additional information but are not required to do so. See
+ the Additional Information Processing section of [4] for more
+ information on NAPTR records and the Additional Information section
+ of a DNS response packet.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 12]
+\f
+Internet-Draft draft-daigle-napstr-01 November 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Newton Expires May 5, 2003 [Page 13]
+\f
Network Working Group R. Arends
Internet-Draft
-Expires: April 14, 2003 M. Kosters
+Expires: May 2, 2003 M. Kosters
D. Blacka
Verisign, Inc.
- October 14, 2002
+ November 1, 2002
DNSSEC Opt-In
- draft-ietf-dnsext-dnssec-opt-in-03
+ draft-ietf-dnsext-dnssec-opt-in-04
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on April 14, 2003.
+ This Internet-Draft will expire on May 2, 2003.
Copyright Notice
-Arends, et al. Expires April 14, 2003 [Page 1]
+Arends, et al. Expires May 2, 2003 [Page 1]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
Table of Contents
-Arends, et al. Expires April 14, 2003 [Page 2]
+Arends, et al. Expires May 2, 2003 [Page 2]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
1. Definitions and Terminology
delegation: refers to a NS RRset with a name different from the
current zone apex (non-zone-apex), signifying a delegation to a
- subzone. A delegation returned in a DNS response is also called a
- "referral".
+ subzone.
secure delegation: refers to the NS, DS, NXT and SIG RRsets for a
non-zone-apex owner name, signifying a delegation to a DNSSEC
-Arends, et al. Expires April 14, 2003 [Page 3]
+
+Arends, et al. Expires May 2, 2003 [Page 3]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
2. Overview
The cost to cryptographically secure delegations to unsigned zones is
high for large delegation-centric zones and zones where insecure
delegations will be updated rapidly. For these zones, the costs of
- maintaining the NXT record chain may not be relative to the gain of
- cryptographically securing delegations to unsigned zones.
+ maintaining the NXT record chain may be extremely high relative to
+ the gain of cryptographically authenticating existence of unsecured
+ zones.
This document describes a method of eliminating the superfluous
cryptography present in secure delegations to insecure zones. Using
-
-Arends, et al. Expires April 14, 2003 [Page 4]
+Arends, et al. Expires May 2, 2003 [Page 4]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
3. Protocol Additions
Since the NXT bit in the type map merely indicates the existence of
the record itself, this bit is redundant and safe for use as a tag.
- Using Opt-In, the existence or non-existence of insecure delegations
- is not asserted by the tagged NXT records. This allows for the
- addition or removal of delegations to unsigned zones without
- recalculating and resigning the NXT chain. However, Opt-In NXT
- records still assert the (non)existence of signed RRsets.
+ An Opt-In tagged NXT record does not assert the (non)existence of the
+ delegations that it covers. This allows for the addition or removal
+ of these delegations without recalculating the resigning the NXT
+ chain. However, Opt-In tagged NXT records do assert the
+ (non)existence of other signed RRsets.
Zones using Opt-In MAY contain a mixture of Opt-In tagged NXT records
and RFC 2535 NXT records. If a NXT record is not Opt-In, there MUST
-Arends, et al. Expires April 14, 2003 [Page 5]
+Arends, et al. Expires May 2, 2003 [Page 5]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
the same owner name.
records to prove the non-existence of an applicable wildcard in non-
existent name responses. This NXT record can be described as a
"negative wildcard proof". The use of Opt-In NXT records changes the
- necessity for this practice. For both non-existent name (NXDOMAIN)
- responses and Opt-In insecure delegation responses, servers MUST NOT
- return negative wildcard proof records when the query name (qname) is
- covered by an Opt-In tagged NXT record.
+ necessity for this practice. For non-existent name (NXDOMAIN)
+ responses when the query name (qname) is covered by an Opt-In tagged
+ NXT record, servers MUST NOT return negative wildcard proof records.
The intent of the RFC 2535 negative wildcard proof requirement is to
prevent malicious users from undetectably removing valid wildcard
-Arends, et al. Expires April 14, 2003 [Page 6]
+
+Arends, et al. Expires May 2, 2003 [Page 6]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
However, if the NXT record covering the exact qname is an Opt-In NXT
-Arends, et al. Expires April 14, 2003 [Page 7]
+Arends, et al. Expires May 2, 2003 [Page 7]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
o Using Opt-In, the security status is proven by the existence of a
The AD bit, as defined by [8], MUST NOT be set when:
o sending a non-existent name (NXDOMAIN) response where the covering
- NXT is tagged as Opt-In, unless the NXT record's owner name equals
- the qname.
+ NXT is tagged as Opt-In.
o sending an Opt-In insecure delegation response, unless the
covering (Opt-In) NXT record's owner name equals the delegation
-Arends, et al. Expires April 14, 2003 [Page 8]
+
+Arends, et al. Expires May 2, 2003 [Page 8]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
4. Benefits
-Arends, et al. Expires April 14, 2003 [Page 9]
+Arends, et al. Expires May 2, 2003 [Page 9]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
5. Example
-Arends, et al. Expires April 14, 2003 [Page 10]
+Arends, et al. Expires May 2, 2003 [Page 10]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE. A
-Arends, et al. Expires April 14, 2003 [Page 11]
+Arends, et al. Expires May 2, 2003 [Page 11]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
6. Transition Issues
-Arends, et al. Expires April 14, 2003 [Page 12]
+Arends, et al. Expires May 2, 2003 [Page 12]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
7. Security Considerations
-Arends, et al. Expires April 14, 2003 [Page 13]
+Arends, et al. Expires May 2, 2003 [Page 13]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
8. IANA Considerations
-Arends, et al. Expires April 14, 2003 [Page 14]
+Arends, et al. Expires May 2, 2003 [Page 14]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
9. Acknowledgments
(in alphabetic order) to this draft are acknowledged:
Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
- Kolkman, Ted Lindgreen, Bill Manning, Dan Massey, Scott Rose, Mike
- Schiraldi, Jakob Schlyter, Brian Wellington.
-
+ Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
+ Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
+ Wellington.
-Arends, et al. Expires April 14, 2003 [Page 15]
+Arends, et al. Expires May 2, 2003 [Page 15]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
References
-Arends, et al. Expires April 14, 2003 [Page 16]
+Arends, et al. Expires May 2, 2003 [Page 16]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
David Blacka
-Arends, et al. Expires April 14, 2003 [Page 17]
+Arends, et al. Expires May 2, 2003 [Page 17]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
Appendix A. Implementing Opt-In using "Views"
-Arends, et al. Expires April 14, 2003 [Page 18]
+Arends, et al. Expires May 2, 2003 [Page 18]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
-Arends, et al. Expires April 14, 2003 [Page 19]
+Arends, et al. Expires May 2, 2003 [Page 19]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
Appendix B. Changes from Prior Versions
+ Changes from version 03:
+
+ Editorial changes for clarification only.
+
Changes from version 02:
Added text on changes to validation process, use of the AD bit,
-
-
-
-
-Arends, et al. Expires April 14, 2003 [Page 20]
+Arends, et al. Expires May 2, 2003 [Page 20]
\f
-Internet-Draft DNSSEC Opt-In October 2002
+Internet-Draft DNSSEC Opt-In November 2002
Full Copyright Statement
-Arends, et al. Expires April 14, 2003 [Page 21]
+Arends, et al. Expires May 2, 2003 [Page 21]
\f
+
+
Network Working Group M. Duerst
-Internet-Draft W3C/Keio University
-Expires: December 30, 2002 July 1, 2002
+Internet-Draft W3C
+Expires: May 4, 2003 November 3, 2002
Internationalized Domain Names in URIs
- draft-ietf-idn-uri-02
+ draft-ietf-idn-uri-03
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on December 30, 2002.
+ This Internet-Draft will expire on May 4, 2003.
Copyright Notice
-Duerst Expires December 30, 2002 [Page 1]
-\f
-Internet-Draft IDNs in URIs July 2002
+Duerst Expires May 4, 2003 [Page 1]
+Internet-Draft IDNs in URIs November 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. URI syntax changes . . . . . . . . . . . . . . . . . . . . . . 3
3. Security considerations . . . . . . . . . . . . . . . . . . . 5
- 4. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
- 4.1 Changes from draft-ietf-idn-uri--01 to draft-ietf-idn-uri-02 . 5
- 4.2 Changes from draft-ietf-idn-uri--00 to draft-ietf-idn-uri-01 . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03 . 5
+ 5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02 . 5
+ 5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01 . 5
+ References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
-
-
-Duerst Expires December 30, 2002 [Page 2]
-\f
-Internet-Draft IDNs in URIs July 2002
+Duerst Expires May 4, 2003 [Page 2]
+Internet-Draft IDNs in URIs November 2002
1. Introduction
syntax, and defines how internationalized domain names are encoded in
URIs.
- The syntax in this document has been choosen to further increase the
+ The syntax in this document has been chosen to further increase the
uniformity of URI syntax, which is a very important principle of
URIs.
- In practice, escaped domanin names should be used as rarely as
+ In practice, escaped domain names should be used as rarely as
possible. Wherever possible, the actual characters in
Internationalized Domain Names should be preserved as long as
possible by using IRIs [IRI] rather than URIs, and only converting to
URIs and then to ACE-encoded [IDNA] domain names (or ideally directly
to ACE-encoding without even using URIs) when resolving the IRI.
- Also, this document does in no way exclude the use of ACE encoding
- directly in an URI domain name part. ACE encoding may be used
- directly in an URI domain name part if this is considered necessary
- for interoperability.
+ Also, this document does not exclude the use of ACE encoding directly
+ in an URI domain name part. ACE encoding may be used directly in an
+ URI domain name part if this is considered necessary for
+ interoperability.
Please note that even with the definition of URIs in [RFC2396], some
URIs can already contain host names with escaped characters. For
-Duerst Expires December 30, 2002 [Page 3]
-\f
-Internet-Draft IDNs in URIs July 2002
+Duerst Expires May 4, 2003 [Page 3]
+Internet-Draft IDNs in URIs November 2002
The later two rules are changed as follows:
and the following rules are added:
- anchar = alphanum | escaped
- achar = alpha | escaped
+ anchar = alphanum | escaped
+ achar = alpha | escaped
Characters outside the repertoire (alphanum) are encoded by first
encoding the characters in UTF-8 [RFC 2279], resulting in a sequence
The above syntax rules permit for domain names that are neither
permitted as US-ASCII only domain names nor as internationalized
- domain names. However, such syntax should never be used, and will
- always be rejected by resolvers. For US-ASCII only domain names, the
- syntax rules in [RFC2396] are relevant. For example, http://
- www.w%33.org is legal, because the corresponding 'w3' is a legal
- 'domainlabel' according to [RFC2396]. However, http://
- %2a.example.org is illegal because the corresponding '*' is not a
- legal 'domainlabel' according to [RFC2396]. For domain names
- containing non-ASCII characters, the legal domain names are those for
- which the ToASCII operation ([IDNA], [Nameprep]; using the unescaped
- UTF-8 values as input) is successful.
+ domain names. However, such domain names should never be used, and
+ will never be resolved because no such domains will be registered.
+ For US-ASCII only domain names, the syntax rules in [RFC2396] are
+ relevant. For example, http://www.w%33.org is legal, because the
+ corresponding 'w3' is a legal 'domainlabel' according to [RFC2396].
+ However, http://%2a.example.org is illegal because the corresponding
+ '*' is not a legal 'domainlabel' according to [RFC2396].
- For consistency in comparison operations and for interoperability
- with older software, the following should be noted: 1) US-ASCII
- characters in domain names should not be escaped. 2) Because of the
- principle of syntax uniformity for URIs, it is always more prudent to
- take into account the possibility that US-ASCII characters are
- escaped.
+ For domain names containing non-ASCII characters, the legal domain
+ names are those for which the ToASCII operation ([IDNA], [Nameprep];
+ using the unescaped UTF-8 values as input), with the flags
+ "UseSTD3ASCIIRules" and "AllowUnassigned" set, is successful. The
+ URI resolver MUST apply any steps required as part of domain name
+ resolution by [IDNA], in particular the ToASCII operation, with the
+ above-mentioned flags set. URIs where the ToASCII operation results
+ in an error should be treated as unresolvable.
- The work of the IDN WG includes some procedures for name preparation
- [Nameprep]. Before encoding an internationalized domain name in an
- URI, this preparation step SHOULD be applied. However, the URI
- resolver MUST also apply any steps required as part of domain name
- resolution by [IDNA].
+ For domain names containing non-ASCII characters, the Nameprep
+ specification ([Nameprep]) defines some mappings, which mainly
+ include normalization to NFKC and folding to lower case. When
+ encoding an internationalized domain name in an URI, these mappings
+ SHOULD NOT be applied. It should be assumed that the domain name is
+ already normalized as far as appropriate.
-Duerst Expires December 30, 2002 [Page 4]
-\f
-Internet-Draft IDNs in URIs July 2002
+Duerst Expires May 4, 2003 [Page 4]
+Internet-Draft IDNs in URIs November 2002
+ For consistency in comparison operations and for interoperability
+ with older software, the following should be noted: 1) US-ASCII
+ characters in domain names should not be escaped. 2) Because of the
+ principle of syntax uniformity for URIs, it is always more prudent to
+ take into account the possibility that US-ASCII characters are
+ escaped.
+
3. Security considerations
The security considerations of [RFC2396] and those applying to
firewalls, although because of the uniform syntax principle for URIs,
such a potential is already existing.
-4. Change Log
+4. Acknowledgements
+
+ Erik Nordmark
+
+5. Change Log
-4.1 Changes from draft-ietf-idn-uri--01 to draft-ietf-idn-uri-02
+5.1 Changes from draft-ietf-idn-uri-02 to draft-ietf-idn-uri-03
+
+ Clarified expectations on name checking.
+
+5.2 Changes from draft-ietf-idn-uri-01 to draft-ietf-idn-uri-02
Moved change log to back
Gave example of mailto: as already allowing escaped host names.
-4.2 Changes from draft-ietf-idn-uri--00 to draft-ietf-idn-uri-01
+ Corrected some typos.
+
+5.3 Changes from draft-ietf-idn-uri-00 to draft-ietf-idn-uri-01
Changed requirement for URI/IRI resolvers from MUST to SHOULD
Changed IRI syntax slightly (ichar -> idchar, based on changes in
[IRI])
+
+
+Duerst Expires May 4, 2003 [Page 5]
+Internet-Draft IDNs in URIs November 2002
+
+
Various wording changes
References
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
- draft-ietf-idn-idna-09.txt (work in progress), May 2002,
- <http://www.ietf.org/internet-drafts/draft-ietf-idn-idna-
- 09.txt>.
+ draft-ietf-idn-idna-14.txt (work in progress), October
+ 2002, <http://www.ietf.org/internet-drafts/draft-ietf-
+ idn-idna-14.txt>.
[IDNWG] "IETF Internationalized Domain Name (idn) Working Group".
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource
- Identifiers (IRI)", draft-duerst-iri-01 (work in
- progress), July 2002.
-
-
-
-
-Duerst Expires December 30, 2002 [Page 5]
-\f
-Internet-Draft IDNs in URIs July 2002
-
+ Identifiers (IRI)", draft-duerst-iri-02.txt (work in
+ progress), November 2002, <http://www.ietf.org/internet-
+ drafts/draft-duerst-iri-02.txt>.
[ISO10646] International Organization for Standardization,
"Information Technology - Universal Multiple-Octet Coded
[Nameprep] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep
Profile for Internationalized Domain Names", draft-ietf-
- idn-nameprep-10.txt (work in progress), May 2002, <http:/
- /www.ietf.org/internet-drafts/draft-ietf-idn-nameprep-
- 10.txt>.
+ idn-nameprep-11.txt (work in progress), June 2002,
+ <http://www.ietf.org/internet-drafts/draft-ietf-idn-
+ nameprep-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
August 1998.
[RFC2640] Curtin, B., "Internationalization of the File Transfer
+
+
+
+Duerst Expires May 4, 2003 [Page 6]
+Internet-Draft IDNs in URIs November 2002
+
+
Protocol", RFC 2640, July 1999.
[RFC2718] Masinter, L., Alvestrand, H., Zigmond, D. and R. Petke,
1999.
-
-
-
-
-
-
-
-
-
-Duerst Expires December 30, 2002 [Page 6]
-\f
-Internet-Draft IDNs in URIs July 2002
-
-
Author's Address
Martin Duerst
- W3C/Keio University
- 5322 Endo
- Fujisawa 252-8520
- Japan
+ World Wide Web Consortium
+ 200 Technology Square
+ Cambridge, MA 02139
+ U.S.A.
- Phone: +81 466 49 1170
- Fax: +81 466 49 1171
+ Phone: +1 617 253 5509
+ Fax: +1 617 258 5999
EMail: duerst@w3.org
URI: http://www.w3.org/People/D%C3%BCrst/
-
-
-
-
-
-
-
-
-
-
-
-Duerst Expires December 30, 2002 [Page 7]
-\f
-Internet-Draft IDNs in URIs July 2002
+Duerst Expires May 4, 2003 [Page 7]
+Internet-Draft IDNs in URIs November 2002
Full Copyright Statement
-Duerst Expires December 30, 2002 [Page 8]
-\f
-
+Duerst Expires May 4, 2003 [Page 8]
-
-
Secure Shell Working Group J. Schlyter
Internet-Draft Carlstedt Research &
-Expires: February 10, 2003 Technology
+Expires: May 4, 2003 Technology
W. Griffin
Network Associates Laboratories
- August 12, 2002
+ November 3, 2002
Using DNS to securely publish SSH key fingerprints
- draft-ietf-secsh-dns-00.txt
+ draft-ietf-secsh-dns-01.txt
Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
- This Internet-Draft will expire on February 10, 2003.
+ This Internet-Draft will expire on May 4, 2003.
Copyright Notice
-Schlyter & Griffin Expires February 10, 2003 [Page 1]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Schlyter & Griffin Expires May 4, 2003 [Page 1]
+
+Internet-Draft DNS and SSH fingerprints November 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. SSH Host Key Verification . . . . . . . . . . . . . . . . . 3
2.1 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
- 2.2 Fingerprint matching . . . . . . . . . . . . . . . . . . . . 3
- 2.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2.2 Implementation notes . . . . . . . . . . . . . . . . . . . . 3
+ 2.3 Fingerprint matching . . . . . . . . . . . . . . . . . . . . 4
+ 2.4 Authentication . . . . . . . . . . . . . . . . . . . . . . . 4
3. The SSHFP resource record . . . . . . . . . . . . . . . . . 4
3.1 The SSHFP RDATA format . . . . . . . . . . . . . . . . . . . 4
3.1.1 Algorithm number specification . . . . . . . . . . . . . . . 4
- 3.1.2 Fingerprint type specification . . . . . . . . . . . . . . . 4
+ 3.1.2 Fingerprint type specification . . . . . . . . . . . . . . . 5
3.1.3 Fingerprint . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Presentation format of the SSHFP RR . . . . . . . . . . . . 5
4. Security considerations . . . . . . . . . . . . . . . . . . 5
- 4.1 Backend transport integrity . . . . . . . . . . . . . . . . 5
- 4.2 Effects on the SSH trust model . . . . . . . . . . . . . . . 5
- 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 5
- References . . . . . . . . . . . . . . . . . . . . . . . . . 6
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7
- A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
- Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
+ 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 6
+ References . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8
+ A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . 9
+
-Schlyter & Griffin Expires February 10, 2003 [Page 2]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Schlyter & Griffin Expires May 4, 2003 [Page 2]
+
+Internet-Draft DNS and SSH fingerprints November 2002
1. Introduction
algorithm and fingerprint of the key received from the SSH server
matches the algorithm and fingerprint of one of the SSHFP resource
record(s) returned from DNS, the client MAY accept the identity of
- the server. It is RECOMMENDED that the client ask the user for
- confirmation before accepting the identity of the server.
+ the server.
-2.2 Fingerprint matching
+2.2 Implementation notes
- The public key and the SSHFP resource record are matched together by
- comparing algorithm number and fingerprint.
+ Client implementors SHOULD to provide a configurable policy used to
+ select the order of methods used to verify a host key and which
+ fingerprints to trust ultimately, after user confirmation or not at
+ all.
-2.3 Authentication
- A public key verified using this method MUST only be trusted if the
-Schlyter & Griffin Expires February 10, 2003 [Page 3]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Schlyter & Griffin Expires May 4, 2003 [Page 3]
+
+Internet-Draft DNS and SSH fingerprints November 2002
+
+
+2.3 Fingerprint matching
+
+ The public key and the SSHFP resource record are matched together by
+ comparing algorithm number and fingerprint.
+
+2.4 Authentication
+ A public key verified using this method MUST only be trusted if the
SSHFP RR used for verification was authenticated by a trusted SIG RR.
Clients that do not validate the DNSSEC signatures themselves MUST
This algorithm number octet describes the algorithm of the public
key. The following values are assigned:
+
+
+
+
+
+
+
+Schlyter & Griffin Expires May 4, 2003 [Page 4]
+
+Internet-Draft DNS and SSH fingerprints November 2002
+
+
Value Algorithm name
----- --------------
0 reserved
The fingerprint type octet describes the message-digest algorithm
used to calculate the fingerprint of the public key. The following
-
-
-
-Schlyter & Griffin Expires February 10, 2003 [Page 4]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
-
-
values are assigned:
Value Fingerprint type
4. Security considerations
-4.1 Backend transport integrity
+ Currently, the amount of trust a user can realistically place in a
+ server key is proportional to the amount of attention paid to
+ verifying that the key presented is actually the key at the server.
+ If a user accepts a key without verifying the fingerprint with
+ something learned through a secured channel, the connection is
+ vulnerable to a man-in-the-middle attack.
+
+ The approach suggested here shifts the burden of key checking from
+ each user of a machine to the key checking performed by the
+
+
+
+Schlyter & Griffin Expires May 4, 2003 [Page 5]
+
+Internet-Draft DNS and SSH fingerprints November 2002
+
+
+ administrator of the DNS recursive server used to resolve the host
+ information. Hopefully, by reducing the number of times that keys
+ need to be verified by hand, each verification is performed more
+ completely. Furthermore, by requiring an administrator do the
+ checking, the result may be more reliable than placing this task in
+ the hands of an application user.
+
+ The overall security of using SSHFP for SSH host key verification is
+ dependent on detailed aspects of how verification is done in SSH
+ implementations. One such aspect is in which order fingerprints are
+ looked up (e.g. first checking local file and then SSHFP). We note
+ that in addition to protecting the first-time transfer of host keys,
+ SSHFP can optionally be used for stronger host key protection.
+
+ If SSHFP is checked first, new SSH host keys may be distributed by
+ replacing the corresponding SSHFP in DNS.
+
+ If SSH host key verification can be configured to require SSHFP,
+ we can implement SSH host key revocation by removing the
+ corresponding SSHFP from DNS.
+
+ As stated in Section 2.2, we recommend that SSH implementors provide
+ a policy mechanism to control the order of methods used for host key
+ verification.
+
+ Another dependency is on the implementation of DNSSEC itself. As
+ stated in Section 2.4, we mandate the use of secure methods for
+ lookup and that SSHFP RRs are authenticated by trusted SIG RRs. This
+ is especially important if SSHFP is to be used as a basis for host
+ key rollover and/or revocation, as described above.
Since DNSSEC only protects the integrity of the host key fingerprint
after it is signed by the DNS zone administrator, the fingerprint
- must be transfered securely from the SSH host administrator to the
+ must be transferred securely from the SSH host administrator to the
DNS zone administrator. This could be done manually between the
administrators or automatically using secure DNS dynamic update [8]
- between the SSH server and the nameserver.
-
-4.2 Effects on the SSH trust model
-
- ... to be written ...
+ between the SSH server and the nameserver. We note that this is no
+ different from other key enrollment situations, e.g. a client
+ sending a certificate request to a certificate authority for signing.
5. IANA considerations
IANA needs to allocate a RR type code for SSHFP from the standard RR
- type space.
+ type space (type 44 requested).
IANA needs to open a new registry for the SSHFP RR type for public
key algorithms. Defined types are:
-Schlyter & Griffin Expires February 10, 2003 [Page 5]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Schlyter & Griffin Expires May 4, 2003 [Page 6]
+
+Internet-Draft DNS and SSH fingerprints November 2002
0 is reserved
[9] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T J. and S.
Lehtinen, "SSH Transport Layer Protocol", work in progress
- draft-ietf-secsh-architecture-12.txt, March 2002.
+ draft-ietf-secsh-architecture-13.txt, September 2002.
[10] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T J. and S.
Lehtinen, "SSH Transport Layer Protocol", work in progress
- draft-ietf-secsh-transport-14.txt, March 2002.
+ draft-ietf-secsh-transport-15.txt, September 2002.
+
+Schlyter & Griffin Expires May 4, 2003 [Page 7]
-Schlyter & Griffin Expires February 10, 2003 [Page 6]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Internet-Draft DNS and SSH fingerprints November 2002
Authors' Addresses
The authors gratefully acknowledges, in no particular order, the
contributions of the following persons:
- Bill Sommerfeld
+ Martin Fredriksson
Olafur Gudmundsson
Edward Lewis
+ Bill Sommerfeld
+Schlyter & Griffin Expires May 4, 2003 [Page 8]
-Schlyter & Griffin Expires February 10, 2003 [Page 7]
-\f
-Internet-Draft DNS and SSH fingerprints August 2002
+Internet-Draft DNS and SSH fingerprints November 2002
Full Copyright Statement
-Schlyter & Griffin Expires February 10, 2003 [Page 8]
-\f
+Schlyter & Griffin Expires May 4, 2003 [Page 9]
+
+
projects / thirdparty / bind9.git / commitdiff
