--- /dev/null
+
+
+IPSECKEY WG M. Richardson
+Internet-Draft SSW
+Expires: September 28, 2003 March 30, 2003
+
+
+ A method for storing IPsec keying material in DNS.
+ draft-ietf-ipseckey-rr-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.
+
+ 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 September 28, 2003.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+Abstract
+
+ This document describes a new resource record for DNS. This record
+ may be used to store public keys for use in IPsec systems.
+
+ This record replaces the functionality of the sub-type #1 of the KEY
+ Resource Record, which has been proposed to be obsoleted by RFC3445
+ [9].
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 1]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4
+ 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4
+ 2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4
+ 2.4 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 4
+ 2.5 RDATA format - RSA public key . . . . . . . . . . . . . . . . 5
+ 2.6 RDATA format - DSA public key . . . . . . . . . . . . . . . . 5
+ 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 6
+ 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
+ 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
+ Normative references . . . . . . . . . . . . . . . . . . . . . 11
+ Non-normative references . . . . . . . . . . . . . . . . . . . 12
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
+ Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 2]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+1. Introduction
+
+1.1 Overview
+
+ The IPSECKEY resource record (RR) is used to publish a public key
+ that is to be associated with a Domain Name System (DNS) name. This
+ can be the public key of a host, network, or application (in the case
+ of per-port keying).
+
+ 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 RFC2119 [5].
+
+ An IPSECKEY resource record SHOULD be authenticated DNSSEC resource
+ record.
+
+ It is expected that there will often be multiple IPSECKEY resource
+ records at the same terminal node. This will be due to the presence
+ of multiple gateways and the need to rollover keys.
+
+ This resource record is class independent.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 3]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+2. Storage formats
+
+ The type number for the IPSECKEY RR is TBD.
+
+2.1 IPSECKEY RDATA format
+
+ The RDATA for an IPSECKEY RR consists of a precedence value, a public
+ key (and algorithm type), and an optional gateway address.
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | precedence | algorithm | gateway |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
+ ~ gateway ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | /
+ / public key /
+ / /
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+
+
+2.2 RDATA format - precedence
+
+ This is an 8-bit precedence for this record. This is interpreted in
+ the same way as the PREFERENCE field described in section 3.3.9 of
+ RFC1035 [2].
+
+2.3 RDATA format - algorithm type
+
+ aThe algorithm type field indicates the type of key that is present
+ in the public key field. A positive number, larger than 0 identifies
+ an algorithm type. The following values, which have been previously
+ defined by IANA are useful (see RFC2535 [6]).
+
+ A value of 0 indicates that no key is present.
+
+ The following values defined by IANA are useful:
+
+ 3 A DSA key is present, in the format defined in RFC2536 [7]
+
+ 5 A RSA key is present, in the format defined in RFC3110 [8]
+
+
+2.4 RDATA format - gateway
+
+ The gateway field indicates a gateway to which an IPsec tunnel may be
+ created in order to reach the entity holding this resource record.
+
+
+
+Richardson Expires September 28, 2003 [Page 4]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+ The gateway field is a normal wire-encoded domain name (section 3.3
+ of RFC1035 [2]).
+
+ If no gateway is to be represented, then a null domain name MUST be
+ present.
+
+ It is a simple fully qualified domain name (FQDN). IP version 4 and
+ IP version 6 addresses may be represented using the reverse name
+ format, from in-addr.arpa. and ip6.arpa.
+
+ For instance, the IP version 4 address 192.0.1.2 is represented as
+ the domain name 2.1.0.192.in-addr.arpa.
+
+2.5 RDATA format - RSA public key
+
+ If the algorithm type has the value 5 then public key portion
+ contains an RSA public key, encoded as described in secion 2 of
+ RFC3110 [8].
+
+ RFC2065 limited the exponent and modulus to 2552 bits in length, and
+ RFC3110 to 4096 bits. No such limit is specified here for the
+ purposes of encoding and decoding.
+
+ The length in octets of the public exponent length is represented as
+ one octet if it is in the range of 1 to 255 and by a zero octet
+ followed by a two octet unsigned length if it is longer than 255
+ bytes. The public key modulus field is a multiprecision unsigned
+ integer. The length of the modulus can be determined from the
+ RDLENGTH and the preceding RDATA fields including the exponent.
+
+ Leading zero bytes are prohibited in the exponent and modulus.
+
+2.6 RDATA format - DSA public key
+
+ If the algorithm type has the value 3, then public key portion
+ contains an DSA public key, encoded as described in RFC2536 [7].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 5]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+3. Presentation formats
+
+3.1 Representation of IPSECKEY RRs
+
+ IPSECKEY RRs may appear as lines in a zone data master file. The
+ precedence, algorithm and gateway fields are REQUIRED. There base64
+ encoded public key block is OPTIONAL.
+
+ If no gateway is to be indicated, then the root (".") SHOULD be used.
+
+3.2 Examples
+
+ An example of a node 192.2.0.38 that will accept IPsec tunnels on its
+ own behalf.
+
+ 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5
+ 38.0.2.192.in-addr.arpa.
+ AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+ 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+ 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+ MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+ cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+ fejrfi1H )
+
+ An example of a node, 192.2.0.38 that has published its key only.
+
+ 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5
+ .
+ AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+ 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+ 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+ MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+ cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+ fejrfi1H )
+
+ An example of a node, 192.2.0.38 that has delegated authority to the
+ node 192.2.3.5.
+
+ 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5
+ 5.3.2.192.in-addr.arpa.
+ AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+ 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+ 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+ MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+ cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+
+
+
+Richardson Expires September 28, 2003 [Page 6]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+ fejrfi1H )
+
+ An example of a node, 192.1.0.38 that has delegated authority to the
+ node with the identity "mygateway.example.com".
+
+ 38.0.2.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 5
+ mygateway.example.com.
+ AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ
+ Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La
+ 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1
+ 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC
+ MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8
+ cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3
+ fejrfi1H )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 7]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+4. Security Considerations
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 8]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+5. IANA Considerations
+
+ IANA is asked to assign a resource record type number from the normal
+ resource record number space.
+
+ The algorithm field does not require any IANA action, as it is
+ inherited from DNS KEY algorithm values.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 9]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+6. Acknowledgments
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 10]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+Normative references
+
+ [1] Mockapetris, P., "Domain names - concepts and facilities", STD
+ 13, RFC 1034, November 1987.
+
+ [2] Mockapetris, P., "Domain names - implementation and
+ specification", STD 13, RFC 1035, November 1987.
+
+ [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [4] Eastlake, D. and C. Kaufman, "Domain Name System Security
+ Extensions", RFC 2065, January 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 11]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+Non-normative references
+
+ [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [6] Eastlake, D., "Domain Name System Security Extensions", RFC
+ 2535, March 1999.
+
+ [7] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+ (DNS)", RFC 2536, March 1999.
+
+ [8] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+ System (DNS)", RFC 3110, May 2001.
+
+ [9] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
+ Record (RR)", RFC 3445, December 2002.
+
+
+Author's Address
+
+ Michael C. Richardson
+ Sandelman Software Works
+ 470 Dawson Avenue
+ Ottawa, ON K1Z 5V7
+ CA
+
+ EMail: mcr@sandelman.ottawa.on.ca
+ URI: http://www.sandelman.ottawa.on.ca/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 12]
+\f
+Internet-Draft ipsecrr March 2003
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2003). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson Expires September 28, 2003 [Page 13]
+\f
projects / thirdparty / bind9.git / commitdiff
