[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
MARID                                                         D. Crocker
Internet-Draft                               Brandenburg InternetWorking
Expires: August 19, 2005                                       J. Leslie
                                                                 D. Otis
                                            Mail Abuse Prevention System
                                                       February 18, 2005

                   Certified Server Validation (CSV)

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).


   Internet mail relies on exchanges between systems that have made no
   prior arrangement with each other.  Widespread abuse of the email
   system has led operators to demand accountability for the email their
   receiving SMTP servers are being asked to process.  Certified Server

Crocker, et al.         Expires August 19, 2005                 [Page 1]

Internet-Draft                  Mail-CSV                   February 2005

   Validation (CSV) provides an economical service that permits a
   receiving SMTP server to decide whether a sending SMTP client is
   likely to produce well-behaved traffic, or at least to decide whether
   the client is sufficiently accountable for its actions.  CSV provides
   a small, simple and useful improvement to Internet mail service
   accountability.  It builds upon the existing practise of service
   providers that accredit the networks from which sending systems are

Table of Contents

   1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Background . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Service Goal . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   4.1 Assessing Authorization  . . . . . . . . . . . . . . . . . . .  7
   4.2 Assessing Accreditation  . . . . . . . . . . . . . . . . . . .  8
   5.  Certified Server Validation Details  . . . . . . . . . . . . .  9
   5.1 Assessing Authorization  . . . . . . . . . . . . . . . . . . .  9
   5.2 Assessing Accreditation  . . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.1 References - Normative . . . . . . . . . . . . . . . . . . . . 11
   7.2 References - Informative . . . . . . . . . . . . . . . . . . . 12
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
   B.  Host Name Authentication . . . . . . . . . . . . . . . . . . . 13
   B.1 DNS-based Mapping  . . . . . . . . . . . . . . . . . . . . . . 14
   B.2 Reverse DNS  . . . . . . . . . . . . . . . . . . . . . . . . . 14
   B.3 Forward DNS Lookup . . . . . . . . . . . . . . . . . . . . . . 15
       Intellectual Property and Copyright Statements . . . . . . . . 16

Crocker, et al.         Expires August 19, 2005                 [Page 2]

Internet-Draft                  Mail-CSV                   February 2005

1.  Overview

   CSV considers two questions at the start of each SMTP session:

      Does a domain's management authorize the connecting, client MTA to
      be sending email?

      Do independent accreditation services consider that domain's
      policies and practices sufficient for controlling email abuse?

   To validate an SMTP session from an unknown sending SMTP client using
   CSV, a typical sequence for the receiving SMTP server is:

   1.  Obtain the remote IP address of the TCP connection.

   2.  Extract the domain name from the EHLO command sent by the SMTP

   3.  Query a chosen Accreditation Service for the EHLO domain name
       (see [ID-CSVDNA])

   4.  Query DNS for a SRV record under the EHLO domain name (see

   5.  Check the SRV reply for flags returned, and check for a match in
       the list of returned IP addresses

   6.  Determines the level of trust to give to the sending SMTP client,
       based on the results of (3) and (5)

   Using whatever thresholds are set by the receiving site's policies:

   o  If the level of trust is high enough, process all email from that
      session in the traditional manner, delivering or forwarding
      without the need for further validation.

   o  If the level of trust is too low, return an error showing the
      reason for not trusting the sending SMTP client.

   o  If the level of trust is in between, document the result in a
      header in each email delivered or forwarded, and/or perform
      additional checks.


      Terminology conforms to [ID-mail-arch].

Crocker, et al.         Expires August 19, 2005                 [Page 3]

Internet-Draft                  Mail-CSV                   February 2005


      The venue for discussing this proposal is the CLEAR mailing list:

   Changes from previous Internet-Draft version:

      replaces "Client SMTP Validation" with "Certified Server
      Validation".  updates the date.

      refers to the example in the Overview as "a typical sequence",
      changing à third-person verbs to second-person verbs in items 1-5
      (but not 6).

      changes the venue for discussion to CLEAR.

      adds a few inconsequential words to Section 2 paragraph 8.

      applies third-level number in section 4.

      adds text to Section 5 stating that CSV can be used without DNA.

2.  Background

   Internet mail suffers from the operation of hosts acting as mail
   transfer agents (MTA) without any meaningful cross-net
   accountability.  This makes it impossible to vet MTAs or find
   recourse when their operations cause problems.  Many of these hosts
   have been compromised and have been turned into unwilling
   participants in large networks of hostile MTAs that send spam and
   worms, and contribute to denial of service attacks.

   When a server MTA receives a connection, it decides whether to accept
   the message traffic that is being sent to it, trusting that its
   delivery will not be problematic to the operation of the provider or
   their users.  How can it do this, when operating in the open
   Internet? Certified Server Validation (CSV) defines a service that
   permits the receiving SMTP server to decide whether messages sent by
   the sending SMTP client are likely to be well-behaved, or at least to
   decide whether that client is sufficiently accountable for its

   The process of deciding on this trust of the client requires
   performing a series of conceptually discrete steps:

Crocker, et al.         Expires August 19, 2005                 [Page 4]

Internet-Draft                  Mail-CSV                   February 2005


      What is the "name" of the client to be trusted? How is it

      CSV uses the domain name supplied by a client in the SMTP HELO/


      Is the client MTA legitimately associated with that name? Can we
      prove that the client is who it purports to be?

      By finding the sending SMTP client's actual IP address, in the
      list of IP addresses returned by a DNS Address query on the EHLO
      domain-name, CSV satisfies the minimal authentication needs of
      this task.


      Is the remote host permitted to act as a sending SMTP client? Has
      the domain management authorized it to perform this function?

      CSV specifies a DNS-based record that states whether an associated
      host has permission to operate as a client MTA.


      What is the trust that is to be extended to the entity that
      authorized the sending SMTP client? Does the receiving SMTP server
      have a basis for deciding that the entity providing authorization
      for the client MTA can, itself, be trusted to make accountable

      CSV defines a DNS record that permits domains to announce the
      accreditation services in which they are listed.  It also defines
      a separate record by which accreditation services publish their
      assessments of sending domains.

   A proposal or its implementation well might combine some of these
   steps.  However it is important to consider them independently, in
   order to ensure that the proposal specifies that they are performed
   in a valid manner, or at least that the constraints of the proposal
   are clear for each of these conceptual functions.  This specification
   distinguishes each of these logical steps and defines their operation
   separately.  It is based on validation of the EHLO domain name.  The
   proposed mechanism is small, simple and useful.  In particular it
   permits detecting machines that are prohibited from acting as Client

Crocker, et al.         Expires August 19, 2005                 [Page 5]

Internet-Draft                  Mail-CSV                   February 2005

   MTAs and those that are permitted.  The mechanism is designed to be
   useful between peer MTAs and only requires use of well-established

   Address-based Accreditation:

      Service providers often maintain lists of remote networks that are
      known to be trustworthy or untrustworthy as sending SMTP clients.
      Typically, these lists are based on the use of IP Addresses of the
      clients.  The IP Addresses serve as identifiers.  The list
      specifies positive or negative authorization, and the source of
      the list is an organization that the operator of the receiving
      SMTP server deems worthy to assess other sites.

      When used in this way, IP Addresses are authenticated by relying
      on their use in the IP routing infrastructure.  Packets are routed
      to the specified IP Address, over the open Internet.  A continuing
      TCP session using that IP Address is therefore presumed to be an
      interaction with the host legitimately associated with that IP

      Increased topological, transfer and access complexities on the
      Internet are making IP Addresses increasingly problematic for use
      as persistent identifiers.  Instead they are viewed as appropriate
      only for the most transient task of delivering individual packets.

   CSV builds upon this popular model.  Besides the considerable benefit
   of having operational practice, the model can be extremely efficient.
   It permits the service provider to assess the source of an entire
   message stream, rather than having to evaluate each message.  Also,
   CSV makes its assessment before messages cross the Internet, thereby
   saving bandwidth and reducing the impact of a distributed denial of
   service attack.

3.  Service Goal

   CSV verifies that a host is authorized to act as an SMTP client and
   that the client is likely to be operated acceptably.  CSV enhances
   current practice with:

   o  Identification by persistent domain name rather than transient IP

   o  A standardized method of documenting authorization to operate as a
      sending SMTP client.

   o  A standardized method of referencing accreditation services.

Crocker, et al.         Expires August 19, 2005                 [Page 6]

Internet-Draft                  Mail-CSV                   February 2005

   o  A standardized method of querying an accreditation service.

4.  Requirements

4.1  Assessing Authorization

   For a receiving SMTP server to determine whether a host has
   authorization to act as a sending SMTP client, it is necessary to
   identify the host and verify its association with that identity.
   Given that, a DNS query on the name can return an explicit

4.1.1  Identification

   The means of identifying a remote host or service requires uniqueness
   and is aided by persistence.  The identifier must not be ambiguous
   and its use is made far more efficient if it is stable over time.
   The two usual choices are IP Addresses and Domain Names.

   An IP Address typically refers to a single host and can change
   relatively frequently, as the host's connection to the Internet
   changes.  IP Addresses are reported by the Internet infrastructure
   and for simple security requirements, transactional use of an IP
   Address through the Internet's routing fabric is taken as validation
   of the Address.

   Domain Names are longer-lived but require new administrative effort.
   They can be used to refer to multiple hosts simultaneously.  The DNS
   administrator for a domain will maintain record(s) listing one or
   more IP addresses associated with that name, even though reverse-DNS
   records (not controlled by the same DNS administrator) may give
   conflicting information.  The forward-DNS is considered the valid
   authority for CSV purposes.  Therefore, authentication of a domain
   name's reference to a particular IP Address requires an explicit
   authentication step.

4.1.2  Authentication

   If the sending SMTP client of a connection can be authenticated, then
   it is possible to develop an accountability mechanism based on that
   authentication.  MUA-MSA exchanges have a substantial number of
   useful authentication mechanisms available.  These are often very
   strong, and involve significant prior arrangement.  The same holds
   true for MDA-MUA exchanges, and often for MSA-MTA and MTA-MDA
   exchanges, such as within an organization's local network.

   What is missing is a useful means of authenticating MTA-MTA exchanges

Crocker, et al.         Expires August 19, 2005                 [Page 7]

Internet-Draft                  Mail-CSV                   February 2005

   over the open Internet.  Prior arrangement between such a pair of
   MTAs is antithetical to the history and operation of Internet mail.
   Spontaneous communications are at the core of Internet design and
   operation.  So the challenge is to develop an authentication
   mechanism that permits the necessary amount of accountability,
   without imposing undue overhead or restrictions.

   A number of strong authentication mechanisms are possible, but none
   has yet attained widespread adoption among MTAs with no prior
   relationship.  CSV specifies a weaker authentication scheme that
   meets the modest requirements for this service.  Stronger methods can
   be supported later, if necessary.  However they must be tied to a
   domain name and must not require any prior relationship.

4.1.3  Authorization

   Internet operation has typically required no public mechanism for
   restricting or permitting particular hosts to operate clients or
   servers for particular services on behalf of particular domains.  The
   DNS MX record states where to route email that is destined for a
   specific domain; this implies a degree of authorization for the host
   referenced in the MX.  However the record is really for routing and
   there is no equivalent means of specifying authorization of other
   hosts that might act as email relays.  Similarly there is no means
   for checking the authorization of World Wide Web servers, DNS
   servers, telnet clients or other Internet applications.

   What is missing is an open, interoperable means by which accountable
   domain management can announce its authorization of a particular host
   to operate a particular service.  CSV defines such a mechanism for
   sending SMTP clients.

4.2  Assessing Accreditation

   This portion of CSV determines accreditations for the sending SMTP
   client or for the administration under which it operates.  The basis
   for deciding that an authorizing agency is, itself, to be trusted can
   be highly varied.  Often, well-established practices are not that
   well-understood.  This makes it difficult to predict what methods of
   accreditation will be most appropriate and successful for Internet
   mail.  It is expected that this portion of an Internet mail
   validation service will therefore need to support be a variety of
   accreditation service styles.

   What is needed is a standard means for:

   o  referencing different accreditation services, and

Crocker, et al.         Expires August 19, 2005                 [Page 8]

Internet-Draft                  Mail-CSV                   February 2005

   o  querying a service to obtain information about the domain it is

5.  Certified Server Validation Details

   CSV defines a mechanism for session-time, domain-based validation of
   a sending SMTP client.  It is useful across the open Internet,
   between MTAs that have made no prior arrangement with each other.
   Validation establishes that the operation of the MTA is authorized by
   an accredited administrator of the declared domain name.

   The validation requirements are modest, because the system does not
   seek to provide long-term vetting of the client host, nor does it
   assess the actual content being exchanged.  Techniques that would be
   wholly inadequate for classic, strong authentication and validation
   can be entirely sufficient for CSV's needs.

   Validation has two separate phases: assessing authorization and
   assessing accreditation.  The first is performed between the
   receiving SMTP server and the sending SMTP client.  The second is
   performed between the receiving SMTP server and one or more
   accrediting services.

5.1  Assessing Authorization

   This phase provides a means for a network administrator to publicly
   state what hosts are authorized by it to act as client MTAs.  Absent
   such a statement of authority, it is possible that the client is a
   rogue or compromised host.

   The assessment requires three steps:


      The sending SMTP client host is identified by a Domain Name.  The
      domain name serves as a unique, topologically-independent,
      persistent identifier that is registered in the Domain Name

      A sending SMTP client MUST supply a published domain name as the
      parameter to an SMTP HELO or EHLO.  The sending SMTP client MAY
      issue multiple EHLO's over the course of a session, such as for
      isolating email flows for accreditation, with different domain
      names to represent different users on the client system.  If an
      EHLO is issued, the entire CSV process MUST be restarted without
      needing to make a new connection.

Crocker, et al.         Expires August 19, 2005                 [Page 9]

Internet-Draft                  Mail-CSV                   February 2005

      For CSV, a sending SMTP client places the domain name into the
      <Domain> field specified for a SMTP HELO or EHLO [RFC2821]
      command.  The domain name is any name under which it is claiming
      authorization to act as a sending SMTP client.  A receiving SMTP
      server will extract this name and use it as the identification for
      the client seeking to send email, upon which CSV assessments are
      then made.


      There is no universal, strong method to authenticate that a host
      is correctly identifying itself.  For most email transport
      purposes, it will be sufficient to show that the EHLO domain name
      forward-resolves to the IP address of the sending SMTP client.

      The response to a CSV authentication query usually includes the
      list of associated IP addresses in the Additional Information
      section.  Formally, this additional information is the same as
      would be obtained from additional queries for that information.  A
      server includes it in the CSV query for efficiency, to avoid
      additional DNS queries.

      If the list is returned and the actual IP address of the sending
      SMTP client is in it, the receiving SMTP server SHOULD consider
      the EHLO domain name to be authenticated.  Conversely, if the list
      is returned and the actual IP address is not in it, the assertion
      of the EHLO domain name SHOULD be considered incorrect, and result
      in an error being returned.


      In CSV, the purpose of authorization is to establish that an
      accountable authority has given permission for the sending SMTP
      client host to operate in that role.

      CSV participants MUST use the Certified Server Authorization
      method, as defined in [ID-CSVCSA].  It specifies a DNS record that
      is associated with the domain name offered by the sending SMTP
      client host.

5.2  Assessing Accreditation

   The CSV authorization phase provides a basis for trusting that the
   sending SMTP client is under the control of a domain's management;
   but this says nothing about the policies and practices of that
   management.  Separate accreditation services are needed for that.  It
   is expected that there will be numerous services that provide

Crocker, et al.         Expires August 19, 2005                [Page 10]

Internet-Draft                  Mail-CSV                   February 2005

   accreditation.  CSV is intended to support use of any service that
   gains credibility among operators of SMTP servers.

   One form of accreditation service is particularly easy to use
   initially: a private list, maintained by the user of the information.
   That is, a receiving SMTP server can manage its own, private list of
   trusted domains.  This is not viable for the long-term, given the
   number of possible, valid client MTAs and the rate of on-going

   Long term use is expected employ queries to independent, third-party
   services.  CSV provides a set of capabilities for using external
   accreditation.  (See "Domain Name Accreditation" in [ID-CSVDNA].)
   Sending SMTP clients SHOULD publish CSV records referring to
   accreditation services in which they are listed.  Accreditation
   services MUST publish DNA-conformant records.

6.  Security Considerations

   CSV defines a security mechanism.  The nature of the security
   requirements for CSV are significantly different from typical,
   "strong" methods required for most Internet security functions.

   The proposal relies on the integrity and authenticity of DNS data.

7.  References

7.1  References - Normative

              Otis, D., Crocker, D. and J. Leslie, "sending SMTP client
              Authorization (CSA)", June 2004.

              Leslie, J., Crocker, D. and D. Otis, "Domain Name
              Accreditation (DNA)", June 2004.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.

   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

Crocker, et al.         Expires August 19, 2005                [Page 11]

Internet-Draft                  Mail-CSV                   February 2005

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

7.2  References - Informative

              Brand, R. and L. Sherzer, "Designated Relays Inquiry
              Protocol (DRIP)", draft-brand-drip-02 (work in progress),
              October 2003.

              Crocker, D., "Internet Mail Architecture", May 2004.

Authors' Addresses

   Dave Crocker
   Brandenburg InternetWorking
   675 Spruce Drive
   Sunnyvale, CA  94086

   Phone: +1.408.246.8253
   EMail: dcrocker@bbiw.net

Crocker, et al.         Expires August 19, 2005                [Page 12]

Internet-Draft                  Mail-CSV                   February 2005

   John Leslie
   10 Souhegan Street
   Milford, NH  03055

   Phone: +1.603.673.6132
   EMail: john@jlc.net

   Douglas Otis
   Mail Abuse Prevention System
   1737 North First Street, Suite 680
   San Jose, CA  94043

   Phone: +1.408.453.6277
   EMail: dotis@mail-abuse.org

Appendix A.  Acknowledgements

   This proposal is similar to DRIP [ID-brand-drip], however it uses a
   different DNS [RFC1035] record.

   Review comments and suggestions, on previous versions of CSV, have
   been made by: Tony Finch, Carl Hutzler, Meng Weng Wong, Greg Connor.

Appendix B.  Host Name Authentication

   The routing infrastructure of the Internet distinguishes hosts by
   their topological attachment, noted as its IP Address.  Because IP
   Addresses change periodically and users prefer references that can be
   mnemonic, hosts on the Internet generally have one or more Domain
   Names (DNS) [RFC1035] assigned to them.  A Domain Name is globally
   unique.  The core function of the DNS is to map from a name supplied
   by the user, to an IP Address associated with that name.  Internet
   protocols often permit a host to identify itself with its domain

   But what if a host is programmed incorrectly, or even maliciously.
   We need a way to authenticate that a host is reporting its name
   correctly.  Establishing this authentication is separate from
   determining its authorization to perform any particular service.
   Until the relationship is authenticated, we cannot apply policies
   associated with the name.

   A number of methods for authenticating the relationship between the
   host and its reported name might be used.  The current CSV

Crocker, et al.         Expires August 19, 2005                [Page 13]

Internet-Draft                  Mail-CSV                   February 2005

   specification supports authentication through Domain Name Service
   mappings between a domain name and an IP Address.  Other equally
   valid methods are possible.  However none has yet proved practical
   for authenticating a client to a server, without prior arrangement
   between them.

B.1  DNS-based Mapping

   The Domain Name System has a common mapping mechanism that can be
   used in a variety of ways, based on the schema for assigning names
   and the types of data listed under those names.  The two most popular
   schemas are forward mapping and Reverse-DNS.  Forward looks up a
   "regular" domain name and receives information about it, such as a
   list of IP Addresses associated with that name.  Reverse DNS starts
   with an IP Address and maps it to a pointer to a "regular" domain

   Often when contacted by a remote host, a host uses a reverse-DNS
   query to get the name of the remote host.  This can be followed by a
   forward-DNS query to see if the name reported by the reverse-DNS
   query matches an IP address reported by the forward-DNS query.  If
   so, this is generally considered an authentication of the
   relationship of the name to the host.  This method is often used by
   receiving SMTP servers to decide whether to trust the sending SMTP

   Closing the circle in this manner permits verifying both that the
   domain assigning the name and the service provider assigning IP
   addresses agree that this is the appropriate name for that remote
   host.  Although this process has known limitations, it is considered
   sufficient for many basic uses.

   Use of an IP Address returned by the DNS is sufficient for
   CSV-related authentication requirements of this service.  However it
   MUST NOT be considered a strong form of authentication as to allow
   otherwise privileged access.  The use of this mechanism is to aid
   selection of accreditation services, such as whether to query using
   the domain name or the client address.  Other measures may be taken
   intended to limit exposure to unknown clients but are beyond the
   scope of this specification.

B.2  Reverse DNS

   Reverse DNS can be used by itself to associate a domain name with an
   IP address.  It indicates that the entity responsible for allocating
   that block of IP addresses has designated an IP address to be used by
   the domain name.  Unfortunately, the reverse-IP branch of the DNS has
   a long history of being poorly maintained, and often does not match

Crocker, et al.         Expires August 19, 2005                [Page 14]

Internet-Draft                  Mail-CSV                   February 2005

   the forward-DNS information even when the relationship of host to
   name is genuine.

   Reverse DNS by itself SHOULD NOT be considered sufficient

B.3  Forward DNS Lookup

   An isolated forward lookup is sufficient for simple sending SMTP
   client authentication, if an IP Address returned for that name
   matches the IP Address reported by the underlying IP service for that
   remote host.  This indicates that the domain in question currently
   designates that IP Address as an IP address entitled to respond for
   that domain name.

Crocker, et al.         Expires August 19, 2005                [Page 15]

Internet-Draft                  Mail-CSV                   February 2005

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Crocker, et al.         Expires August 19, 2005                [Page 16]