From d10eeb96e5244606b0b6501fd9c5c20a948b38a0 Mon Sep 17 00:00:00 2001 From: Mark Andrews Date: Tue, 21 Jan 2003 21:45:30 +0000 Subject: [PATCH] new draft --- doc/draft/draft-richardson-ipsec-rr-01.txt | 339 +++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/draft/draft-richardson-ipsec-rr-01.txt diff --git a/doc/draft/draft-richardson-ipsec-rr-01.txt b/doc/draft/draft-richardson-ipsec-rr-01.txt new file mode 100644 index 0000000000..a4d03ea143 --- /dev/null +++ b/doc/draft/draft-richardson-ipsec-rr-01.txt @@ -0,0 +1,339 @@ + + + + + + +Independent submission M. Richardson +Internet-Draft SSW +Expires: July 16, 2003 January 15, 2003 + + + A method for storing IPsec keying material in DNS. + draft-richardson-ipsec-rr-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 July 16, 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 [1]. + + + + + + + + + +Richardson Expires July 16, 2003 [Page 1] + +Internet-Draft ipsecrr January 2003 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 + + 3. IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 5 + 3.1 RDATA format - gateway type . . . . . . . . . . . . . . . . . 5 + 3.2 RDATA format - algo type . . . . . . . . . . . . . . . . . . . 5 + 3.3 RDATA format - precedence . . . . . . . . . . . . . . . . . . 6 + 3.4 RDATA format - RSA public key . . . . . . . . . . . . . . . . 6 + 3.5 RDATA format - DSA public key . . . . . . . . . . . . . . . . 6 + + 4. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 + 4.1 File Representation of IPSECKEY RRs . . . . . . . . . . . . . 7 + + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + + 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 + + Normative references . . . . . . . . . . . . . . . . . . . . . 10 + + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 + + Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11 +1. Introduction + +1.1 Overview + + Overview. +2. Storage formats + + The IPSECKEY resource record (RR) is used to publish a public key + that is to be associated with a Domain Name System (DNS) name. It + will be a public key as only public keys are stored in the DNS. This + can be the public key of a host, network, or application (in the case + of per-port keying). + + An IPSECKEY RR is, like any other RR, authenticated by a SIG RR. + + It is expected that there will often be multiple resource records of + the IPSECKEY type. This will be due to the need to rollover keys, + and due to the presence of multiple gateways. + + The type number for the IPSECKEY RR is 44 (IANA TBD). +3. IPSECKEY RDATA format + + + + +Richardson Expires July 16, 2003 [Page 2] + +Internet-Draft ipsecrr January 2003 + + + The RDATA for an IPSECKEY RR consists of a precedence value, a public + key (and algorithm type), and an optional gateway address. + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | gtype | algo | precedence | public key length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + / public key + / / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| + ~ gateway ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +3.1 RDATA format - gateway type + + The gateway type ("gtype") field indicates the format of the gateway + field. The gateway field may be absent. + + 0 No gateway field is present + + 1 A 32-bit IPv4 address is present in the gateway field, in section + + 2 A 128-bit IPv6 address is present in the gateway field. The data + portion is an IPv6 address as described in section 3.2 of [4]. + This is a 128-bit number in network byte order. + + 3 A fully qualified domain name is present in the gateway field. + The name a %lt;domain-name%gt; encoded as described in section 3.3 + of [4]. This field occupies the space until the end of the RDATA. + + +3.2 RDATA format - algo type + + The algorithm type ("algo") field indicates the type of key that is + present in the public key field. Valid values are: + + 0 No key is present. + + 1 A RSA key is present, in the format defined in + + 2 A DSA key is present, in the format defined in + +3.3 RDATA format - precedence + + This is an 8-bit precedence for this record. This is interpreted in + + + +Richardson Expires July 16, 2003 [Page 3] + +Internet-Draft ipsecrr January 2003 + + + a similar way to the PREFERENCE field described in section 3.3.9 of + [3]. + +3.4 RDATA format - RSA public key + + If the algorithm type has the value 1, then public key portion + contains an RSA public key, encoded as described in secion 2 of [7], + and repeated here: + + 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | pub exp length| public key exponent / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | / + +- modulus / + | / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-/ + + 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. + +3.5 RDATA format - DSA public key + + If the algorithm type has the value 2, then public key portion + contains an DSA public key, encoded as described in [6]. +4. Presentation formats + +4.1 File Representation of IPSECKEY RRs + + IPSECKEY RRs may appear as lines in a zone data master file. The + precedence field is mandatory. While both the gateway and public key + fields are optional, it is illegal for neither to be present. + + As the IPv4, IPv6 and FQDN references to the gateway are mutually + exclusive, they can share a position. If no gateway is to be + indicated, then the special tokens of either "-" or "none" may be + used. + + + + +Richardson Expires July 16, 2003 [Page 4] + +Internet-Draft ipsecrr January 2003 + + + 38.46.139.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 192.139.46.38 + RSA: AQOrXJxB56Q28iOO43Va36elIFFKc/QB2orIeL94BdC5X4idFQZjSpsZ + Th48wKVXUE9xjwUkwR4R4/+1vjNN7KFp9fcqa2OxgjsoGqCn+3OPR8La + 9uyvZg0OBuSTj3qkbh/2HacAUJ7vqvjQ3W8Wj6sMXtTueR8NNcdSzJh1 + 49ch3zqfiXrxxna8+8UEDQaRR9KOPiSvXb2KjnuDan6hDKOT4qTZRRRC + MWwnNQ9zPIMNbLBp0rNcZ+ZGFg2ckWtWh5yhv1iXYLV2vmd9DB6d4Dv8 + cW7scc3rPmDXpYR6APqPBRHlcbenfHCt+oCkEWse8OQhMM56KODIVQq3 + fejrfi1H ) + +5. IANA Considerations + + IANA is asked to assign resource record 44 to this resource record. +6. Acknowledgments + + People who pushed me to write this. +Normative references + + [1] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource + Record", ID internet-draft (draft-ietf-dnsext-restrict-key-for- + dnssec-02) (normative), March 2002. + + [2] Mockapetris, P., "Domain names - concepts and facilities", STD + 13, RFC 1034, November 1987. + + [3] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [4] Thomson, S. and C. Huitema, "DNS Extensions to support IP + version 6", RFC 1886, December 1995. + + [5] Eastlake, D., "Domain Name System Security Extensions", RFC + 2535, March 1999. + + [6] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System + (DNS)", RFC 2536, March 1999. + + [7] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name + System (DNS)", RFC 3110, May 2001. + + +Author's Address + + Michael C. Richardson + Sandelman Software Works + 470 Dawson Avenue + Ottawa, ON K1Z 5V7 + CA + + + + +Richardson Expires July 16, 2003 [Page 5] + +Internet-Draft ipsecrr January 2003 + + + EMail: mcr@sandelman.ottawa.on.ca + URI: http://www.sandelman.ottawa.on.ca/ +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 July 16, 2003 [Page 6] + \ No newline at end of file