From 4f4d9f7a0e48ee9caa58a9e6ec62485a917a3924 Mon Sep 17 00:00:00 2001 From: Rene Mayrhofer Date: Mon, 6 Nov 2006 19:05:06 +0000 Subject: - New upstream release. --- doc/src/draft-richardson-ipsec-rr.xml | 560 ---------------------------------- 1 file changed, 560 deletions(-) delete mode 100644 doc/src/draft-richardson-ipsec-rr.xml (limited to 'doc/src/draft-richardson-ipsec-rr.xml') diff --git a/doc/src/draft-richardson-ipsec-rr.xml b/doc/src/draft-richardson-ipsec-rr.xml deleted file mode 100644 index e51b32615..000000000 --- a/doc/src/draft-richardson-ipsec-rr.xml +++ /dev/null @@ -1,560 +0,0 @@ - - - - - - - - Security - IPSECKEY WG - - A method for storing IPsec keying material in DNS. - - - - Sandelman Software Works -
- - 470 Dawson Avenue - Ottawa - ON - K1Z 5V7 - CA - - mcr@sandelman.ottawa.on.ca - http://www.sandelman.ottawa.on.ca/ -
- - - - - - -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 obsoleted by RFC3445. - - - - - - - -
- - The type number for the IPSECKEY RR is TBD. - - -
- - The IPSECKEY resource record (RR) is used to publish a public key that is - to be associated with a Domain Name System (DNS) name for use with the - IPsec protocol suite. 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 . - -
- -
- - An IPSECKEY resource record SHOULD be used in combination with DNSSEC -unless some other means of authenticating the IPSECKEY resource record -is available. - - - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence - of multiple gateways and the need to rollover keys. - - - - - This resource record is class independent. - -
-
- -
- -
- - - The RDATA for an IPSECKEY RR consists of a precedence value, a public key, - algorithm type, and an optional gateway address. - - - -
- -
- -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 . - - -Gateways listed in IPSECKEY records with lower precedence are -to be attempted first. Where there is a tie in precedence, the order -should be non-deterministic. - -
- -
- -The algorithm type field identifies the public key's cryptographic -algorithm and determines the format of the public key field. - - - -A value of 0 indicates that no key is present. - - - -The following values are defined: - - A DSA key is present, in the format defined in RFC2536 - A RSA key is present, in the format defined in RFC3110 - - - -
- -
- -The gateway type field indicates the format of the information that -is stored in the gateway field. - - - -The following values are defined: - - No gateway is present - A 4-byte IPv4 address is present - A 16-byte IPv6 address is present - A wire-encoded domain name is present. The wire-encoded -format is self-describing, so the length is implicit. The domain name -MUST NOT be compressed. - - - -
- -
- -The gateway field indicates a gateway to which an IPsec tunnel may be -created in order to reach the entity named by this resource record. - - -There are three formats: - - - -A 32-bit IPv4 address is present in the gateway field. The data -portion is an IPv4 address as described in section 3.4.1 of -RFC1035. This is a 32-bit number in network byte order. - - -A 128-bit IPv6 address is present in the gateway field. -The data portion is an IPv6 address as described in section 2.2 of -RFC1886. This is a 128-bit number in network byte order. - - - -The gateway field is a normal wire-encoded domain name, as described -in section 3.3 of RFC1035 . Compression MUST NOT be used. - - -
- -
- -Both of the public key types defined in this document (RSA and DSA) -inherit their public key formats from the corresponding KEY RR formats. -Specifically, the public key field contains the algorithm-specific -portion of the KEY RR RDATA, which is all of the KEY RR DATA after the -first four octets. This is the same portion of the KEY RR that must be -specified by documents that define a DNSSEC algorithm. -Those documents also specify a message digest to be used for generation -of SIG RRs; that specification is not relevant for IPSECKEY RR. - - - -Future algorithms, if they are to be used by both DNSSEC (in the KEY -RR) and IPSECKEY, are likely to use the same public key encodings in -both records. Unless otherwise specified, the IPSECKEY public key -field will contain the algorithm-specific portion of the KEY RR RDATA -for the corresponding algorithm. The algorithm must still be -designated for use by IPSECKEY, and an IPSECKEY algorithm type number -(which might be different than the DNSSEC algorithm number) must be -assigned to it. - - -The DSA key format is defined in RFC2536 . - -The RSA key format is defined in RFC3110 , -with the following changes: - - -The earlier definition of RSA/MD5 in RFC2065 limited the exponent and -modulus to 2552 bits in length. RFC3110 extended that limit to 4096 -bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on -RSA public keys, other than the 65535 octet limit imposed by the -two-octet length encoding. This length extension is applicable only -to IPSECKEY and not to KEY RRs. - - -
- -
- - - -
- -
- - IPSECKEY RRs may appear in a zone data master file. - The precedence, gateway type and algorithm and gateway fields are REQUIRED. - The base64 encoded public key block is OPTIONAL; if not present, - then the public key field of the resource record MUST be construed - as being zero octets in length. - - - The algorithm field is an unsigned integer. No mnemonics are defined. - - - If no gateway is to be indicated, then the gateway type field MUST - be zero, and the gateway field MUST be "." - - - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see -RFC1521 Section 5.2. - - - - - The general presentation for the record as as follows: - - -
- - -
- -An example of a node 192.0.2.38 that will accept IPsec tunnels on its -own behalf. - - - - -An example of a node, 192.0.2.38 that has published its key only. - - - - -An example of a node, 192.0.2.38 that has delegated authority to the node -192.0.2.3. - - - - -An example of a node, 192.0.1.38 that has delegated authority to the node -with the identity "mygateway.example.com". - - - - -An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has -delegated authority to the node 2001:0DB8:c000:0200:2::1 - - - -
-
- -
- - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) - . - - - -The IPSECKEY resource record contains information that SHOULD be -communicated to the end client in an integral fashion - i.e. free from -modification. The form of this channel is up to the consumer of the -data - there must be a trust relationship between the end consumer of this -resource record and the server. This relationship may be end-to-end -DNSSEC validation, a TSIG or SIG(0) channel to another secure source, -a secure local channel on the host, or some combination of the above. - - - -The keying material provided by the IPSECKEY resource record is not -sensitive to passive attacks. The keying material may be freely -disclosed to any party without any impact on the security properties -of the resulting IPsec session: IPsec and IKE provide for defense -against both active and passive attacks. - - - - Any user of this resource record MUST carefully document their trust - model, and why the trust model of DNSSEC is appropriate, if that is - the secure channel used. - - -
- -This section deals with active attacks against the DNS. These attacks -require that DNS requests and responses be intercepted and changed. -DNSSEC is designed to defend against attacks of this kind. - - - -The first kind of active attack is when the attacker replaces the -keying material with either a key under its control or with garbage. - - - -If the attacker is not able to mount a subsequent -man-in-the-middle attack on the IKE negotiation after replacing the -public key, then this will result in a denial of service, as the -authenticator used by IKE would fail. - - - -If the attacker is able to both to mount active attacks against DNS -and is also in a position to perform a man-in-the-middle attack on IKE and -IPsec negotiations, then the attacker will be in a position to compromise -the resulting IPsec channel. Note that an attacker must be able to -perform active DNS attacks on both sides of the IKE negotiation in -order for this to succeed. - - - -The second kind of active attack is one in which the attacker replaces -the the gateway address to point to a node under the attacker's -control. The attacker can then either replace the public key or remove -it, thus providing an IPSECKEY record of its own to match the -gateway address. - - - -This later form creates a simple man-in-the-middle since the attacker -can then create a second tunnel to the real destination. Note that, as before, -this requires that the attacker also mount an active attack against -the responder. - - - -Note that the man-in-the-middle can not just forward cleartext -packets to the original destination. While the destination may be -willing to speak in the clear, replying to the original sender, -the sender will have already created a policy expecting ciphertext. -Thus, the attacker will need to intercept traffic from both sides. In some -cases, the attacker may be able to accomplish the full intercept by use -of Network Addresss/Port Translation (NAT/NAPT) technology. - - - -Note that the danger here only applies to cases where the gateway -field of the IPSECKEY RR indicates a different entity than the owner -name of the IPSECKEY RR. In cases where the end-to-end integrity of -the IPSECKEY RR is suspect, the end client MUST restrict its use -of the IPSECKEY RR to cases where the RR owner name matches the -content of the gateway field. - -
- -
- -
- -This document updates the IANA Registry for DNS Resource Record Types -by assigning type X to the IPSECKEY record. - - - -This document creates an IANA registry for the algorithm type field. - - -Values 0, 1 and 2 are defined in . Algorithm numbers -3 through 255 can be assigned by IETF Consensus (see RFC2434). - - - -This document creates an IANA registry for the gateway type field. - - -Values 0, 1, 2 and 3 are defined in . -Algorithm numbers 4 through 255 can be assigned by -Standards Action (see RFC2434). - - - - -
- -
- -My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein, -and Olafur Gurmundsson who reviewed this document carefully. -Additional thanks to Olafur Gurmundsson for a reference implementation. - -
- - - - - - - - - - - - - - - - - - - - - - - - - -