Import initial strongswan 2.7.0 version into SVN.

1 files changed, 840 insertions, 0 deletions

diff --git a/doc/draft-richardson-ipsec-rr.txt b/doc/draft-richardson-ipsec-rr.txt
new file mode 100644
index 000000000..7c229b8e1
--- /dev/null
+++ b/doc/draft-richardson-ipsec-rr.txt
@@ -0,0 +1,840 @@
+
+
+IPSECKEY WG                                                M. Richardson
+Internet-Draft                                                       SSW
+Expires: March 4, 2004                                 September 4, 2003
+
+
+           A method for storing IPsec keying material in DNS.
+                     draft-ietf-ipseckey-rr-07.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 March 4, 2004.
+
+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 obsoleted by RFC3445.
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 1]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . .  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 type  . . . . . . . . . . . . . . . . .  4
+   2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  5
+   2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . .  5
+   3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  7
+   3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  7
+   3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   4.1 Active attacks against unsecured IPSECKEY resource records . .  9
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
+   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
+       Normative references . . . . . . . . . . . . . . . . . . . . . 13
+       Non-normative references . . . . . . . . . . . . . . . . . . . 14
+       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 2]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+1. Introduction
+
+   The type number for the IPSECKEY RR is TBD.
+
+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 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 [8].
+
+1.2 Usage Criteria
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 3]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+2. Storage formats
+
+2.1 IPSECKEY RDATA format
+
+   The RDATA for an IPSECKEY RR consists of a precedence value, a public
+   key, 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   | gateway type  |  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].
+
+   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.
+
+2.3 RDATA format - algorithm type
+
+   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:
+
+   1  A DSA key is present, in the format defined in RFC2536 [11]
+
+   2  A RSA key is present, in the format defined in RFC3110 [12]
+
+
+2.4 RDATA format - gateway type
+
+   The gateway type field indicates the format of the information that
+   is stored in the gateway field.
+
+
+
+Richardson                Expires March 4, 2004                 [Page 4]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   The following values are defined:
+
+   0  No gateway is present
+
+   1  A 4-byte IPv4 address is present
+
+   2  A 16-byte IPv6 address is present
+
+   3  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.
+
+
+2.5 RDATA format - gateway
+
+   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
+   [2].  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
+   [7].  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 [2].  Compression MUST NOT be used.
+
+2.6 RDATA format - public keys
+
+   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
+
+
+
+Richardson                Expires March 4, 2004                 [Page 5]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   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 [11]
+
+   The RSA key format is defined in RFC3110 [12], 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 6]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+3. Presentation formats
+
+3.1 Representation of IPSECKEY 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 [3] Section 5.2.
+
+   The general presentation for the record as as follows:
+
+   IN     IPSECKEY ( precedence gateway-type algorithm
+                     gateway base64-encoded-public-key )
+
+
+3.2 Examples
+
+   An example of a node 192.0.2.38 that will accept IPsec tunnels on its
+   own behalf.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.38
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38 that has published its key only.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
+                    .
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   An example of a node, 192.0.2.38 that has delegated authority to the
+   node 192.0.2.3.
+
+   38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
+                    192.0.2.3
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 7]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   An example of a node, 192.0.1.38 that has delegated authority to the
+   node with the identity "mygateway.example.com".
+
+   38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
+                    mygateway.example.com.
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+   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
+
+   $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
+   0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
+                    2001:0DB8:0:8002::2000:1
+                    AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                 [Page 8]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+4. Security Considerations
+
+   This entire memo pertains to the provision of public keying material
+   for use by key management protocols such as ISAKMP/IKE (RFC2407) [9].
+
+   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.
+
+4.1 Active attacks against unsecured IPSECKEY resource records
+
+   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
+
+
+
+Richardson                Expires March 4, 2004                 [Page 9]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 10]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+5. IANA Considerations
+
+   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 Section 2.3.  Algorithm numbers 3
+   through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
+
+   This document creates an IANA registry for the gateway type field.
+
+   Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
+   through 255 can be assigned by Standards Action (see RFC2434 [6]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 11]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+6. Acknowledgments
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 12]
+
+Internet-Draft                   ipsecrr                  September 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]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
+        Extensions) Part One: Mechanisms for Specifying and Describing
+        the Format of Internet Message Bodies", RFC 1521, September
+        1993.
+
+   [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [5]  Eastlake, D. and C. Kaufman, "Domain Name System Security
+        Extensions", RFC 2065, January 1997.
+
+   [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Richardson                Expires March 4, 2004                [Page 13]
+
+Internet-Draft                   ipsecrr                  September 2003
+
+
+Non-normative references
+
+   [7]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
+         version 6", RFC 1886, December 1995.
+
+   [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [9]   Piper, D., "The Internet IP Security Domain of Interpretation
+         for ISAKMP", RFC 2407, November 1998.
+
+   [10]  Eastlake, D., "Domain Name System Security Extensions", RFC
+         2535, March 1999.
+
+   [11]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
+         (DNS)", RFC 2536, March 1999.
+
+   [12]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
+         System (DNS)", RFC 3110, May 2001.
+
+   [13]  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 March 4, 2004                [Page 14]
+
+Internet-Draft                   ipsecrr                  September 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 March 4, 2004                [Page 15]
+