doc/draft-richardson-ipsec-rr.txt

   1
   2
   3 IPSECKEY WG                                                M. Richardson
   4 Internet-Draft                                                       SSW
   5 Expires: March 4, 2004                                 September 4, 2003
   6
   7
   8            A method for storing IPsec keying material in DNS.
   9                      draft-ietf-ipseckey-rr-07.txt
  10
  11 Status of this Memo
  12
  13    This document is an Internet-Draft and is in full conformance with
  14    all provisions of Section 10 of RFC2026.
  15
  16    Internet-Drafts are working documents of the Internet Engineering
  17    Task Force (IETF), its areas, and its working groups.  Note that
  18    other groups may also distribute working documents as Internet-
  19    Drafts.
  20
  21    Internet-Drafts are draft documents valid for a maximum of six months
  22    and may be updated, replaced, or obsoleted by other documents at any
  23    time.  It is inappropriate to use Internet-Drafts as reference
  24    material or to cite them other than as "work in progress."
  25
  26    The list of current Internet-Drafts can be accessed at http://
  27    www.ietf.org/ietf/1id-abstracts.txt.
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  32    This Internet-Draft will expire on March 4, 2004.
  33
  34 Copyright Notice
  35
  36    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  37
  38 Abstract
  39
  40    This document describes a new resource record for DNS.  This record
  41    may be used to store public keys for use in IPsec systems.
  42
  43    This record replaces the functionality of the sub-type #1 of the KEY
  44    Resource Record, which has been obsoleted by RFC3445.
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Richardson                Expires March 4, 2004                 [Page 1]
  56 \f
  57 Internet-Draft                   ipsecrr                  September 2003
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  63    1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  64    1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . .  3
  65    2.  Storage formats  . . . . . . . . . . . . . . . . . . . . . . .  4
  66    2.1 IPSECKEY RDATA format  . . . . . . . . . . . . . . . . . . . .  4
  67    2.2 RDATA format - precedence  . . . . . . . . . . . . . . . . . .  4
  68    2.3 RDATA format - algorithm type  . . . . . . . . . . . . . . . .  4
  69    2.4 RDATA format - gateway type  . . . . . . . . . . . . . . . . .  4
  70    2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . .  5
  71    2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . .  5
  72    3.  Presentation formats . . . . . . . . . . . . . . . . . . . . .  7
  73    3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . .  7
  74    3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
  75    4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
  76    4.1 Active attacks against unsecured IPSECKEY resource records . .  9
  77    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
  78    6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
  79        Normative references . . . . . . . . . . . . . . . . . . . . . 13
  80        Non-normative references . . . . . . . . . . . . . . . . . . . 14
  81        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
  82        Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Richardson                Expires March 4, 2004                 [Page 2]
 112 \f
 113 Internet-Draft                   ipsecrr                  September 2003
 114
 115
 116 1. Introduction
 117
 118    The type number for the IPSECKEY RR is TBD.
 119
 120 1.1 Overview
 121
 122    The IPSECKEY resource record (RR) is used to publish a public key
 123    that is to be associated with a Domain Name System (DNS) name for use
 124    with the IPsec protocol suite.  This can be the  public key of a
 125    host, network, or application (in the case of per-port keying).
 126
 127    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 128    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 129    document are to be interpreted as described in RFC2119 [8].
 130
 131 1.2 Usage Criteria
 132
 133    An IPSECKEY resource record SHOULD be used in combination with DNSSEC
 134    unless some other means of authenticating the IPSECKEY resource
 135    record is available.
 136
 137    It is expected that there will often be multiple IPSECKEY resource
 138    records at the same name.  This will be due to the presence of
 139    multiple gateways and the need to rollover keys.
 140
 141    This resource record is class independent.
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Richardson                Expires March 4, 2004                 [Page 3]
 168 \f
 169 Internet-Draft                   ipsecrr                  September 2003
 170
 171
 172 2. Storage formats
 173
 174 2.1 IPSECKEY RDATA format
 175
 176    The RDATA for an IPSECKEY RR consists of a precedence value, a public
 177    key, algorithm type, and an optional gateway address.
 178
 179        0                   1                   2                   3
 180        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
 181       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 182       |  precedence   | gateway type  |  algorithm  |     gateway     |
 183       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+                 +
 184       ~                            gateway                            ~
 185       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 186       |                                                               /
 187       /                          public key                           /
 188       /                                                               /
 189       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 190
 191
 192 2.2 RDATA format - precedence
 193
 194    This is an 8-bit precedence for this record.  This is interpreted in
 195    the same way as the PREFERENCE field described in section 3.3.9 of
 196    RFC1035 [2].
 197
 198    Gateways listed in IPSECKEY records with  lower precedence are to be
 199    attempted first.  Where there is a tie in precedence, the order
 200    should be non-deterministic.
 201
 202 2.3 RDATA format - algorithm type
 203
 204    The algorithm type field identifies the public key's cryptographic
 205    algorithm and determines the format of the public key field.
 206
 207    A value of 0 indicates that no key is present.
 208
 209    The following values are defined:
 210
 211    1  A DSA key is present, in the format defined in RFC2536 [11]
 212
 213    2  A RSA key is present, in the format defined in RFC3110 [12]
 214
 215
 216 2.4 RDATA format - gateway type
 217
 218    The gateway type field indicates the format of the information that
 219    is stored in the gateway field.
 220
 221
 222
 223 Richardson                Expires March 4, 2004                 [Page 4]
 224 \f
 225 Internet-Draft                   ipsecrr                  September 2003
 226
 227
 228    The following values are defined:
 229
 230    0  No gateway is present
 231
 232    1  A 4-byte IPv4 address is present
 233
 234    2  A 16-byte IPv6 address is present
 235
 236    3  A wire-encoded domain name is present.  The wire-encoded format is
 237       self-describing, so the length is implicit.  The domain name MUST
 238       NOT be compressed.
 239
 240
 241 2.5 RDATA format - gateway
 242
 243    The gateway field indicates a gateway to which an IPsec tunnel may be
 244    created in order to reach the entity named by this resource record.
 245
 246    There are three formats:
 247
 248    A 32-bit IPv4 address is present in the gateway field.  The data
 249    portion is an IPv4 address as described in section 3.4.1 of RFC1035
 250    [2].  This is a 32-bit number in network byte order.
 251
 252    A 128-bit IPv6 address is present in the gateway field.  The data
 253    portion is an IPv6 address as described in section 2.2 of RFC1886
 254    [7].  This is a 128-bit number in network byte order.
 255
 256    The gateway field is a normal wire-encoded domain name, as described
 257    in section 3.3 of RFC1035 [2].  Compression MUST NOT be used.
 258
 259 2.6 RDATA format - public keys
 260
 261    Both of the public key types defined in this document (RSA and DSA)
 262    inherit their public key formats from the corresponding KEY RR
 263    formats.  Specifically, the public key field contains the algorithm-
 264    specific portion of the KEY RR RDATA, which is all of the KEY RR DATA
 265    after the first four octets.  This is the same portion of the KEY RR
 266    that must be specified by documents that define a DNSSEC algorithm.
 267    Those documents also specify a message digest to be used for
 268    generation of SIG RRs; that specification is not relevant for
 269    IPSECKEY RR.
 270
 271    Future algorithms, if they are to be used by both DNSSEC (in the KEY
 272    RR) and IPSECKEY, are likely to use the same public key encodings in
 273    both records.  Unless otherwise specified, the IPSECKEY public key
 274    field will contain the algorithm-specific portion of the KEY RR RDATA
 275    for the corresponding algorithm.  The algorithm must still be
 276
 277
 278
 279 Richardson                Expires March 4, 2004                 [Page 5]
 280 \f
 281 Internet-Draft                   ipsecrr                  September 2003
 282
 283
 284    designated for use by IPSECKEY, and an IPSECKEY algorithm type number
 285    (which might be different than the DNSSEC algorithm number) must be
 286    assigned to it.
 287
 288    The DSA key format is defined in RFC2536 [11]
 289
 290    The RSA key format is defined in RFC3110 [12], with the following
 291    changes:
 292
 293    The earlier definition of RSA/MD5 in RFC2065 limited the exponent and
 294    modulus to 2552 bits in length.  RFC3110 extended that limit to 4096
 295    bits for RSA/SHA1 keys.  The IPSECKEY RR imposes no length limit on
 296    RSA public keys, other than the 65535 octet limit imposed by the two-
 297    octet length encoding.  This length extension is applicable only to
 298    IPSECKEY and not to KEY RRs.
 299
 300
 301
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335 Richardson                Expires March 4, 2004                 [Page 6]
 336 \f
 337 Internet-Draft                   ipsecrr                  September 2003
 338
 339
 340 3. Presentation formats
 341
 342 3.1 Representation of IPSECKEY RRs
 343
 344    IPSECKEY RRs may appear in a zone data master file.  The precedence,
 345    gateway type and algorithm and gateway fields are REQUIRED.  The
 346    base64 encoded public key block is OPTIONAL; if not present, then the
 347    public key field of the resource record MUST be construed as being
 348    zero octets in length.
 349
 350    The algorithm field is an unsigned integer.  No mnemonics are
 351    defined.
 352
 353    If no gateway is to be indicated, then the gateway type field MUST be
 354    zero, and the gateway field MUST be "."
 355
 356    The Public Key field is represented as a Base64 encoding of the
 357    Public Key.  Whitespace is allowed within the Base64 text.  For a
 358    definition of Base64 encoding, see RFC1521 [3] Section 5.2.
 359
 360    The general presentation for the record as as follows:
 361
 362    IN     IPSECKEY ( precedence gateway-type algorithm
 363                      gateway base64-encoded-public-key )
 364
 365
 366 3.2 Examples
 367
 368    An example of a node 192.0.2.38 that will accept IPsec tunnels on its
 369    own behalf.
 370
 371    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
 372                     192.0.2.38
 373                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 374
 375    An example of a node, 192.0.2.38 that has published its key only.
 376
 377    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 0 2
 378                     .
 379                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 380
 381    An example of a node, 192.0.2.38 that has delegated authority to the
 382    node 192.0.2.3.
 383
 384    38.2.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 1 2
 385                     192.0.2.3
 386                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 387
 388
 389
 390
 391 Richardson                Expires March 4, 2004                 [Page 7]
 392 \f
 393 Internet-Draft                   ipsecrr                  September 2003
 394
 395
 396    An example of a node, 192.0.1.38 that has delegated authority to the
 397    node with the identity "mygateway.example.com".
 398
 399    38.1.0.192.in-addr.arpa. 7200 IN     IPSECKEY ( 10 3 2
 400                     mygateway.example.com.
 401                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 402
 403    An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has
 404    delegated authority to the node 2001:0DB8:c000:0200:2::1
 405
 406    $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int.
 407    0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN     IPSECKEY ( 10 2 2
 408                     2001:0DB8:0:8002::2000:1
 409                     AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Richardson                Expires March 4, 2004                 [Page 8]
 448 \f
 449 Internet-Draft                   ipsecrr                  September 2003
 450
 451
 452 4. Security Considerations
 453
 454    This entire memo pertains to the provision of public keying material
 455    for use by key management protocols such as ISAKMP/IKE (RFC2407) [9].
 456
 457    The IPSECKEY resource record contains information that SHOULD be
 458    communicated to the end client in an integral fashion - i.e.  free
 459    from modification.  The form of this channel is up to the consumer of
 460    the data - there must be a trust relationship between the end
 461    consumer of this resource record and the server.  This relationship
 462    may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to
 463    another secure source, a secure local channel on the host, or some
 464    combination of the above.
 465
 466    The keying material provided by the IPSECKEY resource record is not
 467    sensitive to passive attacks.  The keying material may be freely
 468    disclosed to any party without any impact on the security properties
 469    of the resulting IPsec session: IPsec and IKE provide for defense
 470    against both active and passive attacks.
 471
 472    Any user of this resource record MUST carefully document their trust
 473    model, and why the trust model of DNSSEC is appropriate, if that is
 474    the secure channel used.
 475
 476 4.1 Active attacks against unsecured IPSECKEY resource records
 477
 478    This section deals with active attacks against the DNS.  These
 479    attacks require that DNS requests and responses be intercepted and
 480    changed.  DNSSEC is designed to defend against attacks of this kind.
 481
 482    The first kind of active attack is when the attacker replaces the
 483    keying material with either a key under its control or with garbage.
 484
 485    If the attacker is not able to mount a subsequent man-in-the-middle
 486    attack on the IKE negotiation after replacing the public key, then
 487    this will result in a denial of service, as the authenticator used by
 488    IKE would fail.
 489
 490    If the attacker is able to both to mount active attacks against DNS
 491    and is also in a position to perform a man-in-the-middle attack on
 492    IKE and IPsec negotiations, then the attacker will be in a position
 493    to compromise the resulting IPsec channel.  Note that an attacker
 494    must be able to perform active DNS attacks on both sides of the IKE
 495    negotiation in order for this to succeed.
 496
 497    The second kind of active attack is one in which the attacker
 498    replaces the the gateway address to point to a node under the
 499    attacker's control.  The attacker can then either replace the public
 500
 501
 502
 503 Richardson                Expires March 4, 2004                 [Page 9]
 504 \f
 505 Internet-Draft                   ipsecrr                  September 2003
 506
 507
 508    key or remove it, thus providing an IPSECKEY record of its own to
 509    match the gateway address.
 510
 511    This later form creates a simple man-in-the-middle since the attacker
 512    can then create a second tunnel to the real destination.  Note that,
 513    as before, this requires that the attacker also mount an active
 514    attack against the responder.
 515
 516    Note that the man-in-the-middle can not just forward cleartext
 517    packets to the original destination.  While the destination may be
 518    willing to speak in the clear, replying to the original sender, the
 519    sender will have already created a policy expecting ciphertext.
 520    Thus, the attacker will need to intercept traffic from both sides.
 521    In some cases, the attacker may be able to accomplish the full
 522    intercept by use of Network Addresss/Port Translation (NAT/NAPT)
 523    technology.
 524
 525    Note that the danger here only applies to cases where the gateway
 526    field of the IPSECKEY RR indicates a different entity than the owner
 527    name of the IPSECKEY RR.  In cases where the end-to-end integrity of
 528    the IPSECKEY RR is suspect, the end client MUST restrict its use of
 529    the IPSECKEY RR to cases where the RR owner name matches the content
 530    of the gateway field.
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Richardson                Expires March 4, 2004                [Page 10]
 560 \f
 561 Internet-Draft                   ipsecrr                  September 2003
 562
 563
 564 5. IANA Considerations
 565
 566    This document updates the IANA Registry for DNS Resource Record Types
 567    by assigning type X to the IPSECKEY record.
 568
 569    This document creates an IANA registry for the algorithm type field.
 570
 571    Values 0, 1 and 2 are defined in Section 2.3.  Algorithm numbers 3
 572    through 255 can be assigned by IETF Consensus (see RFC2434 [6]).
 573
 574    This document creates an IANA registry for the gateway type field.
 575
 576    Values 0, 1, 2 and 3 are defined in Section 2.4.  Algorithm numbers 4
 577    through 255 can be assigned by Standards Action (see RFC2434 [6]).
 578
 579
 580
 581
 582
 583
 584
 585
 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 Richardson                Expires March 4, 2004                [Page 11]
 616 \f
 617 Internet-Draft                   ipsecrr                  September 2003
 618
 619
 620 6. Acknowledgments
 621
 622    My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob
 623    Austein, and Olafur Gurmundsson who reviewed this document carefully.
 624    Additional thanks to Olafur Gurmundsson for a reference
 625    implementation.
 626
 627
 628
 629
 630
 631
 632
 633
 634
 635
 636
 637
 638
 639
 640
 641
 642
 643
 644
 645
 646
 647
 648
 649
 650
 651
 652
 653
 654
 655
 656
 657
 658
 659
 660
 661
 662
 663
 664
 665
 666
 667
 668
 669
 670
 671 Richardson                Expires March 4, 2004                [Page 12]
 672 \f
 673 Internet-Draft                   ipsecrr                  September 2003
 674
 675
 676 Normative references
 677
 678    [1]  Mockapetris, P., "Domain names - concepts and facilities", STD
 679         13, RFC 1034, November 1987.
 680
 681    [2]  Mockapetris, P., "Domain names - implementation and
 682         specification", STD 13, RFC 1035, November 1987.
 683
 684    [3]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
 685         Extensions) Part One: Mechanisms for Specifying and Describing
 686         the Format of Internet Message Bodies", RFC 1521, September
 687         1993.
 688
 689    [4]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
 690         9, RFC 2026, October 1996.
 691
 692    [5]  Eastlake, D. and C. Kaufman, "Domain Name System Security
 693         Extensions", RFC 2065, January 1997.
 694
 695    [6]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 696         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 697
 698
 699
 700
 701
 702
 703
 704
 705
 706
 707
 708
 709
 710
 711
 712
 713
 714
 715
 716
 717
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727 Richardson                Expires March 4, 2004                [Page 13]
 728 \f
 729 Internet-Draft                   ipsecrr                  September 2003
 730
 731
 732 Non-normative references
 733
 734    [7]   Thomson, S. and C. Huitema, "DNS Extensions to support IP
 735          version 6", RFC 1886, December 1995.
 736
 737    [8]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
 738          Levels", BCP 14, RFC 2119, March 1997.
 739
 740    [9]   Piper, D., "The Internet IP Security Domain of Interpretation
 741          for ISAKMP", RFC 2407, November 1998.
 742
 743    [10]  Eastlake, D., "Domain Name System Security Extensions", RFC
 744          2535, March 1999.
 745
 746    [11]  Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
 747          (DNS)", RFC 2536, March 1999.
 748
 749    [12]  Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
 750          System (DNS)", RFC 3110, May 2001.
 751
 752    [13]  Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource
 753          Record (RR)", RFC 3445, December 2002.
 754
 755
 756 Author's Address
 757
 758    Michael C. Richardson
 759    Sandelman Software Works
 760    470 Dawson Avenue
 761    Ottawa, ON  K1Z 5V7
 762    CA
 763
 764    EMail: mcr@sandelman.ottawa.on.ca
 765    URI:   http://www.sandelman.ottawa.on.ca/
 766
 767
 768
 769
 770
 771
 772
 773
 774
 775
 776
 777
 778
 779
 780
 781
 782
 783 Richardson                Expires March 4, 2004                [Page 14]
 784 \f
 785 Internet-Draft                   ipsecrr                  September 2003
 786
 787
 788 Full Copyright Statement
 789
 790    Copyright (C) The Internet Society (2003).  All Rights Reserved.
 791
 792    This document and translations of it may be copied and furnished to
 793    others, and derivative works that comment on or otherwise explain it
 794    or assist in its implementation may be prepared, copied, published
 795    and distributed, in whole or in part, without restriction of any
 796    kind, provided that the above copyright notice and this paragraph are
 797    included on all such copies and derivative works.  However, this
 798    document itself may not be modified in any way, such as by removing
 799    the copyright notice or references to the Internet Society or other
 800    Internet organizations, except as needed for the purpose of
 801    developing Internet standards in which case the procedures for
 802    copyrights defined in the Internet Standards process must be
 803    followed, or as required to translate it into languages other than
 804    English.
 805
 806    The limited permissions granted above are perpetual and will not be
 807    revoked by the Internet Society or its successors or assigns.
 808
 809    This document and the information contained herein is provided on an
 810    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 811    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 812    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 813    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 814    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 815
 816 Acknowledgement
 817
 818    Funding for the RFC Editor function is currently provided by the
 819    Internet Society.
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839 Richardson                Expires March 4, 2004                [Page 15]
 840 \f