< draft-newman-tls-imappop-00.txt   draft-newman-tls-imappop-01.txt >
Network Working Group C. Newman Network Working Group C. Newman
Internet Draft: Protecting IMAP4 and POP3 Connections Innosoft Internet Draft: Using TLS with IMAP4 and POP3 Innosoft
Document: draft-newman-tls-imappop-00.txt August 1997 Document: draft-newman-tls-imappop-01.txt November 1997
Protecting IMAP4 and POP3 Connections Using TLS with IMAP4 and POP3
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check
the "1id-abstracts.txt" listing contained in the Internet-Drafts the "1id-abstracts.txt" listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
Copyright Notice
Copyright (C) The Internet Society 1997. All Rights Reserved.
Introduction Introduction
The TLS protocol [TLS] (formerly known as SSL) provides a way to The TLS protocol [TLS] (formerly known as SSL) provides a way to
secure a connection from tampering and evesdropping. Obviously, secure a connection from tampering and evesdropping. Obviously,
such security is desirable for IMAP [IMAP4] and POP [POP3]. such security is desirable for IMAP [IMAP4] and POP [POP3].
Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH] Although advanced authentication mechanisms [IMAP-AUTH, POP-AUTH]
can provide this service with less complexity than TLS, TLS is can provide this service with less complexity than TLS, TLS is
useful in combination with plaintext password logins and other useful in combination with plaintext password logins and other
simple mechanisms as it doesn't require a site to upgrade its simple mechanisms as it doesn't require a site to upgrade its
authentication database. authentication database.
The common practice of using a separate port for a secure version The common practice of using a separate port for a secure version
of each protocol has a number of disadvantages in the IMAP [IMAP4] of each protocol has a number of disadvantages in the IMAP [IMAP4]
and POP [POP3] environment. Rather than using the best security and POP [POP3] environment. Rather than using the best security
available, it means that clients have to be explicitly configured available, it means that clients have to be explicitly configured
to use the separate secure port or suffer the performance loss of to use the separate secure port or suffer the performance loss of
probing for active ports. For IMAP, this is even more serious as probing for active ports. For IMAP, this is even more serious as
it would require the definition of a new URL scheme which would it would require a new URL scheme which could only be resolved by
require support for TLS in order to gain access. TLS-enabled clients.
This specification defines extensions to IMAP4 and POP3 which This specification defines extensions to IMAP4 and POP3 which
activate TLS. It defines a set of server security policy response activate TLS. It also defines a set of server security policy
codes for use with IMAP4, and extends POP3 to permit such response response codes for use with IMAP4. The response codes MAY be used
codes. The response codes MAY be used independently of the TLS independently of the TLS extension.
extension.
0. Open Issues
1. The cipher suite requirement is included to meet the decisions
made at the Munich and Danvers IETF meetings. The additional text
about exportable ciphers is my invention to hopefully improve
interoperability. Comments are welcome.
2. Should I explicitly revoke registration of the IMAP+SSL port?
I'm not inclined to do so as this isn't as serious a design flaw as
the SMTP+SSL port, and there are already deployed IMAP+SSL
implementations.
3. Any security considerations I missed?
1. Conventions Used in this Document 1. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels" in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS]. [KEYWORDS].
Formal syntax is defined using ABNF [ABNF]. Formal syntax is defined using ABNF [ABNF].
In examples, "C:" and "S:" indicate lines sent by the client and In examples, "C:" and "S:" indicate lines sent by the client and
server respectively. server respectively.
2. IMAP4 STARTTLS extension 2. Cipher Suite Requirements
This application profile of TLS follows the standard "Mandatory
Cipher Suites" requirement as documented in the TLS specification
[TLS]. Implementations MUST NOT assume any other cipher suites are
present. It is possible that due to certain government export
restrictions some non-compliant versions of this extension could be
deployed. Implementations wishing to interoperate with such non-
compliant versions MAY offer the
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since 40
bit ciphers are known to be vulnerable to attack by current
technology, any client which actives a 40 bit cipher MUST NOT
indicate to the user that the connection is completely secure from
evesdropping.
3. IMAP4 STARTTLS extension
When the TLS extension is present in IMAP4, "STARTTLS" is listed as When the TLS extension is present in IMAP4, "STARTTLS" is listed as
a capability in response to the CAPABILITY command. This extension a capability in response to the CAPABILITY command. This extension
adds a single command, "STARTTLS" to the IMAP4 protocol which is adds a single command, "STARTTLS" to the IMAP4 protocol which is
used to begin a TLS negotiation. used to begin a TLS negotiation.
2.1. STARTTLS Command 3.1. STARTTLS Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - begin TLS negotiation Result: OK - begin TLS negotiation
NO - security layer already active NO - security layer already active
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
A TLS negotiation begins immediately after the CRLF at the end of A TLS negotiation begins immediately after the CRLF at the end of
skipping to change at page 3, line 29 skipping to change at page 3, line 29
command, it MUST NOT issue further commands until a server command, it MUST NOT issue further commands until a server
response is seen. response is seen.
If STARTTLS is issued in non-authenticated state, the server If STARTTLS is issued in non-authenticated state, the server
remains in non-authenticated state, even if client credentials are remains in non-authenticated state, even if client credentials are
supplied during the TLS negotiation. The SASL [SASL] EXTERNAL supplied during the TLS negotiation. The SASL [SASL] EXTERNAL
mechanism MAY be used to authenticate once TLS client credentials mechanism MAY be used to authenticate once TLS client credentials
are successfully exchanged, but servers supporting the STARTTLS are successfully exchanged, but servers supporting the STARTTLS
command are not required to support the EXTERNAL mechanism. command are not required to support the EXTERNAL mechanism.
Support for the TLS mechanism TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is
REQUIRED by all IMAP software implementing this extension.
Implementations MUST NOT assume any other cipher suite is present.
Unfortunately, it is possible that due to certain government
export restrictions some non-compliant versions of this extension
could be deployed. Implementations wishing to interoperate with
such non-compliant versions MAY offer the
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA mechanism. However, since
40 bit ciphers are known to be vulnerable to attack by current
technology, any client which actives a 40 bit cipher MUST NOT
indicate to the user that the connection is secure from
evesdropping.
The formal syntax for IMAP4 is amended as follows: The formal syntax for IMAP4 is amended as follows:
command_any =/ "STARTTLS" command_any =/ "STARTTLS"
Example: C: a001 CAPABILITY Example: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS S: * CAPABILITY IMAP4rev1 STARTTLS
S: a001 OK CAPABILITY completed S: a001 OK CAPABILITY completed
C: a002 STARTTLS C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now S: a002 OK Begin TLS negotiation now
<TLS negotation begins, futher commands sent under TLS layer> <TLS negotation begins, futher commands sent under TLS layer>
C: a003 LOGIN joe password C: a003 LOGIN joe password
S: a003 OK LOGIN completed S: a003 OK LOGIN completed
3. New IMAP4 response codes 4. New IMAP4 response codes
This specification defines three new IMAP4 response codes which This specification defines three new IMAP4 response codes which
MAY be used to communicate server security policy to the client. MAY be used to communicate server security policy to the client.
These MAY be implemented independently of the STARTTLS command. These MAY be implemented independently of the STARTTLS command.
ENCRYPT-NEEDED This occurs on a tagged NO response to an PASS-EXPIRED
AUTHENTICATE or LOGIN command and indicates that This occurs on a tagged NO response to an AUTHENTICATE or
the requested authentication mechanism is only LOGIN command and indicates the password supplied has expired
permitted underneath a security layer. The client and needs to be changed.
MAY then issue the STARTTLS command and repeat the
same AUTHENTICATE or LOGIN command, or try an
AUTHENTICATE command with a stronger mechanism.
The client SHOULD record the fact that encryption
is needed for that user, server and mechanism
combination.
AUTH-TOO-WEAK This occurs on a tagged NO response to an ENCRYPT-NEEDED
AUTHENTICATE or LOGIN command and indicates that This occurs on a tagged NO response to an AUTHENTICATE or
the mechanism is too weak and is no longer LOGIN command and indicates that the requested authentication
permitted for that user by site policy. This mechanism is only permitted underneath a security layer. The
allows a mechanism to be disabled on a per-user client MAY then issue the STARTTLS command and repeat the
rather than a per-server level which is useful if same AUTHENTICATE or LOGIN command, or try an AUTHENTICATE
different users have different security command with a stronger mechanism. The client SHOULD record
requirements or for transitioning from plaintext the fact that encryption is needed for that user, server and
LOGIN to a more secure mechanism. The client mechanism combination.
SHOULD record the fact that the user, server and
mechanism combination is no longer permitted. AUTH-TOO-WEAK
This occurs on a tagged NO response to an AUTHENTICATE or
LOGIN command and indicates that the mechanism is too weak
and is no longer permitted for that user by site policy.
This allows a mechanism to be disabled on a per-user rather
than a per-server level which is useful if different users
have different security requirements or for transitioning
from plaintext LOGIN to a more secure mechanism. The client
SHOULD record the fact that the user, server and mechanism
combination is no longer permitted.
TRANSITION-NEEDED TRANSITION-NEEDED
This occurs on a tagged NO response to an This occurs on a tagged NO response to an AUTHENTICATE
AUTHENTICATE command. It indicates that the server command. It indicates that the server has an entry for the
has an entry for the specified user in a legacy specified user in a legacy authentication database but does
authentication database but does not yet have not yet have credentials to offer the requested mechanism. A
credentials to offer the requested mechanism. A client which receives this error code MAY do a one-time login
client which receives this error code MAY do a using the LOGIN command or another plaintext mechanism
one-time login using the LOGIN command or another (preferably protected by the STARTTLS command) to initialize
plaintext mechanism (preferably protected by the credentials for the requested mechanism.
STARTTLS command) to initialize credentials for the
requested mechanism.
4. POP3 STARTTLS extension 5. POP3 STARTTLS extension
The POP3 STARTTLS extension adds the STLS command to POP3 servers. The POP3 STARTTLS extension adds the STLS command to POP3 servers.
If this is implemented, the POP3 extension mechanism [POP3EXT] SHOULD
also be implemented to avoid the need for client probing.
STLS STLS
Arguments: none Arguments: none
Restrictions: Restrictions:
MAY be given in any state, but MAY fail if a security layer MAY be given in any state, but MAY fail if a security layer
is already active. is already active.
Discussion: Discussion:
skipping to change at page 5, line 32 skipping to change at page 5, line 17
commands until a server response is seen. commands until a server response is seen.
If STLS is issued in authorization state, the server If STLS is issued in authorization state, the server
remains in authorization state, even if client credentials remains in authorization state, even if client credentials
are supplied during the TLS negotiation. The AUTH command are supplied during the TLS negotiation. The AUTH command
[POP3-AUTH] with the EXTERNAL mechanism [SASL] MAY be used [POP3-AUTH] with the EXTERNAL mechanism [SASL] MAY be used
to authenticate once TLS client credentials are to authenticate once TLS client credentials are
successfully exchanged, but servers supporting the STLS successfully exchanged, but servers supporting the STLS
command are not required to support the EXTERNAL mechanism. command are not required to support the EXTERNAL mechanism.
Support for the TLS mechanism
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA is REQUIRED by all POP3
software implementing this extension. Implementations MUST
NOT assume any other cipher suite is present.
Unfortunately, it is possible that due to certain
government export restrictions some non-compliant versions
of this extension could be deployed. Implementations
wishing to interoperate with such non-compliant versions
MAY offer the TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
mechanism. However, since 40 bit ciphers are known to be
vulnerable to attack by current technology, any client
which actives a 40 bit cipher MUST NOT indicate to the user
that the connection is secure from evesdropping.
Possible Responses: Possible Responses:
+OK -ERR +OK -ERR
Examples: Examples:
C: STLS C: STLS
S: +OK Begin TLS negotiation S: +OK Begin TLS negotiation
<TLS negotiation begins> <TLS negotiation begins>
... ...
C: STLS C: STLS
S: -ERR Security Layer already active S: -ERR Security Layer already active
5. POP3 response code extension 6. POP3 response codes
POP3 is currently only capable of indicating success or failure to
most commands. Unfortunately, clients often need to know more
information about the cause of a failure in order to gracefully
recover. The security policy response codes defined for IMAP in
section 3 are a specific example of this.
This specification amends the POP3 standard to permit an optional
response code, enclosed in square brackets, at the beginning of the
human readable text portion of a "+OK" or "-ERR" response. Clients
supporting this extension MAY remove any information enclosed in
square brackets prior to displaying human readable text to the
user. Immediately following the open square bracket "[" character
is a response code which is interpreted in a case-insensitive
fashion by the client.
The response code is hierarchical, with a "/" separating levels of
detail about the error. Clients MUST ignore unknown hierarchical
detail about the response code. This is important, as it could be
necessary to provide further detail for response codes in the
future. For example, ENCRYPT-NEEDED/TLS and ENCRYPT-NEEDED/SSH
might indicate a suggestion to use the TLS or SSH protocols
respectively for encryption.
Examples:
C: USER mrose
S: -ERR [ENCRYPT-NEEDED] You need to activate encryption before
logging in.
5.1. POP3 response codes
This specification defines three new POP3 response codes which MAY
be used to communicate server security policy to the client.
These MAY be implemented independently of the STARTTLS extension.
ENCRYPT-NEEDED This occurs on an -ERR response to an AUTH, USER or
APOP command and indicates that the requested
authentication mechanism is only permitted
underneath a security layer. The client MAY then
issue the STLS command and repeat the same AUTH,
USER or APOP command or try an AUTH command with a
stronger mechanism. The client SHOULD record the
fact that encryption is needed for that user,
server and mechanism combination.
AUTH-TOO-WEAK This occurs on an -ERR response to an AUTH, USER or
APOP command and indicates that the mechanism is
too weak and is no longer permitted for that user
by site policy. This allows a mechanism to be
disabled on a per-user rather than a per-server
level which is useful if different users have
different security requirements or for
transitioning from plaintext USER/PASS to a more
secure mechanism. The client SHOULD record the
fact that the user, server and mechanism
combination is no longer permitted.
TRANSITION-NEEDED This uses the POP3 response codes defined in [POP3EXT].
This occurs on an -ERR response to an AUTH or APOP
command. It indicates that the server has an entry
for the specified user in a legacy authentication
database but does not yet have credentials to offer
the requested mechanism. A client which receives
this error code MAY do a one-time login using the
USER/PASS commands or another plaintext mechanism
(preferably protected by the STLS command) to
initialize credentials for the requested mechanism.
6. imaps and pop3s ports 7. imaps and pop3s ports
Use of the registered "imaps" and "pop3s" ports is hereby strongly Separate "imaps" and "pop3s" ports were registered for use with
discouraged and considered non-standard behavior. TLS. Use of these ports is discouraged in favor of the STARTTLS
command.
7. Security Considerations One of the arguments used in favor of the separate port technique
is that it simplifies configuration of firewalls which filter by IP
port. However, a quality server implementation running on the
standard port can be configured to require use of the STARTTLS
command or a suitably strong SASL mechanism for non-local
connections. This provides superior functionality as the client
need not be re-configured for use outside the firewall and simpler,
faster non-plaintext SASL mechanisms may be acceptable to many
sites for non-local connections.
8. Security Considerations
The mechanisms described in this document only apply to protecting The mechanisms described in this document only apply to protecting
a single connection. Messages are still available to server a single connection. Messages are still available to server
administrators and usually subject to evesdropping, tampering and administrators and usually subject to evesdropping, tampering and
forgery when transmitted through SMTP or NNTP. Protecting messages forgery when transmitted through SMTP or NNTP. Protecting messages
requires an object security mechanism such as PGP MIME [PGP-MIME]. requires an object security mechanism such as PGP MIME [PGP-MIME].
An active attacker for IMAP can remove STARTTLS from the IMAP An active attacker for IMAP can remove STARTTLS from the IMAP
CAPABILITY list, or cause the POP3 STLS command to fail with a CAPABILITY list, or cause the POP3 STLS command to fail with a
message such as "-ERR Unknown command." In order to detect such an message such as "-ERR Unknown command." In order to detect such an
attack, clients SHOULD either warn the user when session protection attack, clients SHOULD either warn the user when session protection
skipping to change at page 8, line 14 skipping to change at page 6, line 26
If a client uses a weak mechanism which sends the user name at the If a client uses a weak mechanism which sends the user name at the
same time as the authentication credentials, such as IMAP4's LOGIN same time as the authentication credentials, such as IMAP4's LOGIN
command, the ENCRYPT-NEEDED or AUTH-TOO-WEAK error codes will not command, the ENCRYPT-NEEDED or AUTH-TOO-WEAK error codes will not
prevent exposure. For this reason, clients SHOULD record the fact prevent exposure. For this reason, clients SHOULD record the fact
that that user, server and mechanism combination is unacceptable to that that user, server and mechanism combination is unacceptable to
prevent future exposure or be configurable to try stronger prevent future exposure or be configurable to try stronger
mechanisms or activate encryption first. mechanisms or activate encryption first.
An active attacker could cause a bogus TRANSITION-NEEDED response An active attacker could cause a bogus TRANSITION-NEEDED response
to a stronger authentication mechanism. For this reasons, clients to a stronger authentication mechanism. For this reason, clients
SHOULD either activate TLS prior to authentication or get explicit SHOULD either activate TLS prior to authentication or get explicit
permission from the user prior to using a plaintext mechanism for permission from the user prior to using a plaintext mechanism for
automated transition. automated transition.
An attacker might probe for users at a site by trying a strong An attacker might probe for users at a site by trying a strong
authentication mechanism which could result in TRANSITION-NEEDED authentication mechanism which could result in TRANSITION-NEEDED
for some users. Strong mechanisms can progress partway through for some users. Strong mechanisms can progress partway through
negotiation prior to issuing the TRANSITION-NEEDED failure message negotiation prior to issuing the TRANSITION-NEEDED failure message
in order to avoid this problem. in order to avoid this problem.
skipping to change at page 8, line 37 skipping to change at page 7, line 5
could use these error codes for unknown users to defeat this could use these error codes for unknown users to defeat this
attack. Delaying the error until after the PASS command is attack. Delaying the error until after the PASS command is
supplied would unnecessarily reveal a user's password and thus supplied would unnecessarily reveal a user's password and thus
would be a far more serious problem than probing for users. would be a far more serious problem than probing for users.
An active attacker can always cause a down-negotiation to the An active attacker can always cause a down-negotiation to the
weakest authentication mechanism or cipher suite available. For weakest authentication mechanism or cipher suite available. For
this reason, implementations need to be configurable to refuse weak this reason, implementations need to be configurable to refuse weak
mechanisms or cipher suites. mechanisms or cipher suites.
8. References 9. References
[ABNF] Crocker, "Augmented BNF for Syntax Specifications: ABNF", work [ABNF] Crocker, "Augmented BNF for Syntax Specifications: ABNF", work
in progress. in progress.
[IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text [IMAIL] Crocker, D., "Standard for the Format of Arpa Internet Text
Messages", RFC 822, University of Delaware, August 1982. Messages", RFC 822, University of Delaware, August 1982.
<ftp://ds.internic.net/rfc/rfc822.txt> <ftp://ds.internic.net/rfc/rfc822.txt>
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1",
RFC 2060, University of Washington, December 1996. RFC 2060, University of Washington, December 1996.
<ftp://ds.internic.net/rfc/rfc2060.txt> <ftp://ds.internic.net/rfc/rfc2060.txt>
[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731, [IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731,
Carnegie-Mellon University, December 1994. Carnegie-Mellon University, December 1994.
<ftp://ds.internic.net/rfc/rfc1731.txt> <ftp://ds.internic.net/rfc/rfc1731.txt>
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, Harvard University, March 1997. Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt> <ftp://ds.internic.net/rfc/rfc2119.txt>
[PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", [PGP-MIME] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)",
RFC 2015, The Aerospace Corporation, October 1996. RFC 2015, The Aerospace Corporation, October 1996.
<ftp://ds.internic.net/rfc/rfc2015.txt> <ftp://ds.internic.net/rfc/rfc2015.txt>
[POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC [POP3] Myers, J., Rose, M., "Post Office Protocol - Version 3", RFC
1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996. 1939, Carnegie Mellon, Dover Beach Consulting, Inc., May 1996.
<ftp://ds.internic.net/rfc/rfc1939.txt> <ftp://ds.internic.net/rfc/rfc1939.txt>
[POP3EXT] Newman, "POP3 Extension Mechanism and Error Codes", Work in
progress.
[POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie [POP-AUTH] Myers, "POP3 AUTHentication command", RFC 1734, Carnegie
Mellon, December 1994. Mellon, December 1994.
<ftp://ds.internic.net/rfc/rfc1734.txt> <ftp://ds.internic.net/rfc/rfc1734.txt>
[SASL] Myers, "Simple Authentication and Security Layer (SASL)", Work [SASL] Myers, "Simple Authentication and Security Layer (SASL)", RFC
in progress. 2222, Netscape Communications, October 1997.
<ftp://ds.internic.net/rfc/rfc2222.txt>
[TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress. [TLS] Dierks, Allen, "The TLS Protocol Version 1.0", Work in progress.
9. Author's Address 10. Full Copyright Statement
Copyright (C) The Internet Society 1997. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing the copyright notice or references to the Internet
Society or other Internet organizations, except as needed for the
purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards process
must be followed, or as required to translate it into languages
other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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.
11. Author's Address
Chris Newman Chris Newman
Innosoft International, Inc. Innosoft International, Inc.
1050 Lakes Drive 1050 Lakes Drive
West Covina, CA 91790 USA West Covina, CA 91790 USA
Email: chris.newman@innosoft.com Email: chris.newman@innosoft.com
 End of changes. 28 change blocks. 
164 lines changed or deleted 122 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/