contrib/bind9/doc/rfc/rfc4025.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      M. Richardson
   8 Request for Comments: 4025                                           SSW
   9 Category: Standards Track                                   February 2005
  10
  11
  12            A Method for Storing IPsec Keying Material in DNS
  13
  14 Status of This Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (2005).
  25
  26 Abstract
  27
  28    This document describes a new resource record for the Domain Name
  29    System (DNS).  This record may be used to store public keys for use
  30    in IP security (IPsec) systems.  The record also includes provisions
  31    for indicating what system should be contacted when an IPsec tunnel
  32    is established with the entity in question.
  33
  34    This record replaces the functionality of the sub-type #4 of the KEY
  35    Resource Record, which has been obsoleted by RFC 3445.
  36
  37 Table of Contents
  38
  39    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
  40        1.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . .  2
  41        1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and
  42              IP6.ARPA)  . . . . . . . . . . . . . . . . . . . . . . .  3
  43        1.3.  Usage Criteria . . . . . . . . . . . . . . . . . . . . .  3
  44    2.  Storage Formats  . . . . . . . . . . . . . . . . . . . . . . .  3
  45        2.1.  IPSECKEY RDATA Format  . . . . . . . . . . . . . . . . .  3
  46        2.2.  RDATA Format - Precedence  . . . . . . . . . . . . . . .  4
  47        2.3.  RDATA Format - Gateway Type  . . . . . . . . . . . . . .  4
  48        2.4.  RDATA Format - Algorithm Type  . . . . . . . . . . . . .  4
  49        2.5.  RDATA Format - Gateway . . . . . . . . . . . . . . . . .  5
  50        2.6.  RDATA Format - Public Keys . . . . . . . . . . . . . . .  5
  51    3.  Presentation Formats . . . . . . . . . . . . . . . . . . . . .  6
  52        3.1.  Representation of IPSECKEY RRs . . . . . . . . . . . . .  6
  53        3.2.  Examples . . . . . . . . . . . . . . . . . . . . . . . .  6
  54    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  55
  56
  57
  58 Richardson                  Standards Track                     [Page 1]
  59 \f
  60 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
  61
  62
  63        4.1.  Active Attacks Against Unsecured IPSECKEY Resource
  64              Records  . . . . . . . . . . . . . . . . . . . . . . . .  8
  65              4.1.1.  Active Attacks Against IPSECKEY Keying
  66                      Materials. . . . . . . . . . . . . . . . . . . .  8
  67              4.1.2.  Active Attacks Against IPSECKEY Gateway
  68                      Material. . . . . . . . . . . . . . . . . . . .   8
  69    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
  70    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
  71    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
  72        7.1.  Normative References . . . . . . . . . . . . . . . . . . 10
  73        7.2.  Informative References . . . . . . . . . . . . . . . . . 10
  74    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
  75    Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 12
  76
  77 1.  Introduction
  78
  79    Suppose a host wishes (or is required by policy) to establish an
  80    IPsec tunnel with some remote entity on the network prior to allowing
  81    normal communication to take place.  In many cases, this end system
  82    will be able to determine the DNS name for the remote entity (either
  83    by having the DNS name given explicitly, by performing a DNS PTR
  84    query for a particular IP address, or through some other means, e.g.,
  85    by extracting the DNS portion of a "user@FQDN" name for a remote
  86    entity).  In these cases, the host will need to obtain a public key
  87    to authenticate the remote entity, and may also need some guidance
  88    about whether it should contact the entity directly or use another
  89    node as a gateway to the target entity.  The IPSECKEY RR provides a
  90    mechanism for storing such information.
  91
  92    The type number for the IPSECKEY RR is 45.
  93
  94    This record replaces the functionality of the sub-type #4 of the KEY
  95    Resource Record, which has been obsoleted by RFC 3445 [11].
  96
  97 1.1.  Overview
  98
  99    The IPSECKEY resource record (RR) is used to publish a public key
 100    that is to be associated with a Domain Name System (DNS) [1] name for
 101    use with the IPsec protocol suite.  This can be the public key of a
 102    host, network, or application (in the case of per-port keying).
 103
 104    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 105    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 106    document are to be interpreted as described in RFC 2119 [3].
 107
 108
 109
 110
 111
 112
 113
 114 Richardson                  Standards Track                     [Page 2]
 115 \f
 116 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 117
 118
 119 1.2.  Use of DNS Address-to-Name Maps (IN-ADDR.ARPA and IP6.ARPA)
 120
 121    Often a security gateway will only have access to the IP address of
 122    the node with which communication is desired and will not know any
 123    other name for the target node.  Because of this, frequently the best
 124    way of looking up IPSECKEY RRs will be by using the IP address as an
 125    index into one of the reverse mapping trees (IN-ADDR.ARPA for IPv4 or
 126    IP6.ARPA for IPv6).
 127
 128    The lookup is done in the fashion usual for PTR records.  The IP
 129    address' octets (IPv4) or nibbles (IPv6) are reversed and looked up
 130    with the appropriate suffix.  Any CNAMEs or DNAMEs found MUST be
 131    followed.
 132
 133    Note: even when the IPsec function is contained in the end-host,
 134    often only the application will know the forward name used.  Although
 135    the case where the application knows the forward name is common, the
 136    user could easily have typed in a literal IP address.  This storage
 137    mechanism does not preclude using the forward name when it is
 138    available but does not require it.
 139
 140 1.3.  Usage Criteria
 141
 142    An IPSECKEY resource record SHOULD be used in combination with DNSSEC
 143    [8] unless some other means of authenticating the IPSECKEY resource
 144    record is available.
 145
 146    It is expected that there will often be multiple IPSECKEY resource
 147    records at the same name.  This will be due to the presence of
 148    multiple gateways and a need to roll over keys.
 149
 150    This resource record is class independent.
 151
 152 2.  Storage Formats
 153
 154 2.1.  IPSECKEY RDATA Format
 155
 156    The RDATA for an IPSECKEY RR consists of a precedence value, a
 157    gateway type, a public key, algorithm type, and an optional gateway
 158    address.
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Richardson                  Standards Track                     [Page 3]
 171 \f
 172 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 173
 174
 175        0                   1                   2                   3
 176        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
 177       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 178       |  precedence   | gateway type  |  algorithm  |     gateway     |
 179       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
 180       ~                            gateway                            ~
 181       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 182       |                                                               /
 183       /                          public key                           /
 184       /                                                               /
 185       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 186
 187 2.2.  RDATA Format - Precedence
 188
 189    This is an 8-bit precedence for this record.  It is interpreted in
 190    the same way as the PREFERENCE field described in section 3.3.9 of
 191    RFC 1035 [2].
 192
 193    Gateways listed in IPSECKEY records with lower precedence are to be
 194    attempted first.  Where there is a tie in precedence, the order
 195    should be non-deterministic.
 196
 197 2.3.  RDATA Format - Gateway Type
 198
 199    The gateway type field indicates the format of the information that
 200    is stored in the gateway field.
 201
 202    The following values are defined:
 203    0  No gateway is present.
 204    1  A 4-byte IPv4 address is present.
 205    2  A 16-byte IPv6 address is present.
 206    3  A wire-encoded domain name is present.  The wire-encoded format is
 207       self-describing, so the length is implicit.  The domain name MUST
 208       NOT be compressed.  (See Section 3.3 of RFC 1035 [2].)
 209
 210 2.4.  RDATA Format - Algorithm Type
 211
 212    The algorithm type field identifies the public key's cryptographic
 213    algorithm and determines the format of the public key field.
 214
 215    A value of 0 indicates that no key is present.
 216
 217    The following values are defined:
 218    1  A DSA key is present, in the format defined in RFC 2536 [9].
 219    2  A RSA key is present, in the format defined in RFC 3110 [10].
 220
 221
 222
 223
 224
 225
 226 Richardson                  Standards Track                     [Page 4]
 227 \f
 228 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 229
 230
 231 2.5.  RDATA Format - Gateway
 232
 233    The gateway field indicates a gateway to which an IPsec tunnel may be
 234    created in order to reach the entity named by this resource record.
 235
 236    There are three formats:
 237
 238    A 32-bit IPv4 address is present in the gateway field.  The data
 239    portion is an IPv4 address as described in section 3.4.1 of RFC 1035
 240    [2].  This is a 32-bit number in network byte order.
 241
 242    A 128-bit IPv6 address is present in the gateway field.  The data
 243    portion is an IPv6 address as described in section 2.2 of RFC 3596
 244    [12].  This is a 128-bit number in network byte order.
 245
 246    The gateway field is a normal wire-encoded domain name, as described
 247    in section 3.3 of RFC 1035 [2].  Compression MUST NOT be used.
 248
 249 2.6.  RDATA Format - Public Keys
 250
 251    Both the public key types defined in this document (RSA and DSA)
 252    inherit their public key formats from the corresponding KEY RR
 253    formats.  Specifically, the public key field contains the
 254    algorithm-specific portion of the KEY RR RDATA, which is all the KEY
 255    RR DATA after the first four octets.  This is the same portion of the
 256    KEY RR that must be specified by documents that define a DNSSEC
 257    algorithm.  Those documents also specify a message digest to be used
 258    for generation of SIG RRs; that specification is not relevant for
 259    IPSECKEY RRs.
 260
 261    Future algorithms, if they are to be used by both DNSSEC (in the KEY
 262    RR) and IPSECKEY, are likely to use the same public key encodings in
 263    both records.  Unless otherwise specified, the IPSECKEY public key
 264    field will contain the algorithm-specific portion of the KEY RR RDATA
 265    for the corresponding algorithm.  The algorithm must still be
 266    designated for use by IPSECKEY, and an IPSECKEY algorithm type number
 267    (which might be different from the DNSSEC algorithm number) must be
 268    assigned to it.
 269
 270    The DSA key format is defined in RFC 2536 [9]
 271
 272    The RSA key format is defined in RFC 3110 [10], with the following
 273    changes:
 274
 275    The earlier definition of RSA/MD5 in RFC 2065 [4] limited the
 276    exponent and modulus to 2552 bits in length.  RFC 3110 extended that
 277    limit to 4096 bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no
 278    length limit on RSA public keys, other than the 65535 octet limit
 279
 280
 281
 282 Richardson                  Standards Track                     [Page 5]
 283 \f
 284 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 285
 286
 287    imposed by the two-octet length encoding.  This length extension is
 288    applicable only to IPSECKEY; it is not applicable to KEY RRs.
 289
 290 3.  Presentation Formats
 291
 292 3.1.  Representation of IPSECKEY RRs
 293
 294    IPSECKEY RRs may appear in a zone data master file.  The precedence,
 295    gateway type, algorithm, and gateway fields are REQUIRED.  The base64
 296    encoded public key block is OPTIONAL; if it is not present, the
 297    public key field of the resource record MUST be construed to be zero
 298    octets in length.
 299
 300    The algorithm field is an unsigned integer.  No mnemonics are
 301    defined.
 302
 303    If no gateway is to be indicated, then the gateway type field MUST be
 304    zero, and the gateway field MUST be "."
 305
 306    The Public Key field is represented as a Base64 encoding of the
 307    Public Key.  Whitespace is allowed within the Base64 text.  For a
 308    definition of Base64 encoding, see RFC 3548 [6], Section 5.2.
 309
 310    The general presentation for the record is as follows:
 311
 312    IN     IPSECKEY ( precedence gateway-type algorithm
 313                      gateway base64-encoded-public-key )
 314
 315 3.2.  Examples
 316
 317    An example of a node, 192.0.2.38, that will accept IPsec tunnels on
 318    its own behalf.
 319
 320    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
 321                     192.0.2.38
 322                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 323
 324    An example of a node, 192.0.2.38, that has published its key only.
 325
 326    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
 327                     .
 328                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Richardson                  Standards Track                     [Page 6]
 339 \f
 340 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 341
 342
 343    An example of a node, 192.0.2.38, that has delegated authority to the
 344    node 192.0.2.3.
 345
 346    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
 347                     192.0.2.3
 348                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 349
 350    An example of a node, 192.0.1.38 that has delegated authority to the
 351    node with the identity "mygateway.example.com".
 352
 353    38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
 354                     mygateway.example.com.
 355                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 356
 357    An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0, that has
 358    delegated authority to the node 2001:0DB8:c000:0200:2::1
 359
 360    $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.arpa.
 361    0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
 362                     2001:0DB8:0:8002::2000:1
 363                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 364
 365 4.  Security Considerations
 366
 367    This entire memo pertains to the provision of public keying material
 368    for use by key management protocols such as ISAKMP/IKE (RFC 2407)
 369    [7].
 370
 371    The IPSECKEY resource record contains information that SHOULD be
 372    communicated to the end client in an integral fashion; i.e., free
 373    from modification.  The form of this channel is up to the consumer of
 374    the data; there must be a trust relationship between the end consumer
 375    of this resource record and the server.  This relationship may be
 376    end-to-end DNSSEC validation, a TSIG or SIG(0) channel to another
 377    secure source, a secure local channel on the host, or some
 378    combination of the above.
 379
 380    The keying material provided by the IPSECKEY resource record is not
 381    sensitive to passive attacks.  The keying material may be freely
 382    disclosed to any party without any impact on the security properties
 383    of the resulting IPsec session.  IPsec and IKE provide defense
 384    against both active and passive attacks.
 385
 386    Any derivative specification that makes use of this resource record
 387    MUST carefully document its trust model and why the trust model of
 388    DNSSEC is appropriate, if that is the secure channel used.
 389
 390
 391
 392
 393
 394 Richardson                  Standards Track                     [Page 7]
 395 \f
 396 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 397
 398
 399    An active attack on the DNS that caused the wrong IP address to be
 400    retrieved (via forged address), and therefore the wrong QNAME to be
 401    queried, would also result in a man-in-the-middle attack.  This
 402    situation is independent of whether the IPSECKEY RR is used.
 403
 404 4.1.  Active Attacks Against Unsecured IPSECKEY Resource Records
 405
 406    This section deals with active attacks against the DNS.  These
 407    attacks require that DNS requests and responses be intercepted and
 408    changed.  DNSSEC is designed to defend against attacks of this kind.
 409    This section deals with the situation in which DNSSEC is not
 410    available.  This is not the recommended deployment scenario.
 411
 412 4.1.1.  Active Attacks Against IPSECKEY Keying Materials
 413
 414    The first kind of active attack is when the attacker replaces the
 415    keying material with either a key under its control or with garbage.
 416
 417    The gateway field is either untouched or is null.  The IKE
 418    negotiation will therefore occur with the original end-system.  For
 419    this attack to succeed, the attacker must perform a man-in-the-middle
 420    attack on the IKE negotiation.  This attack requires that the
 421    attacker be able to intercept and modify packets on the forwarding
 422    path for the IKE and data packets.
 423
 424    If the attacker is not able to perform this man-in-the-middle attack
 425    on the IKE negotiation, then a denial of service will result, as the
 426    IKE negotiation will fail.
 427
 428    If the attacker is not only able to mount active attacks against DNS
 429    but also in a position to perform a man-in-the-middle attack on IKE
 430    and IPsec negotiations, then the attacker will be able to compromise
 431    the resulting IPsec channel.  Note that an attacker must be able to
 432    perform active DNS attacks on both sides of the IKE negotiation for
 433    this to succeed.
 434
 435 4.1.2.  Active Attacks Against IPSECKEY Gateway Material
 436
 437    The second kind of active attack is one in which the attacker
 438    replaces the gateway address to point to a node under the attacker's
 439    control.  The attacker then either replaces the public key or removes
 440    it.  If the public key were removed, then the attacker could provide
 441    an accurate public key of its own in a second record.
 442
 443    This second form creates a simple man-in-the-middle attacks since the
 444    attacker can then create a second tunnel to the real destination.
 445    Note that, as before, this requires that the attacker also mount an
 446    active attack against the responder.
 447
 448
 449
 450 Richardson                  Standards Track                     [Page 8]
 451 \f
 452 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 453
 454
 455    Note that the man-in-the-middle cannot just forward cleartext packets
 456    to the original destination.  While the destination may be willing to
 457    speak in the clear, replying to the original sender, the sender will
 458    already have created a policy expecting ciphertext.  Thus, the
 459    attacker will need to intercept traffic in both directions.  In some
 460    cases, the attacker may be able to accomplish the full intercept by
 461    use of Network Address/Port Translation (NAT/NAPT) technology.
 462
 463    This attack is easier than the first one because the attacker does
 464    NOT need to be on the end-to-end forwarding path.  The attacker need
 465    only be able to modify DNS replies.  This can be done by packet
 466    modification, by various kinds of race attacks, or through methods
 467    that pollute DNS caches.
 468
 469    If the end-to-end integrity of the IPSECKEY RR is suspect, the end
 470    client MUST restrict its use of the IPSECKEY RR to cases where the RR
 471    owner name matches the content of the gateway field.  As the RR owner
 472    name is assumed when the gateway field is null, a null gateway field
 473    is considered a match.
 474
 475    Thus, any records obtained under unverified conditions (e.g., no
 476    DNSSEC or trusted path to source) that have a non-null gateway field
 477    MUST be ignored.
 478
 479    This restriction eliminates attacks against the gateway field, which
 480    are considered much easier, as the attack does not need to be on the
 481    forwarding path.
 482
 483    In the case of an IPSECKEY RR with a value of three in its gateway
 484    type field, the gateway field contains a domain name.  The subsequent
 485    query required to translate that name into an IP address or IPSECKEY
 486    RR will also be subject to man-in-the-middle attacks.  If the
 487    end-to-end integrity of this second query is suspect, then the
 488    provisions above also apply.  The IPSECKEY RR MUST be ignored
 489    whenever the resulting gateway does not match the QNAME of the
 490    original IPSECKEY RR query.
 491
 492 5.  IANA Considerations
 493
 494    This document updates the IANA Registry for DNS Resource Record Types
 495    by assigning type 45 to the IPSECKEY record.
 496
 497    This document creates two new IANA registries, both specific to the
 498    IPSECKEY Resource Record:
 499
 500    This document creates an IANA registry for the algorithm type field.
 501
 502
 503
 504
 505
 506 Richardson                  Standards Track                     [Page 9]
 507 \f
 508 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 509
 510
 511    Values 0, 1, and 2 are defined in Section 2.4.  Algorithm numbers 3
 512    through 255 can be assigned by IETF Consensus (see RFC 2434 [5]).
 513
 514    This document creates an IANA registry for the gateway type field.
 515
 516    Values 0, 1, 2, and 3 are defined in Section 2.3.  Gateway type
 517    numbers 4 through 255 can be assigned by Standards Action (see RFC
 518    2434 [5]).
 519
 520 6.  Acknowledgements
 521
 522    My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
 523    Austein, and Olafur Gudmundsson, who reviewed this document
 524    carefully.  Additional thanks to Olafur Gurmundsson for a reference
 525    implementation.
 526
 527 7.  References
 528
 529 7.1.  Normative References
 530
 531    [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
 532         13, RFC 1034, November 1987.
 533
 534    [2]  Mockapetris, P., "Domain names - implementation and
 535         specification", STD 13, RFC 1035, November 1987.
 536
 537    [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 538         Levels", BCP 14, RFC 2119, March 1997.
 539
 540    [4]  Eastlake 3rd, D. and C. Kaufman, "Domain Name System Security
 541         Extensions", RFC 2065, January 1997.
 542
 543    [5]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 544         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 545
 546    [6]  Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
 547         RFC 3548, July 2003.
 548
 549 7.2.  Informative References
 550
 551    [7]  Piper, D., "The Internet IP Security Domain of Interpretation
 552         for ISAKMP", RFC 2407, November 1998.
 553
 554    [8]  Eastlake 3rd, D., "Domain Name System Security Extensions", RFC
 555         2535, March 1999.
 556
 557    [9]  Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name System
 558         (DNS)", RFC 2536, March 1999.
 559
 560
 561
 562 Richardson                  Standards Track                    [Page 10]
 563 \f
 564 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 565
 566
 567    [10] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain
 568         Name System (DNS)", RFC 3110, May 2001.
 569
 570    [11] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
 571         Record (RR)", RFC 3445, December 2002.
 572
 573    [12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS
 574         Extensions to Support IP Version 6", RFC 3596, October 2003.
 575
 576 Author's Address
 577
 578    Michael C. Richardson
 579    Sandelman Software Works
 580    470 Dawson Avenue
 581    Ottawa, ON  K1Z 5V7
 582    CA
 583
 584    EMail: mcr@sandelman.ottawa.on.ca
 585    URI:   http://www.sandelman.ottawa.on.ca/
 586
 587
 588
 589
 590
 591
 592
 593
 594
 595
 596
 597
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616
 617
 618 Richardson                  Standards Track                    [Page 11]
 619 \f
 620 RFC 4025          Storing IPsec Keying Material in DNS     February 2005
 621
 622
 623 Full Copyright Statement
 624
 625    Copyright (C) The Internet Society (2005).
 626
 627    This document is subject to the rights, licenses and restrictions
 628    contained in BCP 78, and except as set forth therein, the authors
 629    retain all their rights.
 630
 631    This document and the information contained herein are provided on an
 632    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 633    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 634    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 635    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 636    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 637    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 638
 639 Intellectual Property
 640
 641    The IETF takes no position regarding the validity or scope of any
 642    Intellectual Property Rights or other rights that might be claimed to
 643    pertain to the implementation or use of the technology described in
 644    this document or the extent to which any license under such rights
 645    might or might not be available; nor does it represent that it has
 646    made any independent effort to identify any such rights.  Information
 647    on the IETF's procedures with respect to rights in IETF Documents can
 648    be found in BCP 78 and BCP 79.
 649
 650    Copies of IPR disclosures made to the IETF Secretariat and any
 651    assurances of licenses to be made available, or the result of an
 652    attempt made to obtain a general license or permission for the use of
 653    such proprietary rights by implementers or users of this
 654    specification can be obtained from the IETF on-line IPR repository at
 655    http://www.ietf.org/ipr.
 656
 657    The IETF invites any interested party to bring to its attention any
 658    copyrights, patents or patent applications, or other proprietary
 659    rights that may cover technology that may be required to implement
 660    this standard.  Please address the information to the IETF at ietf-
 661    ipr@ietf.org.
 662
 663 Acknowledgement
 664
 665    Funding for the RFC Editor function is currently provided by the
 666    Internet Society.
 667
 668
 669
 670
 671
 672
 673
 674 Richardson                  Standards Track                    [Page 12]
 675 \f