< draft-newman-sasl-plaintrans-03.txt   draft-newman-sasl-plaintrans-04.txt >
Network Working Group C. Newman Network Working Group C. Newman
Internet Draft: Plaintext Password SASL Mechanism Innosoft Internet Draft: Plaintext Transition Innosoft
Document: draft-newman-sasl-plaintrans-03.txt July 1997 Document: draft-newman-sasl-plaintrans-04.txt November 1997
Expires in six months Expires in six months
Plaintext Password SASL Mechanism and Transition Strategy Plaintext Password SASL Mechanism for Transitioning
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
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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).
Abstract Abstract
While plaintext passwords have very poor security characteristics Unencrypted plaintext passwords are the biggest single risk to
by themselves, there are a number of contexts where they are useful Internet application protocol security. Unfortunately, they are
or necessary. This defines a plaintext password mechanism for SASL widely deployed, often tightly integrated into operating system
[SASL] which is intended to be used in combination with an external services and very difficult to replace in an interoperable fashion.
encryption layer, as a transition mechanism from a legacy
authentication database, or to use (insecurely) a legacy
authentication database which can not practically be replaced.
In hopes of promoting the future elimination of unencrypted This specification discusses some methods which can be used to
plaintext passwords, this defines error codes for use with POP3 and eliminate unencrypted plaintext passwords. It also defines a SASL
IMAP4: one to indiciate the need for a transition to a stronger mechanism [SASL] which may be used by newer protocols such as ACAP
mechanism, a second to indicate that a SASL mechanism is too weak [ACAP] to transition away from a legacy authentication database.
for per-user security policy for a given service, and a third to
indicate that a SASL mechanism is only accepted in combination with
an external strong encryption mechanism. Any protocol offering the
PLAIN mechanism SHOULD also support equivalent error codes.
1. Conventions Used in this Document 1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as defined in "Key words for in this document are to be interpreted as defined in "Key words for
use in RFCs to Indicate Requirement Levels" [KEYWORDS]. use in RFCs to Indicate Requirement Levels" [KEYWORDS]. However,
it is important to understand that this is not an IETF standards
track document and therefore the key words only apply to
conformance with this specification independent of any standards
body.
2. Security Impact of Plaintext Passwords 2. Security Impact of Unencrypted Plaintext Passwords
Use of unencrypted plaintext passwords over the Internet is a Use of unencrypted plaintext passwords over the Internet is a
severe security risk. In particular, a passive observer can get severe security risk. In particular, a passive observer can get
the password with any packet sniffer. This requires no technical the password with any packet sniffer. This requires no technical
expertise, as one can simply plug a consumer level computer into expertise, as one can simply plug a consumer level computer into
the network and run widely available network snoop programs. Such the network and run widely available network snoop programs. Such
attacks are difficult or impossible to detect, and can only be attacks are difficult or impossible to detect, and can only be
prevented by complete physical and virtual security of the network prevented by complete physical and virtual security of the network
between the client and server -- something which is usually between the client and server -- something which is usually
impossible to achieve. impossible to achieve.
Unfortunately, most modern servers use legacy authentication Unfortunately, most modern servers use legacy authentication
databases, usually tightly integrated with the operating system, databases, often tightly integrated with the server's operating
which apply a one-way function to the user's password preventing system. These databases usually apply a one-way function to the
the use of any mechanism other than plaintext passwords. This user's password so that server break-ins only expose the users to
means that plaintext passwords are the only authentication dictionary attacks (testing likely passwords) and trojan horse
technology today which will work with the vast majority of deployed server attacks (e.g., replacing the server with one which records
authentication databases. Often the cost of deploying a new user passwords). The result is that plaintext passwords are the
authentication technology or having different authentication only authentication technology today which will work with the vast
credentials for different services outweighs the security risks of majority of deployed authentication databases.
plaintext passwords.
Thus there are three situations where plaintext passwords are 3. Transition Strategies
necessary or useful:
(1) As a method to transition, on a per-user basis, from a legacy There are several techniques which a site may use to transition
authentication database a secure password mechanism such as from unencrypted plaintext passwords. None of these are easy, but
CRAM-MD5 [CRAM-MD5]. sites are STRONGLY ENCOURAGED to make the effort before a security
breach occurs.
(2) As the only feasible mechanism when a legacy authentication 3.1. Deploying Encryption
database is in use, multiple remote services are offered, there is
no way to transition all the remote services, and it is
unacceptable to have different passwords for different services.
(3) In conjunction with a strong encryption layer. One way to eliminate unencrypted plaintext passwords is to deploy
encryption services for all protocols which use plaintext
passwords. This is probably the most viable technique for sites
which use a legacy authentication database, run servers from
different vendors, and are unable to modify all password changing
services.
In all other cases, plaintext passwords SHOULD NOT be used. In There are several drawbacks to this. First, several common public
addition, any client or server supporting this mechanism SHOULD key protocols are very expensive to deploy both in terms of
also support a strong encryption layer or a stronger authentication administrative retraining and in order to purchase licenses,
mechanism. software and certification. Second, for many simple protocols the
encryption and public key services will be many times more
complicated than the base protocol they protect. Third, it is
illegal to use or export sufficiently strong encryption in many
countries. Fourth, some currently deployed software using the
non-standard SSL protocol is export crippled to 40-bit keys which
is only marginally better than plaintext passwords. And even
worse, some of this export-crippled software misleads the user into
believing it is secure. Finally, the only current standards-track
protocol suitable to encrypt TCP based protocols carrying passwords
is [IPESP] which is difficult to deploy due to the need for support
in the TCP/IP stack.
3. Plaintext Password SASL mechanism The TLS protocol, a work in progress, may address the last two
problems. The secure shell protocol, another work in progress, may
also address the first two problems.
The mechanism name associated with plaintext passwords is "PLAIN". 3.2. One Time Upgrade to New Authentication System
Sites with sufficient control over their infrastructure may be able
to deploy a new authentication system. This requires support from
all clients, servers, remote login services and password changing
services at the site.
There are several drawbacks to this approach. First, it requires
all users to change their password or enter a new password.
Second, it is very difficult to get support for the same mechanism
in all the necessary components. Third, this is likely to require
a single-vendor server solution as the only standards track option
for interoperable server authentication is RADIUS [RADIUS] and it
is designed solely for use by network access servers and protocol
support is only available in PPP.
3.3. Gradual Transition on Password Change
A gradual transition can be achieved my modifying all password
change services to set the password in both the old an new
authentication systems. Components can be individually updated to
use the new authentication system once both verifiers are
available. This requires support from all password changing
services at the site.
There are several drawbacks to this approach. First, it is likely
to require parallel databases for a long time as it will be
difficult to phase out the old system due to the need to upgrade
all services and users (especially those who rarely change their
password). Second, this is likely to require a single-vendor
server solution as the only standards track option for
interoperable server authentication is RADIUS [RADIUS] and it is
designed solely for use by network access servers and protocol
support is only available in PPP.
3.4. Gradual Transition on Plaintext Mechanism
A gradual transition can be achieved by permitting use of a
plaintext mechanism to authenticate to the old authentication
service and create an entry in the new service. This also requires
modifying all password change services.
There are several drawbacks to this approach. First, it is likely
to require parallel databases until all services have been upgraded
although it is a faster transition than that described in section
3.3. Second, it requires some support in protocols. Third, this
is likely to require a single-vendor server solution as the only
standards track option for interoperable server authentication is
RADIUS [RADIUS] and it is designed solely for use by network access
servers and protocol support is only available in PPP.
4. Error Codes For Transition
A number of error codes are defined in ACAP [ACAP] which may be
used by ACAP and similar protocols to assist transition. This
further explains those error codes and adds an additional error
code "EXPIRED-PASS." These error codes are also suitable for use
with IMAP [IMAP4].
EXPIRED-PASS
This indicates the user's password or passphrase has expired
and needs to be changed. This is useful both for transition
strategy 3.3, and to force users to change their password or
passphrase more frequently.
TRANSITION-NEEDED
This occurs after a client attempts to authenticate using a
mechanism other than plaintext. 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 PLAIN mechanism (or another
plaintext mechanism) after asking the user for permission to
activate the transition. Alternatively, the client could
inform the user that they must change their password to
transition. This is useful for transition strategy 3.4.
AUTH-TOO-WEAK
This indicates that the authentication mechanism is too weak
for that user according to site security policy and that a
stronger mechanism must be used instead. A client which
receives this error code should try a stronger mechanism if
available and stop using the weaker mechanism for that user.
ENCRYPT-NEEDED
This indicates that external strong encryption is needed in
order to use the requested authentication mechanism. This is
primarily intended for use with the PLAIN mechanism. A client
which receives this may activate an encryption layer or try a
stronger mechanism if available.
5. Plaintext Password SASL mechanism
Newer protocols, such as ACAP [ACAP], require a plaintext mechanism
in order to implement transition strategy 3.4. This defines a
mechanism suitable for that purpose. If this mechanism is
implemented, it is important that it can be disabled by
configuration.
The SASL [SASL] mechanism name is "PLAIN".
The mechanism consists of a single message from the client to the The mechanism consists of a single message from the client to the
server. The client sends the authorization identity, followed by a server. The client sends the authorization identity (identity to
US-ASCII NUL character, followed by the authentication identity, login as), followed by a US-ASCII NUL character, followed by the
authentication identity (identity whose password will be used),
followed by a US-ASCII NUL character, followed by the plaintext followed by a US-ASCII NUL character, followed by the plaintext
password. The client may leave the authorization identity empty to password. The client may leave the authorization identity empty to
indicate that it is the same as the authentication identity. indicate that it is the same as the authentication identity.
The server will verify the authentication identity and password The server will verify the authentication identity and password
with the system authentication database and verify that the with the system authentication database and verify that the
authentication credentials permit the client to login as the authentication credentials permit the client to login as the
authorization identity. If both these steps succeed, the user is authorization identity. If both steps succeed, the user is logged
logged in. in.
When used as a transition mechanism, the password will be stored in When used as a transition mechanism, the password will be stored in
a new authentication database capable of supporting stronger a new authentication database capable of supporting stronger
authentication mechanisms. Once this is completed, the server MAY authentication mechanisms. Once this is completed, the server MAY
refuse future use of the PLAIN mechanism by that authentication refuse future use of the PLAIN mechanism by that authentication
identity. identity.
Non-US-ASCII characters are permitted as long as they can be Non-US-ASCII characters are permitted as long as they can be
represented in UTF-8 [UTF8]. Use of non-visible characters or represented in UTF-8 [UTF8]. Use of non-visible characters or
characters which a user may be unable to enter on some keyboards is characters which a user may be unable to enter on some keyboards is
discouraged. discouraged.
The formal grammar for the client message using Augmented BNF The formal grammar for the client message using Augmented BNF
[ABNF] follows. [ABNF] follows.
message = [authorize-id] NUL authenticate-id NUL password message = [authorize-id] NUL authenticate-id NUL password
NUL = %x00 NUL = %x00
US-ASCII-SAFE = %x01..09 / %x0B..0C / %x0E..7F US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL ;; US-ASCII except CR, LF, NUL
UTF8-SAFE = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3 UTF8-SAFE = US-ASCII-SAFE / UTF8-2 / UTF8-3 / UTF8-4
/ UTF8-4 / UTF8-5 / UTF8-5 / UTF8-6
UTF8-CONT = %x80..BF UTF8-1 = %x80-BF
UTF8-1 = %xC0..DF UTF8-CONT UTF8-2 = %xC0-DF UTF8-1
UTF8-2 = %xE0..EF 2UTF8-CONT UTF8-3 = %xE0-EF 2UTF8-1
UTF8-3 = %xF0..F7 3UTF8-CONT UTF8-4 = %xF0-F7 3UTF8-1
UTF8-4 = %xF8..FB 4UTF8-CONT
UTF8-5 = %xFC..FD 5UTF8-CONT UTF8-5 = %xF8-FB 4UTF8-1
UTF8-6 = %xFC-FD 5UTF8-1
authenticate-id = 1*255UTF8-SAFE authenticate-id = 1*255UTF8-SAFE
authorize-id = 1*255UTF8-SAFE authorize-id = 1*255UTF8-SAFE
password = 1*255UTF8-SAFE password = 1*255UTF8-SAFE
4. New Error/Response Codes 6. Gradual Transition on PLAIN Example
When used as a transition mechanism, two new response codes are
helpful to provide guidance to clients. A third response code is
useful to indicate the need for an external encryption mechanism.
The failure codes for use with IMAP4 [IMAP4] are defined here:
TRANSITION-NEEDED
This IMAP response code occurs on the tagged NO response to an
AUTHENTICATE command after an attempt to use a mechanism other
than PLAIN. It indicates that that mechanism is not currently
usable, but will be usable once "AUTHENTICATE PLAIN" or LOGIN
is used.
AUTH-TOO-WEAK
This IMAP response code occurs on the tagged NO response to a
LOGIN or AUTHENTICATE command. It indicates that the
requested mechanism is not available to the specified user
based on site security policy. This may also be used on the
untagged OK response to a LOGIN or "AUTHENTICATE PLAIN"
command to indicate that plaintext passwords will not be
accepted from that user at a later date.
ENCRYPT-NEEDED
This IMAP response code occurs on the tagged NO response to a
LOGIN or AUTHENTICATE command. It indicates that the
specified mechanism may only be used in combination with an
external strong encryption service. This is intended
primarily for use with plaintext passwords.
The failure codes for use with POP3 [POP3] are defined here:
-ERR [TRANSITION-NEEDED] A password transition is needed.
The portion between the "[" and "]" is a machine parsable
message, interpreted in a case insensitive fashion. The
remainer of the line may contain any implementation-specific
human readable text.
This occurs in response to an APOP or AUTH [POP-AUTH] command
that is not currently available, but will be available after
the use of the PLAIN mechanism or the USER/PASS commands.
-ERR [AUTH-TOO-WEAK] Plaintext passwords forbidden
This occurs in response to a USER, PASS, APOP or AUTH command
and indicates that the server no longer permits the requested
authentication mechanism due to site security policy. It may
also occur on a "+OK" line after a successful PASS or AUTH
PLAIN command to indicate that plaintext passwords will not be
accepted from that user at a later date.
-ERR [ENCRYPT-NEEDED] Plaintext passwords need encryption
This occurs in response to a USER, PASS, APOP or AUTH command
and indicates that the server does not permit use of the
specified mechanism except with an external encryption
mechanism for the specified user. This is intended primarily
for use with plaintext passwords.
5. Example
Here is a sample transition exchange between an IMAP client and Here is a sample transition exchange between an IMAP client and
server. In this example, "C:" and "S:" indicate lines sent by the server. In this example, "C:" and "S:" indicate lines sent by the
client and server respectively. If such lines are wrapped without client and server respectively. If such lines are wrapped without
a new "C:" or "S:" label, then the wrapping is for editorial a new "C:" or "S:" label, then the wrapping is for editorial
clarity and is not part of the command. clarity and is not part of the command.
Note that this example uses the IMAP profile [IMAP4] of SASL. The Note that this example uses the IMAP profile [IMAP4] of SASL. The
base64 encoding of challenges and responses, as well as the "+ " base64 encoding of challenges and responses, as well as the "+ "
preceding the responses are part of the IMAP4 profile, not part of preceding the responses are part of the IMAP4 profile, not part of
SASL itself. Newer profiles of SASL will include the client SASL itself. Newer profiles of SASL will include the initial
message with the AUTHENTICATE command itself so the extra round client PLAIN message with the AUTHENTICATE command itself so the
trip below (the server response with an empty "+ ") can be extra round trip below (the server response with an empty "+ ") can
eliminated. be eliminated.
In this example, the user's authentication identifier is "tim", his In this example, the user's authentication identifier is "tim", his
authorization identifier is the same, and his password is authorization identifier is the same, and his password is
"tanstaaftanstaaf". "tanstaaftanstaaf".
S: * OK IMAP4 server ready S: * OK IMAP4 server ready
C: A001 CAPABILITY C: A001 CAPABILITY
S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAIN S: * CAPABILITY IMAP4 IMAP4rev1 AUTH=CRAM-MD5 AUTH=PLAIN
S: A001 OK done S: A001 OK done
C: A002 AUTHENTICATE CRAM-MD5 C: A002 AUTHENTICATE CRAM-MD5
S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+ S: + PDE4OTYuNjk3MTcwOTUyQHBvc3RvZmZpY2UucmVzdG9uLm1jaS5uZXQ+
C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw C: dGltIGI5MTNhNjAyYzdlZGE3YTQ5NWI0ZTZlNzMzNGQzODkw
S: A002 NO [TRANSITION-NEEDED] You can't login securely until S: A002 NO [TRANSITION-NEEDED] You can't login securely until
you've changed your password on the server you've changed your password on the server
<client gets permission from user to transition>
C: A003 AUTHENTICATE PLAIN C: A003 AUTHENTICATE PLAIN
S: + S: +
C: AHRpbQB0YW5zdGFhZnRhbnN0YWFm C: AHRpbQB0YW5zdGFhZnRhbnN0YWFm
S: A003 OK You can now login securely in the future. S: A003 OK You can now login securely in the future.
C: A004 SELECT INBOX C: A004 SELECT INBOX
... ...
6. Security Considerations 7. Security Considerations
Security considerations are discussed throughout this document. Security considerations are discussed throughout this document.
A man in the middle or a spoof server may be able to aquire the A man in the middle or a spoof server may be able to aquire the
user's password by pretending no strong authentication mechanisms user's password by removing the announcement of available strong
are available. The are two steps the client can take to help authentication mechanisms. Clients SHOULD record the available of
defeat such attacks. First, clients MAY record the occurance of an strong authentication mechanisms on a given server and/or allow
AUTH-TOO-WEAK or ENCRYPT-NEEDED error for a given user, server and explicit configuration to prevent use of the PLAIN mechanism.
protocol combination and refuse to use unencrypted plaintext
passwords for that combination in the future. Second, clients
SHOULD get permission from the user prior to using an unencrypted
plaintext password, especially in response to a TRANSITION-NEEDED
response code. If the user normally makes a secure connection and
suddenly sees a warning, this might prevent a password compromise.
Unencrypted plaintext passwords are visible to any network snooper, Some authentication mechanisms are susceptible to passive
as discussed in section 2. Servers SHOULD have the ability to dictionary attacks. Password change agents should check new
enable the AUTH-TOO-WEAK or ENCRYPT-NEEDED errors on a per-user passwords against a dictionary and reject matches in order to
basis to ease the transition away from unencrypted plaintext reduce the effectiveness of this attack.
passwords.
7. References As there have been successful amateur attacks on 40-bit and 56-bit
keys these are not deemed adequate security for passwords. The
PLAIN mechanism SHOULD be used in combination with an external
encryption layer using a key of sufficient strength to prevent
attack.
8. References
[ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications:
ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt ABNF", Work in progress: draft-ietf-drums-abnf-xx.txt
[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
Protocol", work in progress.
[CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension [CRAM-MD5] Klensin, Catoe, Krumviede, "IMAP/POP AUTHorize Extension
for Simple Challenge/Response", RFC 2095, MCI, January 1997. for Simple Challenge/Response", RFC 2195, MCI, September 1997.
<ftp://ds.internic.net/rfc/rfc2095.txt> <ftp://ds.internic.net/rfc/rfc2195.txt>
[IMAP4] Crispin, M., "Internet Message Access Protocol - Version [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, University of Washington, December 1996. 4rev1", RFC 2060, University of Washington, December 1996.
<ftp://ds.internic.net/rfc/rfc2060.txt> <ftp://ds.internic.net/rfc/rfc2060.txt>
[IPESP] Atkinson, "IP Encapsulating Security Payload (ESP)", RFC
1827, Naval Research Laboratory, August 1995.
<ftp://ds.internic.net/rfc/rfc1827.txt>
[KERBEROS-GSS] Linn, "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, OpenVision Technologies, June 1996.
<ftp://ds.internic.net/rfc/rfc1964.txt>
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997. Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ds.internic.net/rfc/rfc2119.txt> <ftp://ds.internic.net/rfc/rfc2119.txt>
[MIME-SEC] Galvin, Murphy, Crocker, Freed, "Security Multiparts for
MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, Trusted
Information Systems, CyberCash, Innosoft International, October
1995.
<ftp://ds.internic.net/rfc/rfc1847.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>
[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>
[RADIUS] Rigney, Rubens, Simpson, Willens, "Remote Authentication
Dial In User Service (RADIUS)", RFC 2138, Livingston, Merit,
Daydreamer, April 1997.
<ftp://ds.internic.net/rfc/rfc2138.txt>
[SASL] Myers, "Simple Authentication and Security Layer (SASL)", [SASL] Myers, "Simple Authentication and Security Layer (SASL)",
work in progress. RFC 2222, Netscape Communications, October 1997.
<ftp://ds.internic.net/rfc/rfc2222.txt>
[UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and [UTF8] Yergeau, F. "UTF-8, a transformation format of Unicode and
ISO 10646", RFC 2044, Alis Technologies, October 1996. ISO 10646", RFC 2044, Alis Technologies, October 1996.
<ftp://ds.internic.net/rfc/rfc2044.txt> <ftp://ds.internic.net/rfc/rfc2044.txt>
8. Acknowledgements 9. Acknowledgements
Thanks to John Myers and Larry Osterman for providing feedback on Thanks to John Myers, Larry Osterman, Ned Freed and Kevin Carosso
the initial version of this specification. Thanks to Ned Freed and for feedback on this proposal.
Kevin Carosso for coming up with the basic plaintext transition
idea.
9. Author's Address 10. 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. 40 change blocks. 
147 lines changed or deleted 227 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/