Internet Draft Douglas Otis Category: Standards Track Mail Abuse Prevention System draft-dougotis-srv-caa-00.txt May 2004 Expires: December 2004 DNS Extension for SRV-Client Address Authorization (SRV-CAA) Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire in December 2004. Abstract Typical use of DNS records enables resolving a server address, but this record extension authorizes clients to initiate a specific protocol. This document simply extends definitions for fields of a DNS SRV record as defined in [RFC2782] and appends '_c' to the label in the Proto field. This extension enables administrative control of a domain referenced by a client as it enables verification of permitted client addresses. This record extension is useful to authorize a client for a specific protocol and possibly useful for confirming veracity of a return path also referenced by a client. Although an in-addr.arpa IP address reverse DNS query may assert a domain, the domain referenced within client identification may be an alias and thus not match. In addition, specific protocol authorization for the client can not be deduced and reverse DNS information is optional, typically administered separately or not Otis [Page 1] RFC Draft May 2004 delegated, and thus often providing information of limited value. Introduction The SRV-CAA record relates protocols with addresses authorized by the domain to act as a client. How this information is utilized depends on the protocol. The published SRV-CAA record should be stable, concise, and narrow in scope. Use of SRV-CAA allows publishing of protocol/client/domain relationships as a means of adopting a strategic solution for exigent situations where client domain spoofing threatens network integrity. Definitions The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" used in this document are to be interpreted as specified in [BCP 14]. Other terms used in this document are defined in the DNS specification, RFC 1034. Applicability Statement In general, it is expected that SRV-CAA records will be used by servers for applications where the relevant protocol specification indicates use of these records. Such specification MUST define the symbolic name to be used in the Service field of the SRV record as described below. It also MUST include security considerations. Service SRV-CAA records SHOULD NOT be used in the absence of such specification. Introductory Example If an SRV-CAA cognizant SMTP server wants to verify the authorization of an SMTP client using TCP protocol for the domain example.com., it does a lookup of: _smtp._tcp_c.example.com The example zone file near the end of this document contains answering RRs for an SRV query. Note: SMTP is chosen as an example for illustrative purposes only, and examples used in this document should not be considered a definitive statement on the recommended way for SMTP to use SRV-CAA records. As described in the earlier applicability section, consult the appropriate SMTP documents for the recommended procedures. Otis [Page 2] RFC Draft May 2004 Client/Server A client/server relationship is typically established when a client discovers a server by means of a DNS query with the server name and then initiates a connection. Using the SRV-CAA record of the domain referenced by client identifications, the server is now able to perform an analogous operation to determine if the address of the client is valid for this domain referenced in the client identification. Use of this method offers weaker identifications than certificate based schemes, but provides a light-weight domain assurance for existing protocols lacking an otherwise sufficient mechanism. Format of the SRV-CAA RR The format of SRV and (SRV-CAA) RR, whose DNS type code is 33: _Service._Proto(_c).Name TTL Class SRV Priority Weight Port Target (There is an example near the end of this document.) Service Service is the symbolic name of the desired service, as defined in Assigned Numbers [STD 2] or locally. As per RFC2782, an underscore '_' is prepended to the service identifier to avoid collisions with DNS labels used to locate hosts. If Assigned Numbers names the service, that name is the only legal name for SRV-CAA lookups. The Service is case insensitive. Proto Proto is the symbolic name of the desired protocol, with an underscore '_' prepended to prevent collisions with DNS labels used to locate hosts and '_c' is appended the Proto identifier to avoid collisions with labels used to discover services. _tcp_c, _udp_c, and _sctp_c are at present the most useful values for this field, though any name defined by Assigned Numbers, or locally, may be used (as for Service). The Proto is case insensitive. Name Name is the domain this RR refers to. As with other SRV RR queries, the SRV-CAA RR name used for queries is composed from the domain name obtained from client identification; the example near the end shows this clearly. Otis [Page 3] RFC Draft May 2004 TTL Standard DNS meaning [RFC 1035]. Class Standard DNS meaning [RFC 1035]. SRV-CAA records occur in the IN Class. Priority The meaning of Priority differs from [RFC2782]. Priority is generally used to indicate the nature of the client list as defined by the protocol, for example whether the list is complete or open- ended. Priority should be the same for all SRV-CAA records accessed by the same label. Weight The meaning of Weight differs from [RFC2782]. Weight is generally used to indicate the nature of the client as defined by the protocol, for example whether information is being relayed or is originating at the client. Port The meaning of Port differs from [RFC2782]. Port indicates the allowed server port accessed by the client to initiate communications. The range is 0-65535. A port value of 0 indicates all server ports are allowed. This is a 16 bit unsigned integer in network byte order. This value is often as specified in Assigned Numbers, but need not be. If more than a single port is to be allowed, the value of port should be zero. Target The meaning of Target differs from [RFC2782]. Target is the domain name of the client. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field. Domain Administrator Advice Expecting everyone to update their server applications when the first Otis [Page 4] RFC Draft May 2004 client publishes a SRV-CAA RR is futile (even if desirable). Therefore SRV-CAA would have to coexist with other means used to authorize the client. Where clients within a domain are spread over several hosts, it seems advisable to have a list of address records at the same DNS node as the SRV-CAA RR. Currently there's a practical limit of 512 bytes for DNS replies. Until all resolvers can handle larger responses, domain administrators are strongly advised to keep their SRV replies below 512 bytes. A reply packet has a 30-byte overhead plus the name of the service ("_smtp._tcp_c.example.com" for instance); each SRV-CAA RR adds 20 bytes plus the name of the target host; each NS RR in the NS section is 15 bytes plus the name of the name server host; and finally each A RR in the additional data section is 20 bytes or so, and there are A's for each SRV and NS RR mentioned in the answer. This size estimate is approximate, but shouldn't underestimate the actual answer size by much. If an answer may be close to the limit, using a DNS query tool (e.g. "dig") to look at the actual answer is a good idea. Usage rules A SRV-CAA cognizant server SHOULD use this procedure to verify the address of the client has been authorized: Do a lookup for QNAME=_service._protocol_c.name, QCLASS=IN, QTYPE=SRV. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV- CAA RR which specifies the requested Service and Protocol in the reply. If there is precisely one SRV-CAA RR, and its Target is "." (the root domain), the client authorization is not valid. If there were no SRV-CAA RR matching the requested Service and Protocol, the client authorization is unknown. Else, for all such RR's, do a lookup for QNAME=target, QCLASS=IN, QTYPE=A and check for an address matching that of the client. If the Priority indicated an open list, and there was no match, then the client authorization is not confirmed. Otis [Page 5] RFC Draft May 2004 If an address match is discovered, and the port information indicates an authorized port is in use, then client authorization is confirmed. The protocol must then indicate how to process the Priority and Weight information. Notes: If a truncated response comes back from an SRV-CAA query, the rules described in [RFC 2181] shall apply. If the Additional Data section doesn't contain address records for all the SRV-CAA RR's, the server MUST look up the address record(s). (This happens quite often when the address record has shorter TTL than the SRV-CAA or NS RR's.) Fictional Example This example uses fictional service "foobar" as an aid in understanding SRV-CAA records. If ever service "foobar" is implemented, it is not intended that it will necessarily use SRV-CAA records. This is (part of) the zone file for a fictitious example.com: $ORIGIN example.com. @ SOA server.example.com. root.example.com. ( 1995032001 3600 3600 604800 86400 ) NS server.example.com. NS ns1.ip-provider.net. NS ns2.ip-provider.net. _foobar._tcp_c SRV 0 0 0 fred.example.com. SRV 0 0 0 sam.example.com. fred A 172.30.79.11 sam A 172.30.79.12 accounting A 172.30.79.13 server A 172.30.79.14 ; clients are not authorized for other services *._tcp_c SRV 0 0 0 . *._udp_c SRV 0 0 0 . In this example, a client of the "foobar" service in the "example.com." domain needs an SRV lookup of "_foobar._tcp_c.example.com." and possibly A lookups of "fred.example.com.", and/or the other hosts named. The size of the SRV reply is approximately 268 bytes: Otis [Page 6] RFC Draft May 2004 30 bytes general overhead 27 bytes for the query string, "_foobar._tcp_c.example.com." 58 bytes for 2 SRV-CAA RR's, 20 bytes each plus the lengths of "fred", "sam", - "example.com" in the query section is quoted here and doesn't need to be counted again. 73 bytes for 3 NS RRs, 15 bytes each plus the lengths of "server", "ns1" and "ns2" - again, "ip-provider.net." is quoted and only needs to be counted once. 80 bytes for the 4 address records (assuming IPv4 only) mentioned by the SRV and NS RR's. IANA Considerations No IANA services are required by this document. Security Considerations The author believes this RR to not cause any new security problems. Some problems become more visible, though. There is no way a site can keep its hosts from being referenced as servers. This could lead to denial of service. With SRV, DNS spoofers can supply false addresses. Because this vulnerability exists already with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect. SRV-CAA Labeled TXT Records A TXT record associated with the same label used to access the SRV- CAA may be used to provide information related to error reporting as determined by the protocol specification. Otis [Page 7] RFC Draft May 2004 References STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. RFC 1035: Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987. RFC 974: Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, January 1986. BCP 14: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997. BCP 14: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. RFC 2782: Gulbrandsen, A., P. Vixie, and L. Esibov, L.,"A DNS RR for specifying the location of services (DNS SRV)" February 2000. Author's Address: Douglas Otis Mail Abuse Prevention System (MAPS) 1732 North First St. #680 San Jose, CA 95112 dotis@mail-abuse.org Otis [Page 8] RFC Draft May 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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. Otis [Page 9]