Internet DRAFT - draft-otis-dkim-options
draft-otis-dkim-options
pre-workgroup D. Otis
Internet-Draft Trend Micro, NSSG
Expires: June 24, 2006 December 21, 2005
Extended Options for DomainKeys Identified Mail (DKIM)
draft-otis-dkim-options-00
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 June 24, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes options that extend protections offered by
DKIM. These options include Binding-Advice & Role-Assertion, Opaque-
Identifier, and an In-Channel check. The Binding-Advice & Role-
Assertion offers guidance in isolating the source of a message, in
addition to establishing message signature expectations. The Opaque-
Identifier (O-ID) offers protection from replay abuse and intra-
domain spoofing, even when email-addresses are not associated with
the signing-domain. The In-Channel check provides a means to
mitigate DNS lookups for avoiding possible message replay abuse.
Otis Expires June 24, 2006 [Page 1]
Internet-Draft DKIM Options December 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Binding-Advice & Role-Assertion . . . . . . . . . . . . . . . 5
4. Opaque-Identifier . . . . . . . . . . . . . . . . . . . . . . 8
5. In-Channel Check . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13
Otis Expires June 24, 2006 [Page 2]
Internet-Draft DKIM Options December 2005
1. Introduction
Message signing, as exemplified by DomainKeys Identified Mail (DKIM)
[I-D.allman-dkim-base], is a mechanism to allow an assertion of an
accountable domain for an email message in transit. The assertion is
made by means of a digital signature included within a header, which
also validates the integrity of selected headers and message body
content subsequent to the signing of the message.
Combining DKIM with an authorization mechanism, referenced from an
email-address contained within the message, may result in unintended
consequences. The email-address domain owner may be unfairly held
accountable for abuse found subsequent to their authorization. As
the email-address domain owner often has no administrative oversight
or ability to rectify abuse issues, such accountability may place
them in peril of having their email refused.
Even when authorization is restricted to a single provider, the
email-address domain owner would still be relying upon this
provider's diligence, and may be unable to ascertain the cause for
refusals or remedy their situation. Such restriction on allowable
sources for email also interferes with existing email practices, such
as the use of list-servers or sending email using the email-address
of one's alma mater. To ensure fair treatment for email-address
domain owners, and to minimize the impact upon email practices, the
ability to refute messages should not be contingent upon the use of
an authorization scheme.
Indicating the results of an authorization that compares an email-
address domain to a signing-domain would be unsafe. Domain matching
only indicates the email-address is within the same Administrative
Unit as the signing-domain. Ambiguity in the display of the email-
address and one's limited ability to detect variations from prior
messages means such indications may mislead the recipient into
erroneously trusting the source of the message.
In addition, the entity directly involved with sending email should
be held accountable for abuse. Such an assignment of accountability
permits effective and timely remedies, and ensures innocent parties
are not inadvertently harmed. For email, such an entity could be
discerned by the remote IP address, a verified host name, or the
domain used to verify the DKIM-Signature. The DKIM-Signature should
be considered an aspect of the message transport, and not necessarily
directly associated with message content or any contained email-
address.
Restoring trust and establishing the expectation of a signature being
present within email messages can be accomplished by way of a
Otis Expires June 24, 2006 [Page 3]
Internet-Draft DKIM Options December 2005
recognition strategy, instead of using an email-address authorization
mechanism. Perhaps one of the greatest assets of DKIM would be the
enhanced ability to recognize previous email sources. Simple email-
address and signing-domain comparisons permit all too common social
engineering techniques that are often involved in the spoofing of
email-addresses. A recognition strategy can safely highlight those
messages emanating from a source specifically recognized by the
recipient through a prior message.
The ability to recognize a unique email source is enhanced with the
use of the Binding-Advice & Role-Assertion, and the O-ID. The O-ID
and In-Channel check can further enhance protections that curtail
abusive message replays. The In-Channel check allows a reduction in
the overhead associated with abusive message replay protections.
Binding identifiers from a prior correspondent at the behest of the
recipient allows indications of recognition without the use of
complex and problematic email-address domain authorizations, which
may create significant support issues. To support the recognition of
a prior correspondent, the MUA could simply highlight those messages
from prior correspondents. This approach would offer a higher level
of assurance and trust without using any DNS lookups. Following the
verification of the DKIM-Signature, the identification of the message
source would be contained completely within the message itself.
When assuming legacy MUAs, scant protections are possible by the MTA
even using many DNS lookups and registering thousands of look-alike
domains. Due to limitations of ensuring the visibility of checked
domains, the MTA approach provides an alarmingly low level of email-
address protections. There is also a potential for an undesired
exposure of email-addresses in the 'i=' parameter.
The O-ID approach could be used to detect when a previous
correspondent appears to be from a different source. Without the
O-ID, detecting intra-domain spoofing would depend upon the signing-
domain verifying the validity of the email-address. The signed
message may even advise what other information should be compared
against the email-address. While in most cases the collected
relationships (bindings) would be made at the behest of the recipient
and require their approval, some relationships could be established
automatically.
When the email-address domain is within the signing-domain, and when
the message advises that these messages should always be signed, then
it should be safe to capture this assertion automatically. When
signature assurances are captured (cached), the MTA or MUA would be
able to detect when a message violated these expected relationships.
Before rejecting a message for not having the proper signature, a
Otis Expires June 24, 2006 [Page 4]
Internet-Draft DKIM Options December 2005
check may be made to verify that the signature assurance remains
valid.
To recognize the source of a message when there are no assurances
being made regarding the email-address, an O-ID that tracks accounts
could be added by the signing-domain. This O-ID would become a part
of the captured relationship once approved by the recipient. A
provision has been added to indicate when the signing role has been
delegated. The message from a delegated signer is not allowed to
make "broad" recommendations with respect to the scope of a binding.
This delegated role will also require the O-ID to equal the left-most
label of the DKIM-Signature selector.
2. Definitions
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].
Terminology: Terminology conforms to [I-D.crocker-email-arch].
3. Binding-Advice & Role-Assertion
The displayed character-repertoire may be defined by the sender as
result of [RFC2047] or [RFC3492]. Even displaying raw puny-code
would represent a difficult basis for recognition, especially for
recipients who's native language is not based upon ASCII characters.
In addition, a large percentage of recipients only see the "display-
name" as defined by [RFC2822] (also called the "pretty-name") where
the email-address is not normally seen by the recipient.
A safe indication shown to the recipient would be that a message
source has been recognized as belonging to a prior correspondent. To
help achieve this goal, the signer of the message assists by
indicating which aspects of the message's information may be used to
isolate the message's source.
Three roles are defined in the following tables. For example,
although an MSA is indicated as providing the signature, this role
could be delegated to an MUA or another less trusted MSA. Detecting
the delegation of a role involves examining the DKIM-Key optional
parameters. Whenever the 'g=<email-address>' has an email-address
assigned, or the 'w=<sa-validation>' first letter is 'D' then the
role should be considered delegated. In the case of a delegated
role, the O-ID is derived from the DKIM-Signature 's=<selector>'
parameter. When the role is delegated and the 'u=<Opaque-
Identifier>' parameter is present, it MUST match that of the left-
Otis Expires June 24, 2006 [Page 5]
Internet-Draft DKIM Options December 2005
most selector label. A "broad" assertion by a Delegated signer is
not valid.
+------+------------------------------------------------------------+
| Code | Scope of Binding, and Role |
+------+------------------------------------------------------------+
| w=b | Always signed by MSA, broad ass. across email-domain |
| w=n | Always signed by MSA, narrow ass. with email-address |
| w=d | Signed by MSA, broad association across email-domain |
| w=a | Signed by MSA, narrow association with email-address |
| w=o | Signed by MSA, association with Opaque-Identifier |
| none | Signed by MSA, no association assured |
| w=B | Always signed by Mediator, broad ass. across email-domain |
| w=N | Always signed by Mediator, narrow ass. with email-address |
| w=D | Signed by Mediator, broad association across email-domain |
| w=A | Signed by Mediator, narrow association with email-address |
| w=O | Signed by Mediator, association with Opaque-Identifier |
| w=M | Signed by Mediator, no association assured |
| w=X | Signed by MDA, no association assured |
+------+------------------------------------------------------------+
When the DKIM-Signature header field has the option 'w=' with a value
of 'b','B','d', or 'D', then the email-address domain associated with
the signing-role together with the signing-domain can be used to
recognize the source of a message. With a value of 'n','N','a', or
'A', then the entire email-address associated with the signing-role
together with the signing-domain should be used to recognize the
source of a message. With a value of 'o', or 'O', the O-ID together
with the signing-domain can be used to recognize the source of a
message. With a value of 'M', 'X' or no 'w=' option (default), just
the signing-domain can be used to recognize the source of a message.
When the DKIM-Signature header field has the option 'w=' with a value
of 'X', this is used to verify that the message has been accepted by
the MDA of the signing-domain and the 'u=' parameter, if present,
represents an assessment made by the MDA. To ensure signatures are
not misused to perpetrate abusive message replays, the MDA may
overlay the 'b=<signature>' of other roles with "!MDA-verified" or
"!MDA-invalid". DKIM-Signature header fields containing the 'w=X'
option will include other DKIM-Signature header fields containing an
"!MDA-verified" signature overlay, in sequential order from the
beginning of the message. These additional DKIM-Signature header
fields are processed immediately following the processing of the
DKIM-Signature header field with the 'w=X' option, and before the
remainder of the message. A message with a DKIM-Signature header
field signed by a domain of a different Administrative Unit with the
'w=X' option is invalid and SHOULD be rejected.
Otis Expires June 24, 2006 [Page 6]
Internet-Draft DKIM Options December 2005
When the DKIM-Signature header field has the option 'w=' with a value
of 'B','N','D', or 'A', then the email-address associated with the
DKIM-Signature should be found within a "Resent-*" header field.
Each DKIM-Signature should be uniquely associated with a MSA,
Mediator, or MDA role. The DKIM-Signature header field added by the
MDA or Mediator MUST be removed by the MSA prior to processing the
message. When a signature added by an MSA is known by the Mediator
to be currently invalid, the DKIM-Signature header field SHOULD be
removed or the Mediator may otherwise overlay the 'b=<signature>'
with "!Mediator-verified" or "!Mediator-invalid".
+------+-------------------+---------------+------------+----------+
| Code | Binding | Assurances | Validation | Role |
+------+-------------------+---------------+------------+----------+
| w=b | email-domain | always signed | DKIM key | MSA |
| w=n | email-address | always signed | DKIM key | MSA |
| w=d | email-domain | none | none | MSA |
| w=a | email-address | none | none | MSA |
| w=o | Opaque-Identifier | none | none | MSA |
| none | none | none | none | MSA |
| w=B | email-domain | always signed | DKIM key | Mediator |
| w=N | email-address | always signed | DKIM key | Mediator |
| w=D | email-domain | none | none | Mediator |
| w=A | email-address | none | none | Mediator |
| w=O | Opaque-Identifier | none | none | Mediator |
| w=M | none | none | none | Mediator |
| w=X | none | none | none | MDA |
+------+-------------------+---------------+------------+----------+
When the DKIM-Signature header field has the option 'w=' with a value
of 'n', or 'b', and the email-address domain is within the signing-
domain as denoted by the 'd=<domain>' parameter, then the assurance
of a signature for this domain can be automatically cached. The
cached information should include both the domain where an assurance
has been made, and the label for a record used to confirm the
continued status of the assurance. A parameter within the DKIM-Key
can be used to consolidate where assurances are confirmed when
multiple DKIM-Keys are being used. When there are no parameters
added to the DKIM-Key, the default signature-assurance validation
location would be determined by the 'd=<domain>' and parameters
's=<selector>'. The left-most label within the selector would be
used as follows:
"<lm-selector>._dkim-sa.<domain>".
When the 'w=' option is present within the DKIM-Key, the value of
this parameter modifies the signature-assurance validation location
Otis Expires June 24, 2006 [Page 7]
Internet-Draft DKIM Options December 2005
to be:
"<sa-validation>._dkim-sa.<domain>".
The 'w=<sa-validation>' option would be composed of 1 to 63
characters within the DKIM-Key and used to consolidate signature
assurances. The operation of this signature-assurance validation
record mechanism would take the form of a single A record lookup
where the existence of the record would validate a cached assurance.
<sa-validation> ::= <role> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= %x41-5A / %x61-7A
<role> ::= "T" | "D"
; Trusted or Delegated role
<digit> ::= %x30-39
<sa-validation>._dkim-sa.<signing-domain> IN A 127.0.0.2
4. Opaque-Identifier
The Opaque-Identifier (O-ID) is an option that supports two different
mechanisms. One mechanism isolates the source of a message to a
specific account as denoted by the Binding-Advice & Role-Assertion.
The other mechanism provides a means to revoke messages being
abusively replayed. An O-ID added to the signature header MUST also
be a valid domain name label. The term 'opaque' means only the
domain creating the identifier understands the associations indicated
in Binding-Advice & Role-Assertion. There are two modes for creating
the O-ID. One mode would make the O-ID persistent with the account
used to access the signing-domain, and the other could be sequential
for cases where an account is not involved. A prefix added to a
sequential O-ID prevents collisions with identifiers used for
accounts.
If an identifier were added to an unsigned message, this would invite
forgery and therefore offer little value. A standardized O-ID,
included within the validated content of a signed message, would
offer significant value. A persistent O-ID would be most useful and
could be derived from the access server that authenticates the
account being used.
A sequential O-ID may be appropriate when distributing bulk mailings.
To identify abusers that may attempt to stage replay attacks, having
a unique identifier for each recipient could prove helpful. These
Otis Expires June 24, 2006 [Page 8]
Internet-Draft DKIM Options December 2005
replay attacks could be done using the unchanged content of the
message, but sent to recipients that would consider the information
to be unsolicited. The reason for such a replay attack may be to
damage the reputation of the signing-domain.
The persistent O-ID would greatly aid the correlation of abuse and
the locating of compromised systems. This identifier could be
effective against systems compromised by Trojan programs, stolen
passwords, and cracked wireless access points, among many other
nefarious methods. Abuse reports that catalog signed messages and
that are correlated with a persistent O-ID would provide
incontrovertible evidence of where the source of a problem exists.
The publishing of the revocation record for the O-ID would also
provide feedback that actions were taken to rectify a policy breach.
In odd cases where an In-Channel check fails, a single lookup of a
revocation record for the O-ID returning no record would be an
indication that this particular O-ID is still authorized by the
signing-domain. This mechanism would be most valuable in those cases
where the message may have been forwarded, such as at the typical
alma mater, or where a mailing list opts to also forward signed
messages unaltered.
If there is a problem, the signature would offer the name of the most
capable domain able to remedy abuse. People can still safely use
their forwarding email accounts given to them by their school or
society. Mailing lists would be given a strong identifier upon which
to grant the replication of messages. Complaints would also likely
be directed to those most able to curtail future episodes of bad
behavior, i.e. the provider of the abusive account!
Within the signature header, a 'u=<Opaque-Identifier>' parameter or
within the DKIM-Key, a 'w=<sa-assurance>' parameter where the first
letter is 'D' a would indicate the use of an O-ID. The operation of
this revocation record mechanism takes the form of a single A record
lookup where the return of a record indicates the O-ID has been
revoked. The O-ID would be composed of 1 to 63 characters and select
a record in this fashion:
<Opaque-Identifier> ::= <mode> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::= %x41-5A / %x61-7A
<mode> ::= "P" | "S"
; Persistent and Sequential O-ID assignment
<digit> ::= %x30-39
<Opaque-Identifier>._dkim-or.<signing-domain> IN A 127.0.0.2
Otis Expires June 24, 2006 [Page 9]
Internet-Draft DKIM Options December 2005
When the first letter in the O-ID is 'P,' this represents an
identifier where the portion of the identifier to the right of the
leftmost '-' character is persistent with the account used to obtain
access. When the first letter is 'S,' then no portion of the
identifier can be used to isolate which account was used to obtain
access.
When the signing-domain has not revoked authorization for the O-ID,
no record would be returned and the remote DNS cache would retain the
absence of this record for a brief period of time, see [RFC2308].
For the majority of cases, where messages are obtained directly from
the signing-domain, confirmation of an In-Channel check allows the
O-ID revocation check to be skipped.
The O-ID revocation check would be performing nearly an identical
lookup now ubiquitously done to investigate the status of the SMTP
client's IP address against a DNS black-hole list. Those addresses
or identifiers that warrant refusal are granted a long lived address
record to ensure their immediate refusal and limit DNS traffic
resulting from abusive sources. Otherwise, not offering a record
allows for the prompt cessation of an O-ID's authorization when the
situation regarding a particular identifier changes. The Time-To-
Live for negative DNS caching may be determined by the recipient, or
represent the lesser of the SOA TTL or the SOA MINIMUM field,
depending upon the recipient's implementation.
5. In-Channel Check
There are two methods that can be used to ascertain whether a message
is In-Channel. In-Channel would be when the RCPT TO list has been
specified by or sourced by the originating Administrative Unit. One
method uses a hash of the initial [RFC2821] RCPT TO: email-address
list. The other method verifies the EHLO using a DNS lookup for an
address record or CSV-CSA record as defined in [I-D.crocker-csv-csa].
When the signing-domain as noted in the DKIM-Signature 'd=<domain>'
parameter are within the verified EHLO domain name, the message could
be said to be In-Channel. Another method may use a [RFC2821] RCPT
TO: email-address hash parameter stored within the DKIM-Signature to
confirm that the RCPT TO list has not been altered.
When the message is determined to be In-Channel, and an O-ID option
is being used, checking for O-ID revocation may be skipped. When
O-ID revocation should be checked, the receiving SMTP server may
issue an SMTP 450 temporary error and delay acceptance for a few
minutes. Once the receiving SMTP server decides enough time has
elapsed from the initial delivery attempt for the specific message, a
O-ID revocation check would be made instead. If the O-ID
authorization has not been revoked, the message may be accepted.
Otis Expires June 24, 2006 [Page 10]
Internet-Draft DKIM Options December 2005
When the 'm=' parameter is included, an SHA-1 hash algorithm defined
in [RFC3174] is used to hash all [RFC2821] RCPT TO: email-addresses
in sequence from left to right and first to last. The hash will
include only the [RFC2821] RCPT TO: email-addresses, and to obfuscate
the use of a BCC header, the hash may be initialized by a special
SMTP extension MF-SALT. The result of the hash is stored in Base 64
within the DKIM-Signature 'm=<mailfrom-hash>' parameter. When the
MF-SALT extension has been allowed, a RCPT TO parameter may return an
SMTP extension MF-SALT-?????????????? where the fourteen '?' are
replaced by "URL and Filename safe" Base 64 Alphabet characters as
defined in [RFC3548] representing an 84 bit random number. When the
MF-SALT parameter is found within the initial RCPT TO parameter,
without a binary conversion, the fourteen Base 64 Alphabet characters
are hashed first, followed by the RCPT TO: email-addresses. When the
MF-SALT parameter is not present, just the RCPT TO: list may have
been hashed.
6. IANA Considerations
The SMTP extension MF-SALT will require registration by IANA.
Use of the _dkim-sa and _dkim-or prefix in DNS records will require
registration by IANA.
To avoid conflicts, tag names for the DKIM-Signature header and key
records the following should be added to those registered with IANA.
Tag values for the "w=", "u=", and "m=" tags in the DKIM-Signature
header, and the "w=", tags in key records should be registered with
IANA for the same reason.
7. Security Considerations
This document describes options that can be used with DomainKeys
Identified Mail (DKIM) to improve upon the secure use of this
mechanism.
8. References
8.1 Normative References
[I-D.crocker-csv-csa]
Crocker, D., "Client SMTP Authorization (CSA)",
draft-crocker-csv-csa-00 (work in progress), October 2005.
[I-D.crocker-email-arch]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-04 (work in progress),
Otis Expires June 24, 2006 [Page 11]
Internet-Draft DKIM Options December 2005
March 2005.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
[RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[RFC3492] Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 2003.
8.2 Informative References
[I-D.allman-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)",
draft-allman-dkim-base-01 (work in progress),
October 2005.
Author's Address
Douglas Otis
Trend Micro, NSSG
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires June 24, 2006 [Page 12]
Internet-Draft DKIM Options December 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.
Otis Expires June 24, 2006 [Page 13]