< draft-ietf-precis-saslprepbis-16.txt		draft-ietf-precis-saslprepbis-17.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: October 30, 2015 April 28, 2015		Expires: November 16, 2015 May 15, 2015
	Preparation, Enforcement, and Comparison of Internationalized Strings		Preparation, Enforcement, and Comparison of Internationalized Strings
	Representing Usernames and Passwords		Representing Usernames and Passwords
	draft-ietf-precis-saslprepbis-16		draft-ietf-precis-saslprepbis-17
	Abstract		Abstract
	This document describes updated methods for handling Unicode strings		This document describes updated methods for handling Unicode strings
	representing usernames and passwords. The previous approach was		representing usernames and passwords. The previous approach was
	known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).		known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).
	The methods specified in this document provide a more sustainable		The methods specified in this document provide a more sustainable
	approach to the handling of internationalized usernames and		approach to the handling of internationalized usernames and
	passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and		passwords. The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and
	this document obsoletes RFC 4013.		this document obsoletes RFC 4013.
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 October 30, 2015.		This Internet-Draft will expire on November 16, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 5, line 34 ¶		skipping to change at page 5, line 34 ¶
	; UTF-8 encoded Unicode code point that can be		; UTF-8 encoded Unicode code point that can be
	; contained in a string that conforms to the		; contained in a string that conforms to the
	; PRECIS "IdentifierClass"		; PRECIS "IdentifierClass"
	;		;
	All code points and blocks not explicitly allowed in the PRECIS		All code points and blocks not explicitly allowed in the PRECIS
	IdentifierClass are disallowed; this includes private use characters,		IdentifierClass are disallowed; this includes private use characters,
	surrogate code points, and the other code points and blocks that were		surrogate code points, and the other code points and blocks that were
	defined as "Prohibited Output" in [RFC4013]. In addition, common		defined as "Prohibited Output" in [RFC4013]. In addition, common
	constructions such as "user@example.com" (e.g., the Network Access		constructions such as "user@example.com" (e.g., the Network Access
	Identifier from [I-D.ietf-radext-nai]) are allowed as usernames under		Identifier from [RFC7542]) are allowed as usernames under this
	this specification, as they were under [RFC4013].		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		A username MUST NOT be zero bytes in length. This rule is to be
	enforced after any normalization and mapping of code points.		enforced after any normalization and mapping of code points.
	skipping to change at page 6, line 33 ¶		skipping to change at page 6, line 33 ¶
	as UTF-8 [RFC3629].		as UTF-8 [RFC3629].
	3.2.2. Enforcement		3.2.2. Enforcement
	An entity that performs enforcement according to this profile MUST		An entity that performs enforcement according to this profile MUST
	prepare a string as described in the previous section and MUST also		prepare a string as described in the previous section and MUST also
	apply the rules specified below for the UsernameCaseMapped profile		apply the rules specified below for the UsernameCaseMapped profile
	(these rules MUST be applied in the order shown).		(these rules MUST be applied in the order shown).
	1. Width Mapping Rule: Fullwidth and halfwidth characters MUST be		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST be
	mapped to their decomposition mappings.		mapped to their decomposition mappings (see Unicode Standard
			Annex #11 [UAX11]).
	2. Additional Mapping Rule: There is no additional mapping rule.		2. Additional Mapping Rule: There is no additional mapping rule.
	3. Case Mapping Rule: Uppercase and titlecase characters MUST be		3. Case Mapping Rule: Uppercase and titlecase characters MUST be
	mapped to their lowercase equivalents, preferably using Unicode		mapped to their lowercase equivalents, preferably using Unicode
	Default Case Folding as defined in the Unicode Standard [Unicode]		Default Case Folding as defined in the Unicode Standard [Unicode]
	(at the time of this writing, the algorithm is specified in		(at the time of this writing, the algorithm is specified in
	Chapter 3 of [Unicode7.0]).		Chapter 3 of [Unicode7.0]); see further discussion in
			Section 3.4.
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applied to all characters.		applied to all characters.
	5. Directionality Rule: Applications MUST apply the "Bidi Rule"		5. Directionality Rule: Applications MUST apply the "Bidi Rule"
	defined in [RFC5893] to strings that contain right-to-left		defined in [RFC5893] to strings that contain right-to-left
	characters (i.e., each of the six conditions of the Bidi Rule		characters (i.e., each of the six conditions of the Bidi Rule
	must be satisfied).		must be satisfied).
	3.2.3. Comparison		3.2.3. Comparison
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	as UTF-8 [RFC3629].		as UTF-8 [RFC3629].
	3.3.2. Enforcement		3.3.2. Enforcement
	An entity that performs enforcement according to this profile MUST		An entity that performs enforcement according to this profile MUST
	prepare a string as described in the previous section and MUST also		prepare a string as described in the previous section and MUST also
	apply the rules specified below for the UsernameCasePreserved profile		apply the rules specified below for the UsernameCasePreserved profile
	(these rules MUST be applied in the order shown).		(these rules MUST be applied in the order shown).
	1. Width Mapping Rule: Fullwidth and halfwidth characters MUST be		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST be
	mapped to their decomposition mappings.		mapped to their decomposition mappings (see Unicode Standard
			Annex #11 [UAX11]).
	2. Additional Mapping Rule: There is no additional mapping rule.		2. Additional Mapping Rule: There is no additional mapping rule.
	3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be		3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be
	mapped to their lowercase equivalents.		mapped to their lowercase equivalents; see further discussion in
			Section 3.4.
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	applied to all characters.		applied to all characters.
	5. Directionality Rule: Applications MUST apply the "Bidi Rule"		5. Directionality Rule: Applications MUST apply the "Bidi Rule"
	defined in [RFC5893] to strings that contain right-to-left		defined in [RFC5893] to strings that contain right-to-left
	characters (i.e., each of the six conditions of the Bidi Rule		characters (i.e., each of the six conditions of the Bidi Rule
	must be satisfied).		must be satisfied).
	3.3.3. Comparison		3.3.3. Comparison
	skipping to change at page 12, line 43 ¶		skipping to change at page 12, line 43 ¶
	as UTF-8 [RFC3629].		as UTF-8 [RFC3629].
	4.2.2. Enforcement		4.2.2. Enforcement
	An entity that performs enforcement according to this profile MUST		An entity that performs enforcement according to this profile MUST
	prepare a string as described in the previous section and MUST also		prepare a string as described in the previous section and MUST also
	apply the rules specified below (these rules MUST be applied in the		apply the rules specified below (these rules MUST be applied in the
	order shown).		order shown).
	1. Width Mapping Rule: Fullwidth and halfwidth characters MUST NOT		1. Width Mapping Rule: Fullwidth and halfwidth characters MUST NOT
	be mapped to their decomposition mappings.		be mapped to their decomposition mappings (see Unicode Standard
			Annex #11 [UAX11]).
	2. Additional Mapping Rule: Any instances of non-ASCII space MUST be		2. Additional Mapping Rule: Any instances of non-ASCII space MUST be
	mapped to ASCII space (U+0020); a non-ASCII space is any Unicode		mapped to ASCII space (U+0020); a non-ASCII space is any Unicode
	code point having a general category of "Zs", naturally with the		code point having a general category of "Zs", naturally with the
	exception of U+0020.		exception of U+0020.
	3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be		3. Case Mapping Rule: Uppercase and titlecase characters MUST NOT be
	mapped to their lowercase equivalents.		mapped to their lowercase equivalents.
	4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be		4. Normalization Rule: Unicode Normalization Form C (NFC) MUST be
	skipping to change at page 18, line 12 ¶		skipping to change at page 18, line 12 ¶
	Case Mapping Rule: Map uppercase and titlecase characters to		Case Mapping Rule: Map uppercase and titlecase characters to
	lowercase.		lowercase.
	Normalization Rule: NFC.		Normalization Rule: NFC.
	Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.		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, Section 3.2. [Note to RFC Editor: please
	the number issued for this specification.]		change XXXX to the number issued for this specification.]
	7.2. UsernameCasePreserved Profile		7.2. UsernameCasePreserved Profile
	Name: UsernameCasePreserved.		Name: UsernameCasePreserved.
	Base Class: IdentifierClass.		Base Class: IdentifierClass.
	Applicability: Usernames in security and application protocols.		Applicability: Usernames in security and application protocols.
	Replaces: The SASLprep profile of Stringprep.		Replaces: The SASLprep profile of Stringprep.
	skipping to change at page 18, line 39 ¶		skipping to change at page 18, line 39 ¶
	Case Mapping Rule: None.		Case Mapping Rule: None.
	Normalization Rule: NFC.		Normalization Rule: NFC.
	Directionality Rule: The "Bidi Rule" defined in RFC 5893 applies.		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, Section 3.3. [Note to RFC Editor: please
	the number issued for this specification.]		change XXXX to the number issued for this specification.]
	7.3. OpaqueString Profile		7.3. OpaqueString Profile
	Name: OpaqueString.		Name: OpaqueString.
	Base Class: FreeformClass.		Base Class: FreeformClass.
	Applicability: Passwords and other opaque strings in security and		Applicability: Passwords and other opaque strings in security and
	application protocols.		application protocols.
	skipping to change at page 19, line 19 ¶		skipping to change at page 19, line 19 ¶
	Case Mapping Rule: None.		Case Mapping Rule: None.
	Normalization Rule: NFC.		Normalization Rule: NFC.
	Directionality Rule: 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. [Note to RFC Editor: please change XXXX to		Specification: RFC XXXX, Section 4.2. [Note to RFC Editor: please
	the number issued for this specification.]		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 20, line 32 ¶		skipping to change at page 20, line 32 ¶
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, August 2010.		RFC 5890, August 2010.
	[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in		[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
	Internationalization in the IETF", BCP 166, RFC 6365,		Internationalization in the IETF", BCP 166, RFC 6365,
	September 2011.		September 2011.
	[Unicode] The Unicode Consortium, "The Unicode Standard",		[UAX11] The Unicode Consortium, "Unicode Standard Annex #11: East
	2015-present, <http://www.unicode.org/versions/latest/>.		Asian Width", September 2012,
			<http://unicode.org/reports/tr11/>.
	[Unicode7.0]		[Unicode7.0]
	The Unicode Consortium, "The Unicode Standard, Version		The Unicode Consortium, "The Unicode Standard, Version
	7.0.0", 2014,		7.0.0", 2014,
	<http://www.unicode.org/versions/Unicode7.0.0/>.		<http://www.unicode.org/versions/Unicode7.0.0/>.
			[Unicode] The Unicode Consortium, "The Unicode Standard",
			2015-present, <http://www.unicode.org/versions/latest/>.
	9.2. Informative References		9.2. Informative References
	[I-D.ietf-httpauth-basicauth-update]		[I-D.ietf-httpauth-basicauth-update]
	Reschke, J., "The 'Basic' HTTP Authentication Scheme",		Reschke, J., "The 'Basic' HTTP Authentication Scheme",
	draft-ietf-httpauth-basicauth-update-07 (work in		draft-ietf-httpauth-basicauth-update-07 (work in
	progress), February 2015.		progress), February 2015.
	[I-D.ietf-httpauth-digest]		[I-D.ietf-httpauth-digest]
	Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest		Shekh-Yusef, R., Ahrens, D., and S. Bremer, "HTTP Digest
	Access Authentication", draft-ietf-httpauth-digest-19		Access Authentication", draft-ietf-httpauth-digest-19
	(work in progress), April 2015.		(work in progress), April 2015.
	[I-D.ietf-radext-nai]
	DeKok, A., "The Network Access Identifier", draft-ietf-
	radext-nai-15 (work in progress), December 2014.
	[I-D.ietf-xmpp-6122bis]		[I-D.ietf-xmpp-6122bis]
	Saint-Andre, P., "Extensible Messaging and Presence		Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Address Format", draft-ietf-xmpp-		Protocol (XMPP): Address Format", draft-ietf-xmpp-
	6122bis-20 (work in progress), March 2015.		6122bis-22 (work in progress), May 2015.
	[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,		[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
	October 1969.		October 1969.
	[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,
	December 2002.		December 2002.
	[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION		[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
	4rev1", RFC 3501, March 2003.		4rev1", RFC 3501, March 2003.
	skipping to change at page 22, line 11 ¶		skipping to change at page 22, line 11 ¶
	[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 6120, March 2011.		Protocol (XMPP): Core", RFC 6120, March 2011.
	[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence		[RFC6122] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Address Format", RFC 6122, March 2011.		Protocol (XMPP): Address Format", RFC 6122, March 2011.
	[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security		[RFC6943] Thaler, D., "Issues in Identifier Comparison for Security
	Purposes", RFC 6943, May 2013.		Purposes", RFC 6943, May 2013.
			[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, May
			2015.
	[UTS39] The Unicode Consortium, "Unicode Technical Standard #39:		[UTS39] The Unicode Consortium, "Unicode Technical Standard #39:
	Unicode Security Mechanisms", July 2012,		Unicode Security Mechanisms", July 2012,
	<http://unicode.org/reports/tr39/>.		<http://unicode.org/reports/tr39/>.
	Appendix A. Differences from RFC 4013		Appendix A. Differences from RFC 4013
	This document builds upon the PRECIS framework defined in		This document builds upon the PRECIS framework defined in
	[I-D.ietf-precis-framework], which differs fundamentally from the		[I-D.ietf-precis-framework], which differs fundamentally from the
	stringprep technology [RFC3454] used in SASLprep [RFC4013]. The		stringprep technology [RFC3454] used in SASLprep [RFC4013]. The
	primary difference is that stringprep profiles allowed all characters		primary difference is that stringprep profiles allowed all characters
	skipping to change at page 23, line 4 ¶		skipping to change at page 23, line 9 ¶
	are simply disallowed by PRECIS.		are simply disallowed by PRECIS.
	Appendix B. Acknowledgements		Appendix B. Acknowledgements
	This document borrows some text from [RFC4013] and [RFC6120].		This document borrows some text from [RFC4013] and [RFC6120].
	The following individuals provided helpful feedback on this document:		The following individuals provided helpful feedback on this document:
	Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey		Marc Blanchet, Ben Campbell, Alan DeKok, Joe Hildebrand, Jeffrey
	Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt		Hutzelman, Simon Josefsson, Jonathan Lennox, James Manger, Matt
	Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan,		Miller, Chris Newman, Yutaka OIWA, Pete Resnick, Andrew Sullivan,
	Nico Williams, and Yoshiro YONEYA. Nico in particular deserves		Nico Williams, and Yoshiro YONEYA. Nico Williams in particular
	special recognition for providing text that was used in Section 3.4.		deserves special recognition for providing text that was used in
	Thanks also to Takahiro NEMOTO and Yoshiro YONEYA for implementation		Section 3.4. Thanks also to Takahiro NEMOTO and Yoshiro YONEYA for
	feedback.		implementation feedback.
	Robert Sparks and Derek Atkins reviewed the document on behalf of the		Robert Sparks and Derek Atkins reviewed the document on behalf of the
	General Area Review Team and the Security Directorate, respectively.		General Area Review Team and the Security Directorate, respectively.
	Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for		Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for
	employing him during his work on earlier versions of this document.		employing him during his work on earlier draft versions of this
			document.
	Authors' Addresses		Authors' Addresses
	Peter Saint-Andre		Peter Saint-Andre
	&yet		&yet
	Email: peter@andyet.com		Email: peter@andyet.com
	URI: https://andyet.com/		URI: https://andyet.com/
	Alexey Melnikov		Alexey Melnikov
End of changes. 19 change blocks.
	28 lines changed or deleted		37 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/