Stringprep Revision Problem Statement
draft-blanchet-precis-problem-statement-00.txt

Abstract

Using Unicode codepoints in protocol strings requires preparation of the string. Internationalized Domain Names(idn) initial work defined and used Stringprep and Nameprep. Other protocols have defined Stringprep profiles. A new approach different from Stringprep/Nameprep is used for a revision of IDN. The Stringprep profiles need to be updated or a replacement of Stringprep need to be designed. This document summarizes the findings of the current usage of Stringprep and identifies directions for a new Stringprep replacement protocol.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on January 6, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Introduction
2.  Usage and Issues of Stringprep
3.  Considerations for Stringprep replacement
4.  Security Considerations
5.  IANA Considerations
6.  Discussion home for this draft
7.  Informative References
§  Author's Address

1.  Introduction

As part of the Internationalized Domain Names(idn) initial work [RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.)[RFC3491] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.)[RFC3492] (Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” March 2003.), the Unicode-based strings needed to be prepared and normalized to enable their use in the DNS with exact match mechanism. The method, called Nameprep [RFC3491] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.), is specific to idn, but is generalized as Stringprep [RFC3454] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.), to help other protocols with similar needs, but with different constraints than idn.

Strinprep defines a framework where protocols defines their Stringprep profiles. Known IETF specifications using Strinprep are:

• The Nameprep profile[RFC3490] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) for use in Internationalized Domain Names (IDNs)
• The iSCSI profile [RFC3722] (Bakke, M., “String Profile for Internet Small Computer Systems Interface (iSCSI) Names,” April 2004.) for use in Internet Small Computer Systems Interface (iSCSI) Names
• The Nodeprep and Resourceprep profiles [RFC3920] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) for use in the Extensible Messaging and Presence Protocol (XMPP)
• The Policy MIB profile [RFC4011] (Waldbusser, S., Saperia, J., and T. Hongal, “Policy Based Management MIB,” March 2005.) for use in the Simple Network Management Protocol (SNMP)
• The SASLprep profile [RFC4013] (Zeilenga, K., “SASLprep: Stringprep Profile for User Names and Passwords,” February 2005.) for use in the Simple Authentication and Security Layer (SASL)
• The trace profile [RFC4505] (Zeilenga, K., “Anonymous Simple Authentication and Security Layer (SASL) Mechanism,” June 2006.) for use with the SASL ANONYMOUS mechanism
• The LDAP profile [RFC4518] (Zeilenga, K., “Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation,” June 2006.) for use with LDAP

Based on findings [RFC4690] (Klensin, J., Faltstrom, P., Karp, C., and IAB, “Review and Recommendations for Internationalized Domain Names (IDNs),” September 2006.) on early deployments of idn, IDNs specifications have been updated /* note to add ref to idnabis RFCs*/ and do not use stringprep/nameprep anymore. Instead, an algorithm based on Unicode properties of codepoints is defined. That algorithm generates a stable and complete table of the supported Unicode codepoints. This algorithm is based on an inclusion-based approach, instead of the exclusion-based approach of Stringprep/Nameprep.

This document lists the shortcomings and issues found by protocols listed above that defined Stringprep profiles. It also lists some early conclusions and requirements for a potential replacement of Stringprep.

2.  Usage and Issues of Stringprep

During IETF 77, a BOF discussed the current state of the protocols that have defined Stringprep profiles. The main conclusions are /* ref meeting notes */:

• Stringprep is bound to a specific version of Unicode: 3.2. Stringprep has not been updated to new versions of Unicode. Therefore, the protocols using Stringprep are stuck to Unicode 3.2.
• The protocols need to be updated to support new versions of Unicode. The protocols would like to not be bound to a specific version of Unicode, but rather have better Unicode agility as IDNAbis.
• The protocols require better bidirectional support (bidi) than currently offered by Stringprep.
• If the protocols are updated to use a new version of Stringprep or another framework, then backward compatibility is an important requirement. For example, Stringprep uses NFKC[UAX15], while IDNAbis uses NFC[UAX15].
• protocols are using each other, for example, a protocol can use user identifiers that are later passed to SASL, LDAP or another authentication mechanism. Therefore, common set of rules or classes of strings are preferred over specific rules for each protocol.

Stringprep profiles protocols use strings for different purposes:

• XMPP uses a different Stringprep profiles for each part of the XMPP address (JID): a localpart which is similar to a username and used for authentication, a domainpart which is a domain name and a resource part which is less restrictive than the localpart.
• iSCSI uses a Stringprep profile for the IQN which is essentially a domain name.
• SASL and LDAP uses a Stringprep profile for usernames.
• LDAP uses a set of Stringprep profiles.

During the newprep BOF, it was the concensus of the attendees that the Stringprep profiles protocols would highly prefer to have a replacement of Stringprep, with similar characteristics as the IDNA2008. That replacement should be defined so that the protocols would not have to "deal" with i18n strings in too much details since i18n expertise is not available in the respective protocols or working groups.

3.  Considerations for Stringprep replacement

From the findings about, the following directions are proposed:

• A stringprep replacement should be defined.
• The replacement should take an approach similar to IDNA2008, enabling Unicode agility.
• Protocols share similar characteristics of strings. Therefore, defining i18n preparation algorithms for a small set of string classes may be sufficient for most cases and provides the coherence among a set of protocol friends.

4.  Security Considerations

TBD

5.  IANA Considerations

This document has no actions for IANA.

6.  Discussion home for this draft

This document is intended to define the problem space discussed in the precis@ietf.org mailing list.

7. Informative References

Author's Address