[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-dkim-ssp

pre-DKIM                                                       E. Allman
Internet-Draft                                            Sendmail, Inc.
Expires:  April 26, 2006                                       M. Delany
                                                              Yahoo! Inc
                                                               J. Fenton
                                                     Cisco Systems, Inc.
                                                        October 23, 2005


                       DKIM Sender Signing Policy
                        draft-allman-dkim-ssp-01

Status of this Memo

   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 becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 April 26, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   DomainKeys Identified Mail (DKIM) defines a domain-level
   authentication framework for email using public-key cryptography and
   key server technology to permit verification of the source and
   contents of messages by either Mail Transport Agents (MTAs) or Mail
   User Agents (MUAs).  The primary DKIM protocol is described in [ID-



Allman, et al.           Expires April 26, 2006                 [Page 1]

Internet-Draft                  DKIM SSP                    October 2005


   DKIM-BASE].

   This document describes the policy records that senders may use to
   advertise how they sign their outgoing mail, and how verifiers should
   access and interpret those results.

Requirements Language

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

(Unresolved Issues/To Be Done)

   Security Considerations needs further work.

   Need to add new and check existing ABNF.

   DKP RR needs to be defined.

   Text structure of document needs to be examined; this is a quick
   slash-and-burn approach.  Stop signs indicate sections that haven't
   even been approached yet.




























Allman, et al.           Expires April 26, 2006                 [Page 2]

Internet-Draft                  DKIM SSP                    October 2005


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.   Language and Terminology . . . . . . . . . . . . . . . . . .   5
     2.1  Terms Imported from DKIM-Base  . . . . . . . . . . . . . .   5
     2.2  Originator Address . . . . . . . . . . . . . . . . . . . .   5
     2.3  Alleged Signer . . . . . . . . . . . . . . . . . . . . . .   5
     2.4  Alleged Originator . . . . . . . . . . . . . . . . . . . .   6
     2.5  Sender Signing Policy  . . . . . . . . . . . . . . . . . .   6
     2.6  Suspicious . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.7  First Party Signature  . . . . . . . . . . . . . . . . . .   6
     2.8  Third Party Signature  . . . . . . . . . . . . . . . . . .   6
     2.9  Verifier Acceptable Third Party Signature  . . . . . . . .   6
   3.   Operation Overview . . . . . . . . . . . . . . . . . . . . .   7
   4.   Query Mechanism  . . . . . . . . . . . . . . . . . . . . . .   8
   5.   Policy Syntax and Semantics  . . . . . . . . . . . . . . . .   9
   6.   Third Party Signatures and Mailing Lists . . . . . . . . . .  10
     6.1  Verifier Actions . . . . . . . . . . . . . . . . . . . . .  10
     6.2  Mailing List Manager Actions . . . . . . . . . . . . . . .  11
     6.3  Signer Actions . . . . . . . . . . . . . . . . . . . . . .  12
   7.   IANA Considerations  . . . . . . . . . . . . . . . . . . . .  12
   8.   Compliance . . . . . . . . . . . . . . . . . . . . . . . . .  12
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  12
     9.1  Fraudulent Sender Address  . . . . . . . . . . . . . . . .  12
     9.2  DNS Attacks  . . . . . . . . . . . . . . . . . . . . . . .  13
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1   Normative References . . . . . . . . . . . . . . . . . .  13
     10.2   Informational References . . . . . . . . . . . . . . . .  13
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  13
   A.   Change Log . . . . . . . . . . . . . . . . . . . . . . . . .  14
     A.1  Changes since -00  . . . . . . . . . . . . . . . . . . . .  14
        Intellectual Property and Copyright Statements . . . . . . .  15



















Allman, et al.           Expires April 26, 2006                 [Page 3]

Internet-Draft                  DKIM SSP                    October 2005


1.  Introduction

   DomainKeys Identified Mail (DKIM) defines a simple, low cost, and
   effective mechanism by which email messages can be cryptographically
   signed, permitting a signing domain to claim responsibility for the
   use of a given email address.  Message recipients can verify the
   signature by querying the signer's domain directly to retrieve the
   appropriate public key, and thereby confirm that the message was
   attested to by a party in possession of the private key for the
   signing domain.

   However, the legacy of the Internet is such that not all messages
   will be signed, and the absence of a signature on a message is not an
   a priori indication of forgery.  In fact, during early phases of
   deployment it must be expected that most messages will remain
   unsigned.  However, some senders may choose to sign all of their
   outgoing mail, for example, to protect their brand name.  Such
   signers must be able to advertise to verifiers that messages claiming
   to be from them that are not signed are forgeries.  This is the topic
   for sender signing policy.

   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822], the verifier of a message MUST determine whether
   messages from that sender are expected to be signed, and what
   signatures are acceptable.  In particular, whether a domain is
   participating in DKIM, whether they are testing, and whether it signs
   all outbound email must be communicated to the verifier.  Without
   such a mechanism, the benefit of message signing techniques such as
   DKIM is limited since unsigned messages will always need to be
   considered to be potentially legitimate.  This determination is
   referred to as a Sender Signing Policy Check.

   Sender Signing Policies MAY be expressed on behalf of an entity which
   may be a domain or an individual address.  Expression of signing
   policy on behalf of individual addresses will, of course, entail
   additional key server transaction load.

   Conceivably, such policy expressions might be imagined to be extended
   in the future to include information about what hashing algorithms a
   domain uses, what kind of messages might be sent (e.g., bulk vs.
   personal vs. transactional), etc.  Such concerns are out of scope of
   this standard; because of the need for outside auditing they fall
   under the purview of reputation and accreditation.

   This document refers to [ID-DKIM-BASE], which should be read as a
   prerequisite to this document.





Allman, et al.           Expires April 26, 2006                 [Page 4]

Internet-Draft                  DKIM SSP                    October 2005


2.  Language and Terminology

2.1  Terms Imported from DKIM-Base

   Some terminology used herein is derived directly from [ID-DKIM-BASE].
   Briefly,

      o A "Signer" is the agent that signs a message.  In normal cases
      it will probably correspond closely with the original author of
      the message or an agent working on the author's behalf.

      o A "Verifier" is the agent that verifies a message by checking
      the actual signature against the message itself and the public key
      published by the alleged signer.  The Verifier also looks up the
      Sender Signing Policy published by the domain of the Originator
      Address if the message is not correctly signed by the Alleged
      Originator.

      o A "Selector" specifies which of the keys published by a signing
      domain should be queried.  It is essentially a way of subdividing
      the address space to allow a single sending domain to publish
      multiple keys.


2.2  Originator Address

   The "Originator Address" is the email address in the From header
   field of a message [RFC2822], or if and only if the From header field
   contains multiple addresses, the first address in the From header
   field.

      NON-NORMATIVE RATIONALE:  The alternative option when there are
      multiple addresses in the From header field is to use the value of
      the Sender header field.  This would be closer to the semantics
      indicated in [RFC2822] than using the first address in the From
      header field.  However, the large number of deployed Mail User
      Agents that do not display the Sender header field value argues
      against that.  Multiple addresses in the From header field are
      rare in real life.


2.3  Alleged Signer

   An "Alleged Signer" is the identity of the signer claimed in the
   DKIM-Signature header field in a message received by a Verifier; it
   is "alleged" because it has not yet been verified.





Allman, et al.           Expires April 26, 2006                 [Page 5]

Internet-Draft                  DKIM SSP                    October 2005


2.4  Alleged Originator

   An "Alleged Originator" is the Originator Address of a message
   received by a Verifier; it is "alleged" because it has not yet been
   verified.

2.5  Sender Signing Policy

   A "Sender Signing Policy" (or just "policy") is a machine-readable
   record published by the domain of the Alleged Originator which
   includes information about whether that sender signs all, some, or
   none of their email.  It must be considered together with the "key"
   records, which advertise the public keys associated with the Alleged
   Originator.

2.6  Suspicious

   Messages that fail an initial signature verification step (either by
   an incorrect signature or a lack of signature) and also a further
   Sender Signing Policy check are referred to as "Suspicious".  The
   handling of such messages is at the discretion of the verifier or
   final recipient.  "Suspicious" applies only to the DKIM layer; a
   verifier may decide the message should be accepted on the basis of
   other information beyond the scope of this document.  Conversely,
   messages deemed non-Suspicious may be rejected for other reasons.

2.7  First Party Signature

   A First Party Signature is any valid signature where the signer name
   (listed in the "i=" tag if present, otherwise the null address,
   representing an unknown user, followed by "@", followed by the value
   of the "d=" tag) matches the address in the "From" header.  If the
   signer name does not include a local-part, then only the domains must
   match; otherwise, the two addresses must be identical.

2.8  Third Party Signature

   A Third Party Signature is a valid signature where the signer (listed
   in the "i=" tag) does not match the address in the "From" header.

2.9  Verifier Acceptable Third Party Signature

   A Verifier Acceptable Third Party Signature is a Third Party
   Signature that the Verifier is willing to accept as meaningful for
   the message under consideration.  "Accept" means that the Verifier
   will, on the basis of local policy, take an action based on that
   signature, such as matching against a locally maintained allow-list,
   doing an external reputation lookup, or any other local action that



Allman, et al.           Expires April 26, 2006                 [Page 6]

Internet-Draft                  DKIM SSP                    October 2005


   the Verifier deems useful for classifying or otherwise processing the
   message.

   A Verifier SHOULD accept signatures that correspond with addresses in
   the "Sender" header, MAY accept signatures that are for identities
   that the Verifier is certain will be displayed to end users, and MAY
   accept signatures that pass other tests such as accreditation or
   reputation.  Verifiers SHOULD NOT accept signatures from identities
   that have no known relationship with the message other than their
   appearance in the "DKIM-Signature" header.

3.  Operation Overview

   Sender Signing Policy Checks MUST be based on the Originator Address.
   If the message contains a valid signature on behalf of the Originator
   Address no Sender Signing Policy Check need be performed:  the
   verifier SHOULD NOT look up the Sender Signing Policy and the message
   SHOULD be considered non-Suspicious.

   Verifiers checking messages that do not have at least one valid
   signature on behalf of the Originator Address MUST perform a Sender
   Signing Policy Check by doing a lookup for the "_policy" record as
   described in Section 4 from the domain specified by the Originator
   Address.

   The result of a Sender Signing Policy Check is one of four possible
   policies:

      (1) Some messages from this entity are not signed; the message
      SHOULD be presumed to be legitimate in the absence of a valid
      signature.  This is the default policy.

      (2) All messages from this entity are signed; all messages from
      this entity SHOULD have a valid signature, either directly on
      behalf of the originator or on behalf of a third party (e.g., a
      mailing list or an outsourcing house) handling the message.

      (3) All valid messages from this entity are signed, and SHOULD
      have a valid signature from this entity.  Third-party signatures
      SHOULD not be accepted.

      (4) Signing policy for this domain is expressed at the individual
      address level.  A second Sender Signing Policy Check should be
      performed specifying the individual address

   If a message is encountered by a verifier without a valid signature
   from the Originator Address, the policy results MUST be interpreted
   as follows:



Allman, et al.           Expires April 26, 2006                 [Page 7]

Internet-Draft                  DKIM SSP                    October 2005


      If the result of the check is policy (1) described above, the
      message MUST be considered non-Suspicious.

      If the result of the check is policy (2), and any verifiable
      signature is present from some signer other than the Originator
      Address in the message, the message SHOULD be considered non-
      Suspicious.

      If the result of the check is policy (3), the message MUST be
      considered Suspicious.

      If the result of the check is policy (4), a second Sender Signing
      Policy Check SHOULD be performed based on the entire Originator
      Address and interpreted using the above steps.  If the result of
      that check is policy (4), the signing policy for the originator is
      misconfigured, and the message SHOULD be considered non-
      Suspicious.

   If the Sender Signing Policy record does not exist, verifier systems
   MUST assume that some messages from this entity are not signed and
   the message SHOULD NOT be considered to be Suspicious.

4.  Query Mechanism

   Signing policy records for a domain are published in key servers as
   the "_policy" selector.  Signing policy records for individual
   addresses are published as the "<user>._policy" selector.

      NON-NORMATIVE RATIONALE:  Use of a synthetic selector allows non-
      DNS based access for signer policies.

   Initially, the query mechanism defined uses DNS to look up the key
   "<selector>._domainkey.<domain>", where <selector> is either
   "_policy" for the initial lookup or "<user>._policy" for per-user
   lookups, and <domain> is the domain of the Originator Address.  When
   represented in DNS, signing policy checks MUST search for a DKSSP
   (DomainKey Sender Signing Policy) RR type first.  If no DKSSP RR is
   found, signing policy checks MUST search for a TXT RR type.  The
   DKSSP record MUST override the TXT record.

   To avoid a Denial-of-Service attack, signer policy searches for
   signing policy checks of very deeply nested domains MUST strip off
   all but the last five components of a domain name.  If a policy
   record is not found, the verifier MUST repeat the request to
   successively higher levels of the domain hierarchy until the root is
   reached.  This allows subdomains to inherit the signing policy of
   their parent domains without allowing attackers to specify extremely
   deep subdomains such as



Allman, et al.           Expires April 26, 2006                 [Page 8]

Internet-Draft                  DKIM SSP                    October 2005


   "a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z.example.com".
   If presented with such a signing domain in a DKIM-Signature header
   field, the search for a policy record would start at
   "x.y.z.example.com" and proceed upwards.  Verifiers MUST stop
   searching at the first policy record they encounter.

      NON-NORMATIVE DISCUSSION:  It seems like this limitation should be
      part of the DNS binding rather than a general restriction.


5.  Policy Syntax and Semantics

   Signing policy records follow the tag-value syntax described in [ID-
   DKIM-BASE].  Tags used in signing policy records are as follows:

   n= Human readable notes regarding the record (quoted-printable with
      semicolon encoded in addition to the standard characters;
      OPTIONAL, default is no notes).

   o= Outbound signing policy for the entity (plain-text; OPTIONAL,
      default is "~").  Possible values are as follows:

      ~  The entity signs some but not all email.

      -  All mail from the entity is signed; unsigned email MUST NOT be
         accepted, but email signed with a Verifier Acceptable Third
         Party Signature SHOULD be accepted.

      !  All mail from the entity is signed; Third-Party signatures
         SHOULD NOT be accepted

      .  This entity never sends email.  The "." policy can be used to
         "short circuit" searches from subdomains; for example, the
         "ad.jp" domain might use this.  If an initial policy search
         receives this policy then the email SHOULD NOT be accepted; if
         found while searching parent domains then the search should
         terminate as though no policy record was found.

      ^  Repeat query at user level.  This value MUST NOT be used in
         user-level policy records.  A Verifier MUST look up the
         selector for "<user>._policy" where <user> is the local-part of
         the Originator Address (i.e., the portion of the address before
         the "@" character).








Allman, et al.           Expires April 26, 2006                 [Page 9]

Internet-Draft                  DKIM SSP                    October 2005


   r= Email address for reports and inquiries regarding the signing
      policy for this entity (plain-text; OPTIONAL, default is no
      contact address available).

   t= A vertical-bar separated list of flags (plain-text; OPTIONAL,
      default is that no flags are set).  Flag values are:

      y  The entity is testing signing policy, and the verifier SHOULD
         NOT consider a message suspicious based on the record.

   u= Reserved for future reference to a URI to provide more detailed
      policy information.


6.  Third Party Signatures and Mailing Lists

   There are several forms of mailing lists, which interact with signing
   in different ways.

   o  "Verbatim" mailing lists send messages without modification
      whatsoever.  They are often implemented as MTA-based aliases.
      Since they do not modify the message, signatures are unaffected
      and will continue to verify.  There is no reason for the forwarder
      to re-sign the message.

   o  "Digesting" mailing lists collect together one or more postings
      and then retransmit them, often on a nightly basis, to the
      subscription list.  These are essentially entirely new messages
      which must be independently authored (that is, they will have a
      "From" header referring to the list, not the submitters) and
      signed by the Mailing List Manager itself, if they are signed at
      all.

   o  "Resending" mailing lists receive a message, modify it (often to
      add "unsubscribe" information or advertising), and immediately
      resend that message to the subscription list.  They are
      problematic because they usually do not change the "From" header
      of the message, but they do invalidate the signature in the
      process of modifying the message.

   The first two cases act in obvious ways and do not require further
   discussion.  However, the third case is problematic.  The remainder
   of this session applies only to that case.

6.1  Verifier Actions

   Generally speaking, a Verifier SHOULD treat messages as Suspicious
   unless they have a First Party Signature or Verifier Acceptable Third



Allman, et al.           Expires April 26, 2006                [Page 10]

Internet-Draft                  DKIM SSP                    October 2005


   Party Signature.  Since Verifiers SHOULD accept signatures for
   identities listed in the Sender header field, adding such a field is
   the recommended approach for Mailing List Managers.

6.2  Mailing List Manager Actions

   Mailing List Managers should make every effort to ensure that
   messages that they relay and which have valid signatures upon receipt
   also have valid signatures upon retransmission.  In particular,
   Mailing List Managers that modify the message in ways that break
   existing signatures SHOULD:

   o  Verify any existing DKIM Signatures.  A DKIM-aware Mailing List
      Manager MUST NOT re-sign an improperly signed message in such a
      way that would imply that the existing signature is acceptable.
      In particular, a DKIM-aware MLM MUST NOT sign an Authentication-
      Results header field that it can not personally verify, whether
      that header field be added locally or remotely.

         NON-NORMATIVE RATIONALE:  An attacker might send a message
         through a DKIM-aware Mailing List Manager that included an
         existing Authentication-Results header that claims that the MLM
         verified the signature when the signature was not valid in an
         attempt to gain creditability.

   o  Apply regular anti-spam policies.  A Mailing List Manager SHOULD
      apply message content security policy just as they would messages
      destined for an individual user's mailbox.  In fact, a Mailing
      List Manager might apply a higher standard to messages destined to
      a mailing list than would normally be applied to individual
      messages.

         NON-NORMATIVE RATIONALE:  Since reputation will accrue to
         signers, Mailing List Managers should verify the source and
         content of messages before they are willing to sign lest their
         reputation be sullied by nefarious parties.

   o  Add a Sender header using a valid address pointing back to the
      Mailing List Administrator or an appropriate agent (such as an
      "owner-" or a "-request" address).

   o  Sign the resulting message with a signature that is valid for the
      Sender header address.  The Mailing List Manager SHOULD NOT sign
      messages for which they are unwilling to accept responsibility.

   Mailing List Managers MAY:





Allman, et al.           Expires April 26, 2006                [Page 11]

Internet-Draft                  DKIM SSP                    October 2005


   o  Reject messages with signatures that do not verify or otherwise
      satisfy their policy.


6.3  Signer Actions

   All Signers SHOULD:

   o  Include the From header as a signed header field (i.e., in the
      "h=" tag) under all circumstances.

   o  Include any existing Sender header in the signed header field
      list, if the Sender header exists.

   Signers wishing to avoid the use of third party signatures SHOULD do
   everything listed above, and also:

   o  Include the Sender header field name in the header field list
      ("h=" tag) under all circumstances, even if the Sender header
      field does not exist in the header block.  This prevents another
      entity from adding a Sender header field.

   o  Publish a Sender Signing Policy that does not permit the use of
      Third Party Signatures


7.  IANA Considerations

   Use of the _policy prefix in DNS records will require registration by
   IANA.

   The DKSSP RR type must be registered by IANA.

8.  Compliance

   [[To be done.]]

9.  Security Considerations

   Security considerations in the Sender Signing Policy are mostly
   related to attempts on the part of malicious senders to represent
   themselves as other senders, often in an attempt to defraud either
   the recipient or the Alleged Originator.

9.1  Fraudulent Sender Address

   [[Assuming 3rd party signature is based on Sender header]] If the
   Sender Signing Policy permits third party signing, an attacker can



Allman, et al.           Expires April 26, 2006                [Page 12]

Internet-Draft                  DKIM SSP                    October 2005


   create a message with a From header of an arbitrary sender and a
   legitimately signed Sender header

9.2  DNS Attacks

   An attacker might attack the DNS infrastructure in an attempt to
   impersonate policy records.  However, such an attacker is more likely
   to attack at a higher level, e.g., redirecting A or MX record lookups
   in order to capture traffic that was legitimately intended for the
   target domain.  Domains concerned about this should use DNSSEC
   [RFC4033].

10.  References

10.1  Normative References

   [ID-DKIM-BASE]
              Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)",
              draft-allman-dkim-base-00 (work in progress), July 2005.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

10.2  Informational References

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.


Authors' Addresses

   Eric Allman
   Sendmail, Inc.
   6425 Christie Ave, Suite 400
   Emeryville, CA  94608
   USA

   Phone:  +1 510 594 5501
   Email:  eric+dkim@sendmail.org
   URI:






Allman, et al.           Expires April 26, 2006                [Page 13]

Internet-Draft                  DKIM SSP                    October 2005


   Mark Delany
   Yahoo! Inc
   701 First Avenue
   Sunnyvale, CA  95087
   USA

   Phone:  +1 408 349 6831
   Email:  markd+dkim@yahoo-inc.com
   URI:


   Jim Fenton
   Cisco Systems, Inc.
   MS SJ-24/2
   170 W. Tasman Drive
   San Jose, CA  95134-1706
   USA

   Phone:  +1 408 526 5914
   Email:  fenton@cisco.com
   URI:

Appendix A.  Change Log

A.1  Changes since -00

   From a "diff" perspective, the changes are extensive.  Semantically,
   the changes are:

   o  Added section on "Third Party Signatures and Mailing Lists"

   o  Added "Compliance" (transferred from -base document).  I'm not
      clear on what needs to be done here.

   o  Extensive restructuring.
















Allman, et al.           Expires April 26, 2006                [Page 14]

Internet-Draft                  DKIM SSP                    October 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
   http://www.ietf.org/ipr.

   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
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.


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.


Acknowledgment

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




Allman, et al.           Expires April 26, 2006                [Page 15]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/