Network Working Group J. Klensin
Internet-Draft July 12, 2004
Expires: January 10, 2005
A Name Munging Protocol
draft-klensin-name-munging-03.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
As one works on internationalization issues for DNS, email, and other
protocols, it becomes clear that the various encodings and
transformations required, while not intrinsically difficult, can be
an impediment to rapid conversion of applications to international
form and to rapid prototyping of new applications. This document
proposes a new, lightweight, protocol that can be used to make such
conversions, rather than incorporating the needed tables and
algorithms into each application.
Klensin Expires January 10, 2005 [Page 1]
Internet-Draft A Name Munging Protocol July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
2. The Protocol . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Inputs . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Element definitions . . . . . . . . . . . . . . . . 4
2.3 Initial List of Encodings . . . . . . . . . . . . . 4
2.4 Outputs . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Reply codes . . . . . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Signed Messages and Business Arrangements . . . . . . . 6
5. Availability . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . 9
A. A Security-Enhanced Variation . . . . . . . . . . . . . ancho
A.1 Input . . . . . . . . . . . . . . . . . . . . . . . ancho
A.2 Output . . . . . . . . . . . . . . . . . . . . . . . ancho
Intellectual Property and Copyright Statements . . . . . 10
Klensin Expires January 10, 2005 [Page 2]
Internet-Draft A Name Munging Protocol July 2004
1. Introduction
A variety of new and upcoming protocols, most, but not all, of them
associated with internationalization, require that data be presented
in, or mapped into, encoding forms that are specialized and largely
unique to the Internet or those protocols. The trend arguably
started with the introduction of quoted-printable into MIME [RFC1341]
and has continued to more recent DNS internationalization work
[RFC3490] and developing errors in internationalization of electronic
mail [I-D.hoffman-imaa]. These encodings are at least complex enough
that testing for interoperability and accuracy is perceived to be
needed. Even though they are not, intrinsically, very hard, the
process of getting the needed code incorporated and tested may be
sufficient to discourage or delay internationalization of some
applications, including those that are built around short scripts.
This document describes a protocol -- designed for use over either
TCP or UDP -- that can be passed short strings for conversion from
one encoding to another. There are various samples, testbeds, and
web pages today that can do some of these conversions, but they are
not general (few of them handle more than one or two conversions),
and they are really not compatible with use in applications
implementation (regardless of whether they can be used in testing or
not). The core code in those samples and tests could presumably be
adapted to support this protocol.
2. The Protocol
The protocol is designed to be as simple as possible, following the
general "send packet containing one line, get another line back"
model used in finger [RFC1288] and whois [RFC0954]. That model is
traditional and well-proven in the Internet, but, by today's
standards, sacrifices a high degree of security for performance and
should be used with appropriate care. The appendix contains an
outline description of a possible variant on this protocol for
situations in which it is desired to have, within the protocol
itself, some degree of authentication that the intended server was
reached and the response received is from it, but, in general some
type of authenticated tunnel mechanism will be more satisfactory.
See Section 5, Section 4, and Section 7 for additional discussion of
these issues. For performance, the protocol is designed to be used
over either UDP or TCP, as meets the needs of the application. The
TCP variation on the above is, obviously, "open a connection, send a
line, remote system sends a line back and closes the connection".
The lines are defined as follows:
Klensin Expires January 10, 2005 [Page 3]
Internet-Draft A Name Munging Protocol July 2004
2.1 Inputs
The input line consists of
o A Version number, "1" for this variation on the protocol.
o An ASCII space (i.e., an octet containing hex 20)
o A source-indication string
o An ASCII space
o A target-indication string
o An ASCII space
o A bit count, expressed as an ASCII numeral
o An ASCII space
o The source bit string
2.2 Element definitions
The version number is a positive integer, defined as "1" in this
version of the protocol. Implementations of this version of the
protocol are required to check the version number and, if it is not
"1", to return a string consisting of "550 bad version number" (see
below). The indication strings are positive integers, registered
with IANA and described in Section 2.3, below.
The integers for the version number, indicator strings, and bit count
are expressed as decimal numbers using ASCII digits. They, and the
single ASCII space character that follows each one, are protocol
elements and are not intended to be internationalized.
The source string will be a simple string of bits, of length
specified by the bit count (with the first bit counted as one).
While it will normally be an integral number of octets, some special
encodings may not permit this, so any extra bits are ignored. For
convenience, the bit count may be specified as an ASCII asterisk
("*", an octet containing hex 2A), in which case the server will
examine the string for the first pair of octets containing,
respectively, hex 0D and 0A (the usual CRLF convention) and consider
it to terminate immediately before those characters.
2.3 Initial List of Encodings
As discussed below, IANA is expected to set up a registry of encoding
codes for use in this protocol. That list is initially:
0 Information and debugging option. If 0 appears as the input
indicator, the rest of the input line is ignored and the server
returns a reply code of "000 " followed by a blank-separated list
of the indicator codes it recognizes. If 0 appears as the output
indication, the input is copied to the output, also with a reply
code of 000, and returned.
Klensin Expires January 10, 2005 [Page 4]
Internet-Draft A Name Munging Protocol July 2004
1 UCS-4
2 Unicode (UCS-2)
3 IDNA Punycode
4 The IMAA encoding scheme described in [I-D.hoffman-imaa]
5 UTF-8
6 ISO 8859-1
7 Unicode written as a blank-separated list of four or more
hexadecimal digit codes (written in ASCII), and with each set of
codes optionally preceded by "U+" or "u+". The hexadecimal codes
"A"..."F" may be written in either upper or lower case.
8 Nameprep (stringprep profile only, no punycode)
9 SASLprep (stringprep profile only, no punycode)
10 iSCSIprep (stringprep profile only, no punycode)
There is no requirement that every server support every encoding,
although it is expected that every server will support the "0"
encoding for test purposes. Issues of how a client locates an
appropriate server are outside the scope of this specification (see
Section 5).
2.4 Outputs
The version 1 output consists of
o a three-digit (ASCII) reply code (codes listed below)
o an ASCII space
o a bit count
o an ASCII space
o a string
The bit count, space, and string are as described above, but the "*"
convention will not be used.
2.5 Reply codes
The following reply codes are specified for use in this protocol.
If, for some reason (presumably due to a new version of the protocol
on the server), the three-digit code returned is not listed below,
only the first digit should be examined. A first digit of zero
indicates that the string returned contains either the original
string or a recoding of it; a first digit of 5 indicates that the
recoding failed and the string is either zero-length or contains an
explanation in ASCII characters.
000 String translated
001 String not translated
500 Service not available to you
Klensin Expires January 10, 2005 [Page 5]
Internet-Draft A Name Munging Protocol July 2004
501 Input encoding type not recognized
502 Output encoding type not recognized
503 Bit count exceeds length of line
504 No translation available, i.e., the server recognizes the input
encoding and the output encoding, but has no mapping between them.
505 Translation failed or input string invalid, e.g., the input
string was not a possible example of the input encoding specified.
506 Input string too long.
550 Wrong version number, i.e., version number specified is not
understood by this server.
6yz Authentication, authorization, or other security problem.
Reserved for future use.
3. Examples
1 6 0 10 teststring
000 10 teststring
1 6 3 9 Fltstr÷m
I.e., with the second and eighth characters as a-with-diaeresis
(U+00E4) and o-with-diaeresis (U+00F6) respectively.
000 12 xn--fltstrm-5wa1o
4. Signed Messages and Business Arrangements
In today's sometimes-hostile Internet environment, two questions
immediately arise about a protocol that is designed to be this
simple. One is how one tells that the returned string is the
intended one, i.e., that it came from the designated server and that
some is taking responsibility for that server's results. The other
is how to get someone to provide this service, especially if it is to
be called from production-scale applications protocols. Either or
both requirements might be satisfied by sending digitally-signed
strings. In the input (business model) case, we might imagine a
subscription service with registered users, with the digital
signature used to authenticate the query as coming from a subscriber
and/or authorize billing. In the output case, we might imagine a
family of certified servers (using a certification process that lies
outside this specification) able to sign the responses with a key the
user or application would trust. Both of these issues, and the
protocol changes that would be required, should be examined in depth
before this protocol is published.
At least for the TCP version of the protocol, both of these issues
could be dealt with independently of the protocol itself, e.g., by
running it over fully-authenticated IPSec or SSL.
Klensin Expires January 10, 2005 [Page 6]
Internet-Draft A Name Munging Protocol July 2004
This specification does not cover identification and location of
appropriate servers.
5. Availability
As suggested elsewhere in this document, it is expected that this
protocol will be used primarily within controlled environments, or
with servers accessed through tunnels that provide both client and
server authentication. Sample PERL source for client and server
implementations, contributed by Paul Hoffman, will be deposited with
the RFC Editor.
6. IANA Considerations
IANA has assigned reserved port number 3950 for both the UDP and TCP
variations of this protocol.
A registry of encoding type indicator strings is also required, with
a sequential integer to be assigned to each type of encoding
registered and the list in Section 2.3 used to initialize that
registry. IANA is requested to accept registrations only with
contact information and a reference that defines the encoding
involved, but, since there is no shortage of integers, checking and
evaluation of such requests is not required except to the degree
required to prevent denial of service attacks on IANA itself.
The conversions defined and supported are one-to-one mappings only.
This protocol, or at least this version of the protocol, does not
support any one-many, or otherwise ambiguous, mappings.
No IANA registry is required for version numbers: versions other than
the one described here will require a revised version of this
specification.
7. Security Considerations
As mentioned in Section 4, there is an attack on this protocol,
especially in which it is used over UDP, in which a response is sent
to the client application that contains an encoding of a different
string than the one that was submitted. If that string is used
without inspection or review by the client, various bad things might
happen. Signed strings, as discussed above, might protect against
that problem, but only if keys are properly protected and verified.
If assurances are needed that the server is the intended one, it is
recommended that the protocol be operated over an appropriately
configured tunnel. An extension for SASL negotiation is possible in
principle, but would be incompatible with operation of the protocol
over UDP and would be likely to defeat the intent of a very high
Klensin Expires January 10, 2005 [Page 7]
Internet-Draft A Name Munging Protocol July 2004
performance protocol design.
For those situations in which authentication of the server (and
response source) to the client is useful, an alternative version of
the protocol is specified with a minimal digest challenge-response
mechanism. Since that mechanism depends on a secret shared between
the client and server, it is likely to be useful, if at all, in
restricted environments such as a small department or group that does
not consider whatever group-isolation firewalls or similar mechanisms
adequate to protect against server spoofing attacks. For any sort of
public use, the mechanism is subject to the well-known problems of a
secret known to hundreds of people and is hence likely to be useless.
As discussed elsewhere in this document, authenticity and integrity
protection when public servers and the public Internet are involved
are probably best dealt by running this protocol within an
authenticated and cryptographically protected tunnel or, in
principle, by extending the protocol to utilize some sort of public
key message-signing mechanism.
8. Acknowledgements
The author would like to express appreciation to Patrik Faltstrom and
Leslie Dangle, who made some suggestions at a early formative stage
of this proposal and, in particular, pointed out the desirability of
digitally signing the strings. Paul Hoffman made a number of other
useful suggestions and contributed the first implementation. Simon
Josefsson suggested the addition of type codes for several additional
stringprep profiles. And the decision to modify the protocol to add
a version number emerged from a discussion with Harald Alvestrand.
9. References
9.1 Normative References
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000.
9.2 Informative References
[I-D.hoffman-imaa]
Hoffman, P. and A. Costello, "Internationalizing Mail
Addresses in Applications (IMAA)", draft-hoffman-imaa-03
(work in progress), October 2003.
[RFC0954] Harrenstien, K., Stahl, M. and E. Feinler, "NICNAME/
WHOIS", RFC 954, October 1985.
[RFC1288] Zimmerman, D., "The Finger User Information Protocol", RFC
Klensin Expires January 10, 2005 [Page 8]
Internet-Draft A Name Munging Protocol July 2004
1288, December 1991.
[RFC1341] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet
Mail Extensions): Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1341, June
1992.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P. and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003.
Author's Address
John C Klensin
1770 Massachusetts Ave, #322
Cambridge, MA 02140
USA
Phone: +1 617 491 5735
EMail: john-ietf@jck.com
Klensin Expires January 10, 2005 [Page 9]
Internet-Draft A Name Munging Protocol July 2004
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 (2004). 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.
Klensin Expires January 10, 2005 [Page 10]