DKIM Working Group D. Otis
Internet-Draft Trend Micro, NSSG
Intended status: Standards Track August 18, 2008
Expires: February 19, 2009
DKIM Author Domain Signing Practices (ADSP) Security Issues
draft-otis-dkim-adsp-sec-issues-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 February 19, 2009.
Abstract
The proposed [I-D.ietf-dkim-ssp] defines DNS records that advertise
the extent to which a domain employs [RFC4871] to sign [RFC2822]
messages, and defines how other hosts can access these
advertisements. Its laudable goal is to allow domains control over
the use of the From header field. When a message is not adequately
signed, advertised assertions, referenced by a domain in the From
header field, assist in resolving the message's intended disposition.
However, [I-D.ietf-dkim-ssp] fails to discern that restricted
identities imposed upon remote signing agents, require additional
control be afforded the domain, irrespective of the domain's
advertised practices. [I-D.ietf-dkim-ssp] employs a flawed two-stage
Otis Expires February 19, 2009 [Page 1]
Internet-Draft ADSP-SEC-ISSUES August 2008
signature validation process that occurs in conjunction with
advertised practices. The two stage approach impairs the range of
authentication assertions and related security tactics. Advertised
practices not only determine whether a signature should be expected,
they may constrain the "on-behalf-of" identity applied by signing
agents that are not otherwise so restricted. By constraining the
"on-behalf-of" identity for all signing agents, the draft neglects
the predominate role of the domain as a point of trust, and
incorrectly assumes the signature is limited to supporting assertions
regarding the identity of the author. In addition, the only directly
actionable practice is defined using a term that is likely to
negatively impact the integrity of delivery status.
[I-D.ietf-dkim-ssp] impairs security in other ways as well, but
fortunately minor changes to the definition of a valid signature can
significantly remedy the most critical security issue.
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].
Otis Expires February 19, 2009 [Page 2]
Internet-Draft ADSP-SEC-ISSUES August 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Errors and Omissions . . . . . . . . . . . . . . . . . . . . . 7
2.1. Factual Errors . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Factual Omissions . . . . . . . . . . . . . . . . . . . . 7
3. Recommended Changes . . . . . . . . . . . . . . . . . . . . . 8
3.1. 3.2 ADSP Usage . . . . . . . . . . . . . . . . . . . . . . 8
3.2. 2.7. Author Signature . . . . . . . . . . . . . . . . . . 9
3.3. Section 4.1. DNS Representation . . . . . . . . . . . . . 9
3.4. 3.1. ADSP Applicability . . . . . . . . . . . . . . . . . 9
3.5. 4.2.1. Record Syntax . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5.1. Considerations not managed by draft-ietf-dkim-ssp . . . . 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. References - Normative . . . . . . . . . . . . . . . . . . 12
6.2. References - Informative . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Otis Expires February 19, 2009 [Page 3]
Internet-Draft ADSP-SEC-ISSUES August 2008
1. Introduction
Both [RFC4871] and [I-D.ietf-dkim-ssp] would benefit from a general
requirement for signatures with keys that restrict a remote signing
agent's "on-behalf-of" identity, where this identity must also match
against the From header field before being considered valid.
[RFC4871] makes a statement that is emblematic of how the signature's
role can be distorted. This statement can not be applied as a basis
for message acceptance, does not acknowledge that restricted
identities for remote signing agents require greater control be
afforded the domain, and ignores the predominate role of the domain
by assuming the DKIM signature is to make assertions regarding the
identity of the author. In section 6.3 paragraph 5,
"If the message is signed on behalf of any address other than that
in the From: header field, the mail system SHOULD take pains to
ensure that the actual signing identity is clear to the reader."
At best, DKIM might make a weak assertion regarding the identity of
the author. However, these assertions lack a wide range of
supporting conventions where reliance upon an author identity would
be unsafe. To sustain delivery integrity, whether the signature is
valid must remain clear. The "on-behalf-of" identity may be opaque
whenever the key employed by the signing agent can sign on behalf of
the entire domain. Signing agents afforded unrestricted keys can be
considered able to verify the entire message's compliance with the
domain's practices. The establish trust is with the signing domain,
and can never be based upon a dubious identity within the From header
field.
Conceptually, receiving hosts verify a DKIM signature by obtaining
the corresponding public key. A valid signature confirms the message
is attested to by a party in possession of the private key, and in
control of a portion of the domain publishing the public key. An
important missing check is needed to repair [I-D.ietf-dkim-ssp]. The
check should be applied whenever a key restricts the "on-behalf-of"
identity for remote signing agents. For the domain to control the
From header field with remote signing agents, a restricted "on-
behalf-of" identity must then be required to also match against the
From header field before considering the signature to be valid. The
From header field requirement for a restricted "on-behalf-of"
identity should be consistent at every stage in the process.
Ideally, [I-D.ietf-dkim-ssp] should only introduce practices that
ensure the From header field domains are within their signing domain,
and ensure the signing domain is able to control the From header
field for remote signing agents in all cases. Keys that restrict the
"on-behalf-of" identity being signed are likely employed by mobile
Otis Expires February 19, 2009 [Page 4]
Internet-Draft ADSP-SEC-ISSUES August 2008
users having limited access to the domain's outbound signing servers.
In the case of a key restricted identity, the signature is required
to include a matching "on-behalf-of" identity. Currently, there is
no general requirement that the restricted identity also match
against the From header field. Since these keys are prone to theft
and are easily abused, no signature should be considered valid when a
restricted identity does not match against the From header field.
[I-D.ietf-dkim-ssp] fails to stipulate that signatures using identity
restricted keys should be considered invalid when the identity does
not match against the From header field. These signatures are only
considered invalid when the domain is able to advertise a restrictive
practice at the domain or subdomain in question. Ensuring that a
restricted identity match against the From header field should not
depend upon the recipient discovering and the domain being able to
assert a restrictive advertised practice. Not relying upon
restrictive advertised assertions becomes even more paramount when
the restrictive advertised practices potentially harm the integrity
of delivery status. When delivery integrity is important,
restrictive advertised practices may need to be avoided.
As IP addresses are increasingly being blocked by providers,
compromised systems, often containing account information, are
frequently used by bad actors to gain access to larger domains, where
blocking the combined outbound messages often prove impractical.
Ordinarily, larger domains are either unwilling or unable to affirm
the identity in the From header field and, as a result, may end up
leaving the "on-behalf-of" identity tag and value blank.
The constraints imposed by [I-D.ietf-dkim-ssp] makes it impractical
for the "on-behalf-of" identity to always indicate what was
authenticated, as intended in [RFC4871]. Ironically, an ability to
always indicate an authenticated identity was lost due to an
optimization that considered signatures having a restricted "on-
behalf-of" identity not matching against the From header field to be
valid. Any scheme that considers signatures to be valid when a
restricted identity does not match against the From header field
places recipients in significant peril since the signature header or
this identity are seldom visible, and this leaves the From header
field open to exploitation.
Detecting inappropriate use of an identity restricted key should
occur quickly and prior to message acceptance. The fix for
[I-D.ietf-dkim-ssp] is to preclude signatures from being considered
valid that might permit an unverifiable use of a domain within the
From header field by remote signing agents. This check is not
prefaced upon first discovering whether the domain advertises
Otis Expires February 19, 2009 [Page 5]
Internet-Draft ADSP-SEC-ISSUES August 2008
practices. In other words, in addition to restrictions on the "on-
behalf-of" identity within the signature for remote signing agents,
the From header field should also match against the same restriction.
Currently, [I-D.ietf-dkim-ssp] advertised practices may affect
messages that lack signatures, or where the From header field address
is not within the signing domain, or where the "on-behalf-of"
identity does not match against the From header field. The impact of
an advertised practice and the resulting "on-behalf-of" identity
requirement occurs irrespective of the type of signing agent and key
used. This creates a security vulnerability that may encourage DNS
attack, and unnecessarily limits the practical utility of the DKIM
signature.
When a restricted identity fails to match against the From header
field and is considered to provide a valid signature,
[I-D.ietf-dkim-ssp] may subsequently invalidate the signature
whenever a practice advertisement by the domain is discovered.
Unfortunately, the two stage conditional valid signature requirement
unnecessarily affects all signing agents. Signature validity is
dependent upon the success of advertisement discovery, where this two
stage process is likely to negatively impact both delivery integrity
and security. Limitations imposed on the "on-behalf-of" identity
within the second stage may alter what is considered valid by
[RFC4871]. When the signing agent employs unrestricted keys, this
change is wholly without merit.
To control remote signing agents, keys may restrict the
"on-behalf-of" identity being signed. However [RFC4871] imposes no
requirement for restricted identity placement within the message. In
addition, [I-D.ietf-dkim-ssp] incorrectly assumes reliable
advertisement discovery, and fails to impose restricted identity
placement for remote signing agents as well. Although remote signing
agents may have keys that restrict identity signing, the domain is
unable to control whether a restricted "on-behalf-of" identity is
also assured to match with the From header field, except by
publishing advertised practices at every existing subdomain.
For [RFC4871], the "on-behalf-of" identity is not required to be that
of a message author, and may even indicate authentication of a system
or an access account. This distinction is important since
predominately compromised systems, rather than individuals, are the
source of abuse. Unfortunately, [I-D.ietf-dkim-ssp] places
constraints on what may be placed within the "on-behalf-of" identity.
It is unrealistic to suggest multiple signatures offer a solution,
since this doubles the related overhead. [RFC4871] has already
defined an "on-behalf-of" identity. There is no reason to reinvent
the meaning of the "on-behalf-of" identity in support of a flawed two
Otis Expires February 19, 2009 [Page 6]
Internet-Draft ADSP-SEC-ISSUES August 2008
stage conditional valid signature definition.
2. Errors and Omissions
2.1. Factual Errors
Section 3.2 of [I-D.ietf-dkim-ssp] makes a factual error in stating
that a valid signature by an Author Domain is already known to be
compliant with any possible ADSP for that domain. Compliance with
ADSP currently requires Author Signatures, not just a signature by
the Author domain.
The Author Signature requires the "on-behalf-of" identity to match
against the author's address. A valid signature by the Author Domain
per [RFC4871] will not impose this limitation, where the
[I-D.ietf-dkim-ssp] Author Signature requirements therefore limit
interchange without justification.
For example, office administrators might submit messages authored by
their managers. The authenticated DKIM signature "on-behalf-of"
identity could be that of the office administrator whose email-
address was placed within the Sender header field as permitted by
[RFC2822]. When a signing domain's practice permits office
administrators to send messages on behalf of managers, a manager's
email-address could be placed within the From header field to signify
the manager's role as author.
A valid signature, verified with a key lacking identity restrictions,
clearly indicates that the signature was applied by a trusted signing
agent. A trusted signing agent can sign on behalf of the entire
domain, and should first ensure message conformance prior to signing.
A signature by the Author domain using a key that lacks identity
restrictions is sufficient to ensure a domain's ability to control
the use of the From header field, and to assert any sundry list of
message conformance requirements.
A valid signature applied using a key lacking identity restrictions
by the Author Domain should be considered compliant with any possible
ADSP. However the current Author Signature definition in conjunction
with the discovery of a practice may cause a valid signature to
become invalid when assessing ADSP compliance where the
"on-behalf-of" identity does not match against the author's address.
2.2. Factual Omissions
[I-D.ietf-dkim-ssp] attempts to define practices used by a domain,
but then fails to specify which public transport protocol or
Otis Expires February 19, 2009 [Page 7]
Internet-Draft ADSP-SEC-ISSUES August 2008
protocols meet the advertised practice. Misapplication of practice
compliance assessment could lead to interchange problems when only a
portion of the possible [RFC2822] related transports employ
[RFC4871].
Omitting public transport specifics might seem reasonable, since
there are many possible protocol gateways into SMTP provided by
various third-parties. Remaining silent on the relevant transport
will lead to various ad-hoc methods for dealing with protocol
gateways. The omission fails to warn of potential problems, such as
various news articles being dropped, for example.
Omitting transport specifics has lead to the general requirement in
Section 4.3 that any ADSP related transport use DNS at the domain of
the address. The lack of transport agility is the result of there
not being any ADSP parameter that makes any specific public transport
assertion.
3. Recommended Changes
3.1. 3.2 ADSP Usage
CHANGE:
If a message has a Valid Signature from an Author Domain, ADSP
provides no benefit relative to that domain since the message is
already known to be compliant with any possible ADSP for that domain.
TO:
If a message has a Valid Signature from an Author Domain, an
additional consideration must be applied. When a key used to
validate the signature imposes a restrictive template on the local-
part of the "on-behalf-of" identity, this template and the
signature's domain should also match against an address contained
within the From header field, or the signature should not be
considered valid.
A match is determined by the construction of a template composed of
the key's "g=" tag and value, and the domain as denoted in the
signature's "d=" tag and value in the form:
<g value | * >@[*.]<d value>
The default for the key's local-part template value, when it is not
present, is "*", in which case no From header field comparison will
be required.
Otis Expires February 19, 2009 [Page 8]
Internet-Draft ADSP-SEC-ISSUES August 2008
3.2. 2.7. Author Signature
CHANGE:
An "Author Signature" is any Valid Signature where the identity of
the user or agent on behalf of which the message is signed (listed in
the "i=" tag or its default value from the "d=" tag) matches an
Author Address in the message. When the identity of the user or
agent includes a Local-part, the identities match if the Local-parts
are the same string, and the domains are the same string.
TO:
An "Author Signature" is any Valid Signature per section 3.2, where
an Author Address domain is within the signature's "d=" tag and value
domain.
3.3. Section 4.1. DNS Representation
CHANGE:
_adsp._domainkey.
TO:
_adsp. (preferably adopt a specific resource record instead).
3.4. 3.1. ADSP Applicability
CHANGE:
ADSP as defined in this document is bound to DNS.
TO:
ADSP as defined in this document is bound to DNS and SMTP.
3.5. 4.2.1. Record Syntax
CHANGE TERMS:
Discardable and discard
TO:
Dismissable and dismiss
Otis Expires February 19, 2009 [Page 9]
Internet-Draft ADSP-SEC-ISSUES August 2008
Even for the example cases sighted, arrangements are being made to
offer feedback to determine the level of abuse. The term
discardable is likely to thwart adoption when the integrity of the
delivery status is also important. If the mechanism proves
effective, the level of abuse should also dramatically wane.
4. IANA Considerations
This document requires no IANA consideration.
5. Security Considerations
5.1. Considerations not managed by draft-ietf-dkim-ssp
DKIM keys with a restrictive local-part template in the "g=" tag and
value are likely employed by remote signing agents beyond the direct
control of the signing domain. As a result, additional consideration
is required when a restrictive local-part template does not match
against the From header field. Signatures should not be considered
valid whenever a restrictive local-part key "g=" tag and value, and
the signature "d=" tag and value, do not match against a From header
field address.
Signatures by keys lacking a restrictive local-part template are only
safely used when the signing agent is able to directly evaluate the
signed header fields and content. Recognition of signing agents able
to apply policy over the entire message improves security in several
ways:
Discerns potentially deceptive signatures independent of
advertised signing practice discovery.
Permits an accurate indication of on whose behalf the signature
was added, even when not on behalf of the author's address.
Permits the "on behalf of" identity to be derived from an account
instead of being left blank when a signing domain is unable or
unwilling to affirm the identity of the author's address.
Permits the identity to track either the author or the account
used. This ability can be most useful to third-parties that
attempt to isolate bot-net 0wned systems. In response to a
growing portion of the IP address space being blocked, bot-nets
increasingly send their mail through a provider's outbound server
after obtaining access to valid accounts.
Otis Expires February 19, 2009 [Page 10]
Internet-Draft ADSP-SEC-ISSUES August 2008
[I-D.ietf-dkim-ssp] should state a valid DKIM signature does not
safely provide an assertion of the author's identity, and that only
the domain contained within the signature will have been verified by
DKIM signature validation. In addition, when the "on-behalf-of"
identity signing is restricted, and does not match against the From
header field, the signature should not be considered valid.
5.1.1. Lack of transport specificity
[I-D.ietf-dkim-ssp] fails to signal which transport protocol
implements an advertised practice. As such, it also fails to
indicate which DNS resource, if any, supports the transport.
Although verifying a domain's existence might query resource records
specified by [RFC2821], the associated transport is never specified,
where only query errors returned are meaningful.
Since the goal is to control use of a domain in the From header
field, a DNS error will then likely require a message to be refused,
since the proposed methods are unable to resolve practices over a
domain hierarchy. [I-D.ietf-dkim-ssp] also never specifies a
transport or related resource records. This means any wildcard
resource record within the domain will thereby allow domain spoofing.
Any domain using wildcards will permit any synthesized domain appear
to lack advertised practice assertions.
Contrary to the MUST NOT use wildcards mandate, a solution for
covering the entire domain hierarchy or to cope with wildcard
resources will likely be wildcard TXT resource records containing
restrictive practice assertions. The sanctioned alternative would be
to publish separate resource records at each existing domain node.
As if a per node alternative was not bad enough, this alternative has
been made even less attractive by requiring more entries and by
consuming more resources than otherwise required.
The additional DNS overhead occurs with the use of two prefixed
subdomain labels locating the TXT resource record. Instead of just
the 6 byte "_adsp.", the additional "_domainkey." label introduces an
additional 11 bytes and subdomain for every DNS node protected.
Justification for having any label was to accommodate typical web-
based commodity provider tools that often do not support new resource
record types.
Justification for the second label is likely based upon a false
assumption that delegation of the "_domainkey." subdomain will also
facilitate the typical needs of third-party providers expected to
advertise practices at just the domain supporting the transport.
There are transport protocols in wide use that employ [RFC2822]
Otis Expires February 19, 2009 [Page 11]
Internet-Draft ADSP-SEC-ISSUES August 2008
messages, but that might not utilize DNS. There are also cases where
a domain contained within a message is intentionally not found in
DNS. Such domains may deal with a different name space, or ensure
the related address is not exploited by spammers.
[I-D.ietf-dkim-ssp] does not offer a means to deal with messages that
conflict with a strategy that depends upon the lack of DNS errors as
a basis for acceptance.
[I-D.ietf-dkim-ssp] should recommend that recipients be advised to
use automated folder placement for trusted signing domains to reduce
deceptions that utilize domain look-alike and subdomain based
tactics.
5.1.2. DNS Wildcards and specifying SMTP as the transport
With the exception of wildcard MX records, wildcards within a domain
that also publish ADSP records should not pose a significant problem.
Although referencing SMTP related records will not provide "NXDOMAIN"
results when a domain contains a wildcard, SMTP discovery records,
such as MX or A records, still offer evidence of SMTP support.
Whether AAAA records, absent MX or A records, can be considered
evidence of SMTP support has not withstood widespread use of AAAA
only servers.
For security reasons, SMTP should also adopt an MX resource record
mandate for the acceptance of public exchanges. This would then mean
advertised practice discovery could be limited to subdomains
containing MX records, and ensure failure of a single transaction
obtaining an MX record would curtail all other message related
transactions. An MX resource record mandate would thereby shelter
domains not publishing MX records from the additional assortment of
transactions often associated with any number of spoofed email-
addresses and DKIM signatures that might be generated per message.
6. References
6.1. References - Normative
[I-D.ietf-dkim-ssp]
Local-part, a., Allman, E., Fenton, J., Delany, M., and J.
Levine, "DKIM Author Domain Signing Practices (ADSP)",
draft-ietf-dkim-ssp-05 (work in progress), August 2008.
6.2. References - Informative
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
Otis Expires February 19, 2009 [Page 12]
Internet-Draft ADSP-SEC-ISSUES August 2008
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 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 2001.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
(DKIM) Signing Practices Protocol", RFC 5016,
October 2007.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
Otis Expires February 19, 2009 [Page 13]
Internet-Draft ADSP-SEC-ISSUES August 2008
Author's Address
Douglas Otis
Trend Micro, NSSG
10101 N. De Anza Blvd
Cupertino, CA 95014
USA
Phone: +1.408.257-1500
Email: doug_otis@trendmicro.com
Otis Expires February 19, 2009 [Page 14]
Internet-Draft ADSP-SEC-ISSUES August 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Otis Expires February 19, 2009 [Page 15]