< draft-ietf-precis-saslprepbis-07.txt		draft-ietf-precis-saslprepbis-08.txt >
	PRECIS P. Saint-Andre		PRECIS P. Saint-Andre
	Internet-Draft &yet		Internet-Draft &yet
	Obsoletes: 4013 (if approved) A. Melnikov		Obsoletes: 4013 (if approved) A. Melnikov
	Intended status: Standards Track Isode Ltd		Intended status: Standards Track Isode Ltd
	Expires: September 25, 2014 March 24, 2014		Expires: April 13, 2015 October 10, 2014
	Preparation and Comparison of Internationalized Strings Representing		Preparation and Comparison of Internationalized Strings Representing
	Usernames and Passwords		Usernames and Passwords
	draft-ietf-precis-saslprepbis-07		draft-ietf-precis-saslprepbis-08
	Abstract		Abstract
	This document describes methods for handling Unicode strings		This document describes methods for handling Unicode strings
	representing usernames and passwords. This document obsoletes RFC		representing usernames and passwords. This document obsoletes RFC
	4013.		4013.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 25, 2014.		This Internet-Draft will expire on April 13, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. What the Username and Password Profiles Provide . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Preparation, Comparison, and Enforcement . . . . . . . . . . 4
	4. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 4		4. Usernames . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 4		4.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 5
	4.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 5		4.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2.1. Case Mapping . . . . . . . . . . . . . . . . . . . . 6		4.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 6
	4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7		4.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 6
			4.5. Case Mapping . . . . . . . . . . . . . . . . . . . . . . 7
			4.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 9		5. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Preparation . . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10		5.3. Enforcement . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.4. Comparison . . . . . . . . . . . . . . . . . . . . . . . 11
	6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 11		5.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Migration . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		6.1. Usernames . . . . . . . . . . . . . . . . . . . . . . . . 12
	7.1. UsernameIdentifierClass . . . . . . . . . . . . . . . . . 13		6.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2. PasswordFreeformClass . . . . . . . . . . . . . . . . . . 14		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7.1. UsernameIdentifierClass . . . . . . . . . . . . . . . . . 14
	8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 15		7.2. PasswordFreeformClass . . . . . . . . . . . . . . . . . . 15
	8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 15		8.1. Password/Passphrase Strength . . . . . . . . . . . . . . 16
	8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 15		8.2. Identifier Comparison . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		8.3. Reuse of PRECIS . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		8.4. Reuse of Unicode . . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . 16
	Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 18		9.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Differences from RFC 4013 . . . . . . . . . . . . . 18
			Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	Usernames and passwords are widely used for authentication and		Usernames and passwords are widely used for authentication and
	authorization on the Internet, either directly when provided in		authorization on the Internet, either directly when provided in
	plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic		plaintext (as in the SASL PLAIN mechanism [RFC4616] or the HTTP Basic
	scheme [RFC2617]) or indirectly when provided as the input to a		scheme [RFC2617]) or indirectly when provided as the input to a
	cryptographic algorithm such as a hash function (as in the SASL SCRAM		cryptographic algorithm such as a hash function (as in the SASL SCRAM
	mechanism [RFC5802] or the HTTP Digest scheme [RFC2617]). To		mechanism [RFC5802] or the HTTP Digest scheme [RFC2617]).
	increase the likelihood that the input and comparison of usernames
			To increase the likelihood that the input and comparison of usernames
	and passwords will work in ways that make sense for typical users		and passwords will work in ways that make sense for typical users
	throughout the world, this document defines rules for preparing and		throughout the world, this document defines rules for preparing and
	comparing internationalized strings that represent usernames and		comparing internationalized strings that represent usernames and
	passwords.		passwords. Such strings consist of characters from the Unicode
			character set [UNICODE], especially characters outside the ASCII
	The methods specified in this document define two PRECIS profiles as		range [RFC20]. The rules for handling such strings are specified
	explained in the PRECIS framework specification		through profiles of the string classes defined in the PRECIS
			framework specification [I-D.ietf-precis-framework].
	[I-D.ietf-precis-framework]. This document assumes that all strings
	are comprised of characters from the Unicode character set [UNICODE],
	with special attention to characters outside the ASCII range [RFC20].
	The methods defined here might be applicable wherever usernames or
	passwords are used. However, the methods are not intended for use in
	preparing strings that are not usernames (e.g., email addresses and
	LDAP distinguished names), nor in cases where identifiers or secrets
	are not strings (e.g., keys and certificates) or require specialized
	handling.
	This document obsoletes RFC 4013 (the "SASLprep" profile of
	stringprep [RFC3454]) but can be used by technologies other than the
	Simple Authentication and Security Layer (SASL) [RFC4422], such as
	HTTP authentication [RFC2617].
	2. What the Username and Password Profiles Provide
	Profiles of the PRECIS framework enable software to handle Unicode		Profiles of the PRECIS framework enable software to handle Unicode
	characters outside the ASCII range in an automated way, so that such		characters outside the ASCII range in an automated way, so that such
	characters are treated carefully and consistently in application		characters are treated carefully and consistently in application
	protocols. In large measure, these profiles are designed to protect		protocols. In large measure, these profiles are designed to protect
	application developers from the potentially negative consequences of		application developers from the potentially negative consequences of
	supporting the full range of Unicode characters. For instance, in		supporting the full range of Unicode characters. For instance, in
	almost all application protocols it would be dangerous to treat the		almost all application protocols it would be dangerous to treat the
	Unicode character SUPERSCRIPT ONE (U+0089) as equivalent to DIGIT ONE		Unicode character SUPERSCRIPT ONE (U+0089) as equivalent to DIGIT ONE
	(U+0031), since that would result in false positives during		(U+0031), since that would result in false positives during
	comparison, authentication, and authorization (e.g., an attacker		comparison, authentication, and authorization (e.g., an attacker
	could easy spoof an account "user1@example.com").		could easy spoof an account "user1@example.com").
	Whereas a naive use of Unicode would make such attacks trivially		Whereas a naive use of Unicode would make such attacks trivially
	easy, the Username PRECIS profile defined in this document generally		easy, the PRECIS profile defined here for usernames generally
	protects applications from inadvertently causing such problems.		protects applications from inadvertently causing such problems.
	(Similar considerations apply to passwords, although here it is		(Similar considerations apply to passwords, although here it is
	desirable to support a wider range of characters so as to maximize		desirable to support a wider range of characters so as to maximize
	entropy during authentication.)		entropy during authentication.)
	3. Terminology		The methods defined here might be applicable wherever usernames or
			passwords are used. However, the methods are not intended for use in
			preparing strings that are not usernames (e.g., email addresses and
			LDAP distinguished names), nor in cases where identifiers or secrets
			are not strings (e.g., keys and certificates) or require specialized
			handling.
			This document obsoletes RFC 4013 (the "SASLprep" profile of
			stringprep [RFC3454]) but can be used by technologies other than the
			Simple Authentication and Security Layer (SASL) [RFC4422], such as
			HTTP authentication [RFC2617].
			2. Terminology
	Many important terms used in this document are defined in		Many important terms used in this document are defined in
	[I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [UNICODE].		[I-D.ietf-precis-framework], [RFC5890], [RFC6365], and [UNICODE].
	The term "non-ASCII space" refers to any Unicode code point having a		The term "non-ASCII space" refers to any Unicode code point having a
	general category of "Zs", with the exception of U+0020 (here called		general category of "Zs", with the exception of U+0020 (here called
	"ASCII space").		"ASCII space").
	As used here, the term "password" is not literally limited to a word;		As used here, the term "password" is not literally limited to a word;
	i.e., a password could be a passphrase consisting of more than one		i.e., a password could be a passphrase consisting of more than one
	word, perhaps separated by spaces or other such characters.		word, perhaps separated by spaces or other such characters.
	skipping to change at page 4, line 22 ¶		skipping to change at page 4, line 26 ¶
	username in any particular SASL mechanism or application technology		username in any particular SASL mechanism or application technology
	is a matter for implementation and deployment, and that a username		is a matter for implementation and deployment, and that a username
	does not necessarily map to any particular application identifier		does not necessarily map to any particular application identifier
	(such as the localpart of an email address).		(such as the localpart of an email address).
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
			3. Preparation, Comparison, and Enforcement
			This document distinguishes between three different actions that an
			entity can take in handling a username or password:
			o Enforcement entails applying all of the rules specified for a
			particular profile (UsernameIdentifierClass or
			PasswordFreeformClass) to an individual string.
			o Comparison entails applying all of the rules specified for a
			particular profile to two separate strings, for the purpose of
			determining if the two strings are equivalent.
			o Preparation entails only ensuring that the characters in an
			individual string are allowed by the underlying PRECIS base class
			(IdentifierClass or FreeformClass).
			In most cases, "servers" are responsible for enforcement and
			"clients" are responsible only for preparation. Although some
			information regarding these responsibilities (e.g., the protocol
			slots in which usernames or passwords can be placed) needs to be
			provided in specifications that use the profiles defined in this
			document, the general outlines of such responsibilities are explained
			in the following sections.
	4. Usernames		4. Usernames
	4.1. Definition		4.1. Definition
	This document specifies that a username is a string of Unicode code		This document specifies that a username is a string of Unicode code
	points [UNICODE], encoded using UTF-8 [RFC3629], and structured		points [UNICODE], encoded using UTF-8 [RFC3629], and structured
	either as an ordered sequence of "userparts" (where the complete		either as an ordered sequence of "userparts" (where the complete
	username can consist of a single userpart or a space-separated		username can consist of a single userpart or a space-separated
	sequence of userparts) or as a userpart@domainpart (where the		sequence of userparts) or as a userpart@domainpart (where the
	domainpart is an IP literal, an IPv4 address, or a fully-qualified		domainpart is an IP literal, an IPv4 address, or a fully-qualified
	skipping to change at page 5, line 43 ¶		skipping to change at page 6, line 9 ¶
	constructions such as "user@example.com" are allowed as usernames		constructions such as "user@example.com" are allowed as usernames
	under this specification, as they were under [RFC4013].		under this specification, as they were under [RFC4013].
	Implementation Note: The username construct defined in this		Implementation Note: The username construct defined in this
	document does not necessarily match what all deployed applications		document does not necessarily match what all deployed applications
	might refer to as a "username" or "userid", but instead provides a		might refer to as a "username" or "userid", but instead provides a
	relatively safe subset of Unicode characters that can be used in		relatively safe subset of Unicode characters that can be used in
	existing SASL mechanisms and SASL-using application protocols, and		existing SASL mechanisms and SASL-using application protocols, and
	even in most application protocols that do not currently use SASL.		even in most application protocols that do not currently use SASL.
			A username MUST NOT be zero bytes in length. This rule is to be
			enforced after any normalization and mapping of code points.
			In protocols that provide usernames as input to a cryptographic
			algorithm such as a hash function, the client will need to perform
			proper preparation of the username before applying the algorithm.
	4.2. Preparation		4.2. Preparation
	Each userpart of a username MUST conform to the		An entity that prepares a string for inclusion in a username slot
	"UsernameIdentifierClass" profile of the PRECIS IdentifierClass,		MUST ensure that the string consists only of Unicode code points that
	which is defined as follows:		conform to the "IdentifierClass" base string class defined in
			[I-D.ietf-precis-framework]. In addition, the string MUST be encoded
			as UTF-8 [RFC3629].
	1. The base string class is the "IdentifierClass" specified in		4.3. Enforcement
	[I-D.ietf-precis-framework].
	2. Fullwidth and halfwidth characters MUST be mapped to their		An entity that performs enforcement in username slots MUST prepare a
	decomposition mappings.		string as described in the previous section and MUST also apply the
			rules specified below for the UsernameIdentifierClass profile (these
			rules MUST be applied in the order shown).
	3. So-called additional mappings MAY be applied, such as mapping of		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST be
	delimiters (e.g., characters such as '@', ':', '/', '+', and '-')		mapped to their decomposition mappings.
	and special handling of certain characters or classes of
	characters (e.g., mapping of non-ASCII spaces to ASCII space or
	mapping of control characters to nothing); the PRECIS mappings
	document [I-D.ietf-precis-mappings] describes such mappings in
	more detail.
	4. Depending on the SASL mechanism, SASL-using application protocol,		2. Additional Mapping Rule: There is no additional mapping rule.
	or non-SASL-using application protocol in question, uppercase and
	titlecase characters might or might not be mapped to their
	lowercase equivalents (see Section 4.2.1 below).
	5. Unicode Normalization Form C (NFC) MUST be applied to all		3. Case Mapping Rule: There is no case mapping rule (although see
	characters.		Section 4.5 below).
	With regard to directionality, the "Bidi Rule" provided in [RFC5893]		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applies.		applied to all characters.
	A username MUST NOT be zero bytes in length. This rule is to be		5. Exclusion Rule: There is no exclusion rule.
	enforced after any normalization and mapping of code points.
	In protocols that provide usernames as input to a cryptographic		6. Directionality Rule: The "Bidi Rule" provided in [RFC5893]
	algorithm such as a hash function, the client will need to perform		applies.
	proper preparation of the username before applying the algorithm.
	4.2.1. Case Mapping		4.4. Comparison
			An entity that performs comparison of two strings before or after
			their inclusion in username slots MUST prepare each string and
			enforce the rules specified in the previous two sections. The two
			strings are to be considered equivalent if they are an exact octet-
			for-octet match (sometimes called "bit-string identity").
			4.5. Case Mapping
	Case mapping is a matter for the application protocol, protocol		Case mapping is a matter for the application protocol, protocol
	implementation, or end deployment. In general, this document		implementation, or end deployment. In general, this document
	suggests that it is preferable to perform case mapping, since not		suggests that it is preferable to perform case mapping, since not
	doing so can lead to false positives during authentication and		doing so can lead to false positives during authentication and
	authorization (as described in [RFC6943]) and can result in confusion		authorization (as described in [RFC6943]) and can result in confusion
	among end users given the prevalence of case mapping in many existing		among end users given the prevalence of case mapping in many existing
	protocols and applications. However, there can be good reasons to		protocols and applications. However, there can be good reasons to
	not perform case mapping, such as backward compatibility with		not perform case mapping, such as backward compatibility with
	deployed infrastructure.		deployed infrastructure.
	skipping to change at page 7, line 38 ¶		skipping to change at page 8, line 12 ¶
	decisions about case mapping can be a matter of deployment		decisions about case mapping can be a matter of deployment
	policy).		policy).
	If the specification for a SASL mechanism, SASL application protocol,		If the specification for a SASL mechanism, SASL application protocol,
	or non-SASL application protocol specifies the handling of case		or non-SASL application protocol specifies the handling of case
	mapping for strings that conform to the UsernameIdentifierClass, it		mapping for strings that conform to the UsernameIdentifierClass, it
	MUST clearly describe whether case mapping is required, recommended,		MUST clearly describe whether case mapping is required, recommended,
	or optional at the level of the protocol itself, implementations		or optional at the level of the protocol itself, implementations
	thereof, or service deployments.		thereof, or service deployments.
	4.3. Examples		4.6. Examples
	The following examples illustrate a small number of usernames that		The following examples illustrate a small number of usernames that
	are consistent with the format defined above (note that the		are consistent with the format defined above (note that the
	characters < and > are used here to delineate the actual usernames		characters < and > are used here to delineate the actual usernames
	and are not part of the username strings).		and are not part of the username strings).
	Table 1: A sample of legal usernames		Table 1: A sample of legal usernames
	+---------------------------------+---------------------------------+		+---------------------------------+---------------------------------+
	| # | Username | Notes |		| # | Username | Notes |
	skipping to change at page 10, line 7 ¶		skipping to change at page 10, line 17 ¶
	; a "freepoint" is a UTF-8 encoded		; a "freepoint" is a UTF-8 encoded
	; Unicode code point that conforms to		; Unicode code point that conforms to
	; the PRECIS "FreeformClass"		; the PRECIS "FreeformClass"
	;		;
	All code points and blocks not explicitly allowed in the PRECIS		All code points and blocks not explicitly allowed in the PRECIS
	FreeformClass are disallowed; this includes private use characters,		FreeformClass are disallowed; this includes private use characters,
	surrogate code points, and the other code points and blocks defined		surrogate code points, and the other code points and blocks defined
	as "Prohibited Output" in Section 2.3 of RFC 4013.		as "Prohibited Output" in Section 2.3 of RFC 4013.
			A password MUST NOT be zero bytes in length. This rule is to be
			enforced after any normalization and mapping of code points.
			In protocols that provide passwords as input to a cryptographic
			algorithm such as a hash function, the client will need to perform
			proper preparation of the password before applying the algorithm,
			since the password is not available to the server in plaintext form.
	5.2. Preparation		5.2. Preparation
	A password MUST conform to the "PasswordFreeformClass" profile of the		An entity that prepares a string for inclusion in a password slot
	PRECIS FreeformClass, which is defined as follows:		MUST ensure that the string consists only of Unicode code points that
			conform to the "FreeformClass" base string class defined in
			[I-D.ietf-precis-framework]. In addition, the string MUST be encoded
			as UTF-8 [RFC3629].
	1. The base string class is the "FreeformClass" specified in		5.3. Enforcement
	[I-D.ietf-precis-framework].
	2. Fullwidth and halfwidth characters MUST NOT be mapped to their		An entity that performs enforcement in password slots MUST prepare a
	decomposition mappings.		string as described in the previous section and MUST also apply the
			rules specified below for the PasswordFreeformClass (these rules MUST
			be applied in the order shown).
	3. Any instances of non-ASCII space MUST be mapped to ASCII space		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST NOT
	(U+0020).		be mapped to their decomposition mappings.
	4. Uppercase and titlecase characters MUST NOT be mapped to their		2. Additional Mapping Rule: Any instances of non-ASCII space MUST be
	lowercase equivalents.		mapped to ASCII space (U+0020); such an instance is any Unicode
			code point that has a compatibility mapping of any kind to U+0020
			SPACE (including but not limited to <compat> as for U+0384 GREEK
			TONOS, <noBreak> as for U+2007 FIGURE SPACE, and <wide> as for
			U+3000 IDEOGRAPHIC SPACE).
	5. Unicode Normalization Form C (NFC) MUST be applied to all		3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be
	characters.		mapped to their lowercase equivalents.
			4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
			applied to all characters.
			5. Exclusion Rule: There is no exclusion rule.
			6. Directionality Rule: There is no directionality rule.
	With regard to directionality, the "Bidi Rule" (defined in [RFC5893])		With regard to directionality, the "Bidi Rule" (defined in [RFC5893])
	and similar rules are unnecessary and inapplicable to passwords,		and similar rules are unnecessary and inapplicable to passwords,
	since they can reduce the range of characters that are allowed in a		since they can reduce the range of characters that are allowed in a
	string and therefore reduce the amount of entropy that is possible in		string and therefore reduce the amount of entropy that is possible in
	a password. Furthermore, such rules are intended to minimize the		a password. Furthermore, such rules are intended to minimize the
	possibility that the same string will be displayed differently on a		possibility that the same string will be displayed differently on a
	system set for right-to-left display and a system set for left-to-		system set for right-to-left display and a system set for left-to-
	right display; however, passwords are typically not displayed at all		right display; however, passwords are typically not displayed at all
	and are rarely meant to be interoperable across different systems in		and are rarely meant to be interoperable across different systems in
	the way that non-secret strings like domain names and usernames are.		the way that non-secret strings like domain names and usernames are.
	A password MUST NOT be zero bytes in length. This rule is to be		5.4. Comparison
	enforced after any normalization and mapping of code points.
	In protocols that provide passwords as input to a cryptographic		An entity that performs comparison of two strings before or after
	algorithm such as a hash function, the client will need to perform		their inclusion in password slots MUST prepare each string and
	proper preparation of the password before applying the algorithm,		enforce the rules specified in the previous two sections. The two
	since the password is not available to the server in plaintext form.		strings are to be considered equivalent if they are an exact octet-
			for-octet match (sometimes called "bit-string identity").
	5.3. Examples		5.5. Examples
	The following examples illustrate a small number of passwords that		The following examples illustrate a small number of passwords that
	are consistent with the format defined above (note that the		are consistent with the format defined above (note that the
	characters < and > are used here to delineate the actual passwords		characters < and > are used here to delineate the actual passwords
	and are not part of the username strings).		and are not part of the username strings).
	Table 3: A sample of legal passwords		Table 3: A sample of legal passwords
	+------------------------------------+------------------------------+		+------------------------------------+------------------------------+
	| # | Password | Notes |		| # | Password | Notes |
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 51 ¶
	7.1. UsernameIdentifierClass		7.1. UsernameIdentifierClass
	Name: UsernameIdentifierClass.		Name: UsernameIdentifierClass.
	Applicability: Usernames in security and application protocols.		Applicability: Usernames in security and application protocols.
	Base Class: IdentifierClass.		Base Class: IdentifierClass.
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
	Width Mapping: Map fullwidth and halfwidth characters to their		Width Mapping Rule: Map fullwidth and halfwidth characters to their
	decomposition mappings.		decomposition mappings.
	Additional Mappings: None required or recommended.		Additional Mapping Rule: None.
	Case Mapping: To be defined by security or application protocols		Case Mapping Rule: To be defined by security or application
	that use this profile.		protocols that use this profile.
	Normalization: NFC.		Normalization Rule: NFC.
	Directionality: The "Bidi Rule" defined in RFC 5893 applies.		Exclusion Rule: None.
	Exclusions: None.		Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.
	Enforcement: To be defined by security or application protocols that		Enforcement: To be defined by security or application protocols that
	use this profile.		use this profile.
	Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to		Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
	the number issued for this specification.]		the number issued for this specification.]
	7.2. PasswordFreeformClass		7.2. PasswordFreeformClass
	Name: PasswordFreeformClass.		Name: PasswordFreeformClass.
	Applicability: Passwords in security and application protocols.		Applicability: Passwords in security and application protocols.
	Base Class: FreeformClass		Base Class: FreeformClass
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
	Width Mapping: None.		Width Mapping Rule: None.
	Additional Mappings: Map non-ASCII space characters to ASCII space.		Additional Mapping Rule: Map non-ASCII space characters to ASCII
			space.
	Case Mapping: None.		Case Mapping Rule: None.
	Normalization: NFC.		Normalization Rule: NFC.
	Directionality: None.		Exclusion Rule: None.
	Exclusions: None.		Directionality Rule: None.
	Enforcement: To be defined by security or application protocols that		Enforcement: To be defined by security or application protocols that
	use this profile.		use this profile.
	Specification: RFC XXXX.		Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
			the number issued for this specification.]
	8. Security Considerations		8. Security Considerations
	8.1. Password/Passphrase Strength		8.1. Password/Passphrase Strength
	The ability to include a wide range of characters in passwords and		The ability to include a wide range of characters in passwords and
	passphrases can increase the potential for creating a strong password		passphrases can increase the potential for creating a strong password
	with high entropy. However, in practice, the ability to include such		with high entropy. However, in practice, the ability to include such
	characters ought to be weighed against the possible need to reproduce		characters ought to be weighed against the possible need to reproduce
	them on various devices using various input methods.		them on various devices using various input methods.
	skipping to change at page 15, line 42 ¶		skipping to change at page 16, line 42 ¶
	The security considerations described in [UTS39] apply to the use of		The security considerations described in [UTS39] apply to the use of
	Unicode characters in usernames and passwords.		Unicode characters in usernames and passwords.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-precis-framework]		[I-D.ietf-precis-framework]
	Saint-Andre, P. and M. Blanchet, "Precis Framework:		Saint-Andre, P. and M. Blanchet, "Precis Framework:
	Handling Internationalized Strings in Protocols", draft-		Handling Internationalized Strings in Protocols", draft-
	ietf-precis-framework-15 (work in progress), March 2014.		ietf-precis-framework-18 (work in progress), September
			2014.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO		[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
	10646", STD 63, RFC 3629, November 2003.		10646", STD 63, RFC 3629, November 2003.
	[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[UNICODE] The Unicode Consortium, "The Unicode Standard, Version		[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
	6.1", 2012,		6.3", 2013,
	<http://www.unicode.org/versions/Unicode6.1.0/>.		<http://www.unicode.org/versions/Unicode6.3.0/>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-precis-mappings]
	Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS
	classes", draft-ietf-precis-mappings-07 (work in
	progress), February 2014.
	[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,		[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
	October 1969.		October 1969.
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of		[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
	Internationalized Strings ("stringprep")", RFC 3454,		Internationalized Strings ("stringprep")", RFC 3454,
	skipping to change at page 17, line 51 ¶		skipping to change at page 18, line 47 ¶
	The following substantive modifications were made from RFC 4013.		The following substantive modifications were made from RFC 4013.
	o A single SASLprep algorithm was replaced by two separate		o A single SASLprep algorithm was replaced by two separate
	algorithms: one for usernames and another for passwords.		algorithms: one for usernames and another for passwords.
	o The new preparation algorithms use PRECIS instead of a stringprep		o The new preparation algorithms use PRECIS instead of a stringprep
	profile. The new algorithms work independenctly of Unicode		profile. The new algorithms work independenctly of Unicode
	versions.		versions.
	o As recommended in the PRECIS framwork, changed the Unicode		o As recommended in the PRECIS framwork, changed the Unicode
	normalization form to NFC (from NFKC).		normalization form from NFKC to NFC.
	o Some Unicode code points that were mapped to nothing in RFC 4013		o Some Unicode code points that were mapped to nothing in RFC 4013
	are simply disallowed by PRECIS.		are simply disallowed by PRECIS.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	The following individuals provided helpful feedback on this document:		The following individuals provided helpful feedback on this document:
	Marc Blanchet, Alan DeKok, Joe Hildebrand, Jeffrey Hutzelman, Simon		Marc Blanchet, Alan DeKok, Joe Hildebrand, Jeffrey Hutzelman, Simon
	Josefsson, Jonathan Lennox, Matt Miller, Chris Newman, Yutaka OIWA,		Josefsson, Jonathan Lennox, Matt Miller, Chris Newman, Yutaka OIWA,
	Pete Resnick, Andrew Sullivan, and Nico Williams (Nico in particular		Pete Resnick, Andrew Sullivan, and Nico Williams. Nico in particular
	provided text that was used in Section 4.2.1). Thanks also to		deserves special recognition for providing text that was used in
	Yoshiro YONEYA and Takahiro NEMOTO for implementation feedback.		Section 4.5. Thanks also to Yoshiro YONEYA and Takahiro NEMOTO for
			implementation feedback.
	This document borrows some text from [RFC4013] and [RFC6120].		This document borrows some text from [RFC4013] and [RFC6120].
	Authors' Addresses		Authors' Addresses
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
	P.O. Box 787
	Parker, CO 80134
	USA
	Email: ietf@stpeter.im		Email: peter@andyet.com
			URI: https://andyet.com/
	Alexey Melnikov		Alexey Melnikov
	Isode Ltd		Isode Ltd
	5 Castle Business Village		5 Castle Business Village
	36 Station Road		36 Station Road
	Hampton, Middlesex TW12 2BX		Hampton, Middlesex TW12 2BX
	UK		UK
	Email: Alexey.Melnikov@isode.com		Email: Alexey.Melnikov@isode.com
End of changes. 52 change blocks.
	131 lines changed or deleted		185 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/