Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords
draft-ietf-precis-saslprepbis-18

[Ballot comment]

- Unsurprisingly, the diff between this and RFC4013 isn't
useful, so I read from scratch. If I'm commenting on
something that was already true of 4013, just tell me and
that'll be fine.

- intro: given the unsolved i18n issues and the fact that
passwords are crap (security wise) would it be fair to ask
that you add a sentence here to encourage folks to not use
passwords at all but some better form of authentication,
when that's possible? (Which is sadly not nearly common
enough for user authentication.) Maybe something like:

"While this document specifies how to handle passwords
to the best of our current abilities, those designing and
implementing protocols would be much better off if they
can avoid any use of passwords. Using passwords means
having to deal with the inherent insecurity of passwords,
and of password verifier databases, and also the i18n
issues described here. Authentication schemes based on
digital signatures or other cryptographic mechanisms
are, where usable, far preferable."

- nitty nit: intro, 2nd last para on p3: once a password is
chosen, there are no more entropy changes so you cannot
maximise entropy *during* authentication. Maybe
s/during/for/ works though.

- 3.2.2, bullet 3: I read this as saying to use the latest
Unicode default case folding and not to stick with v7.0
even if a new and in this sense different version is
published. This is just to check that that is what you
intended and that I've not misread the text.

4.1: zero length password - I think you're wrong on that
one but it is arguable. This was a discuss until you told
me that 4013 prohibited 'em too so probably no point
in changing now if it's just my opinion.

There are situations where an empty password is ok (say
when I'm not "protecting" something but just want to know
what user's profile to use, e.g. for weather) and that is
supported in many systems (that hence won't be able to
exactly adopt this) and insisting on a non-empty password
could be more damaging than allowing a zero-length
password, whenever a user re-uses a password for something
for which no password is really needed (and which hence is
less likely to be well protected) and where that password
is also used to protect something of significantly higher
value. The zero-length password is also not an interesting
subset of the set of stupid passwords really so doesn't
deserve to be called out as such (and you say that in the
draft when you talk about length-1 passwords.) So I think
allowing zero length passwords is better overall, and more
consistent with implementations.

[Ballot comment]

- Unsurprisingly, the diff between this and RFC4013 isn't
useful, so I read from scratch. If I'm commenting on
something that was already true of 4013, just tell me and
that'll be fine.

- intro: given the unsolved i18n issues and the fact that
passwords are crap (security wise) would it be fair to ask
that you add a sentence here to encourage folks to not use
passwords at all but some better form of authentication,
when that's possible? (Which is sadly not nearly common
enough for user authentication.)

- nitty nit: intro, 2nd last para on p3: once a password is
chosen, there are no more entropy changes so you cannot
maximise entropy *during* authentication. Maybe
s/during/for/ works though.

- 3.2.2, bullet 3: I read this as saying to use the latest
Unicode default case folding and not to stick with v7.0
even if a new and in this sense different version is
published. This is just to check that that is what you
intended and that I've not misread the text.

[Ballot discuss]

4.1: zero length password - I think you're wrong on that
one but it is arguable. If RFC4013 also prohibited zero
length passwords (I couldn't tell at a quick glance) or if
the WG did debate this and having done so decided to
prohibit zero length passwords then I will clear the
discuss immediately. But if not, I'd like to chat about
it...

There are situations where an empty password is ok (say
when I'm not "protecting" something but just want to know
what user's profile to use, e.g. for weather) and that is
supported in many systems (that hence won't be able to
exactly adopt this) and insisting on a non-empty password
could be more damaging than allowing a zero-length
password, whenever a user re-uses a password for something
for which no password is really needed (and which hence is
less likely to be well protected) and where that password
is also used to protect something of significantly higher
value. The zero-length password is also not an interesting
subset of the set of stupid passwords really so doesn't
deserve to be called out as such (and you say that in the
draft when you talk about length-1 passwords.) So I think
allowing zero length passwords is better overall, and more
consistent with implementations.

[Ballot comment]

- Unsurprisingly, the diff between this and RFC4013 isn't
useful, so I read from scratch. If I'm commenting on
something that was already true of 4013, just tell me and
that'll be fine.

- intro: given the unsolved i18n issues and the fact that
passwords are crap (security wise) would it be fair to ask
that you add a sentence here to encourage folks to not use
passwords at all but some better form of authentication,
when that's possible? (Which is sadly not nearly common
enough for user authentication.)

- nitty nit: intro, 2nd last para on p3: once a password is
chosen, there are no more entropy changes to you cannot
maximise entropy *during* authentication. Maybe
s/during/for/ works though.

- 3.2.2, bullet 3: I read this as saying to use the latest
Unicode default case folding and not to stick with v7.0
even if a new and in this sense different version is
published. This is just to check that that is what you
intended and that I've not misread the text.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-precis-saslprepbis-15  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there is a single action which needs to be completed.

In the PRECIS Profiles subregistry of the Preparation and Comparison of Internationalized Strings (PRECIS) Parameters registry located at:

https://www.iana.org/assignments/precis-parameters/

three new profiles are to be registered as follows:

Name: UsernameCaseMapped
Base Class: IdentifierClass
Replaces: The SASLprep profile of Stringprep
Template: [ TBD-AT-REGISTRATION ]
Reference: [ RFC-TO-BE ]

Name: UsernameCasePreserved
Base Class: IdentifierClass
Replaces: The SASLprep profile of Stringprep
Template: [ TBD-AT-REGISTRATION ]
Reference: [ RFC-TO-BE ]

Name: OpaqueString
Base Class: FreeformClass
Replaces: The SASLprep profile of Stringprep
Template: [ TBD-AT-REGISTRATION ]
Reference: [ RFC-TO-BE ]

IANA Note --> As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we have initiated the required Expert Review via a separate request. We cannot make these registrations without expert approval.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Notification list changed to draft-ietf-precis-saslprepbis@ietf.org, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, mamille2@cisco.com, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org from draft-ietf-precis-saslprepbis@ietf.org, linuxwolf@outer-planes.net, precis@ietf.org, draft-ietf-precis-saslprepbis.ad@ietf.org, precis-chairs@ietf.org, draft-ietf-precis-saslprepbis.shepherd@ietf.org

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords) to Proposed Standard


The IESG has received a request from the Preparation and Comparison of
Internationalized Strings WG (precis) to consider the following document:
- 'Preparation, Enforcement, and Comparison of Internationalized Strings
  Representing Usernames and Passwords'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes updated methods for handling Unicode strings
  representing usernames and passwords.  The previous approach was
  known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454).
  The methods specified in this document provide a more sustainable
  approach to the handling of internationalized usernames and
  passwords.  The PRECIS framework, RFC YYYY, obsoletes RFC 3454, and
  this document obsoletes RFC 4013.

  [[ NOTE TO RFC EDITOR: please replace "YYYY" in the previous
  paragraph with the RFC number assigned to draft-ietf-precis-
  framework. ]]




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-precis-saslprepbis/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

Matthew Miller is the document shepherd, and Barry Leiba is the
responsible AD.  The document type is expected to be Proposed
Standard upon publication. This document will obsolete RFC 4013.

This document describes methods for handling internationalized
usernames and passwords. It provides for a more sustainable approach
than SASLprep (RFC 4013) by leveraging the PRECIS framework; this
includes better adaptability to future versions of Unicode. While
oriented toward SASL authentication schemes, the methods in this
document can be applied to other schemes, such as HTTP-based
authentication.


2. Review and Consensus

This document received wide review, including input from individuals
in the KITTEN and HTTP-AUTH Working Groups, and spanned at least two
Working Group Last Calls.  The consensus in the PRECIS Working Group
is to publish this document.

One of the major points of concern was how to handle case mapping in
usernames. In some protocols the case is significant, others it is
not. To address this concern, the consensus was to define two profiles
for usernames that protocols and applications are expected to choose
exactly one of: UsernameCaseMapped for when case is not significant,
and UsernameCasePreserved for when case is significant.

The other major point of concern was how to deal with changes to the
Unicode specifications (e.g., draft-klensin-idna-5892upd-unicode70).
This concern is not specific to this document -- or even to the PRECIS
Working Group -- but is relevant to all IETF technologies dealing with
internationalized text (e.g., IDNA2008 and PRECIS).  The issues are
complex and the IETF has not yet developed mitigations.  The rough
consensus of the Working Group was to proceed with the PRECIS work as
it stands since it is considered a significant improvement over the
Stringprep-based approach, and to address these issues more
comprehensively once future mitigations have been developed.


3. Intellectual Property

The document is submitted in full compliance with BCPs 78 and 79.
There are no IPR disclosures referencing this document.


4. Other Points

This document does not create any new IANA registries.  It does
register three new profiles to the PRECIS Profiles Registry:
UsernameCaseMapped, UsernameCasePreserved, and OpaqueString.

There is one nit about a possible downref to a non-RFC document
(UNICODE);  the reference is correct and meets with the Working
Group's consensus.  Other nits are in regard to updated I-Ds this
document references; there is no concern that this document is
substantively outdated with regards to the references, and it is
expected the RFC Editor will make the appropriate reference updates
before publication.

1. Summary

Matthew Miller is the document shepherd, and Pete Resnick is the
responsible AD.  The document type is expected to be Proposed
Standard upon publication. This document will obsolete RFC 4013.

This document describes methods for handling internationalized
usernames and passwords. It provides for a more sustainable approach
than SASLprep (RFC 4013) by leveraging the PRECIS framework; this
includes better adaptability to future versions of Unicode. While
oriented toward SASL authentication schemes, the methods in this
document can be applied to other schemes, such as HTTP-based
authentication.


2. Review and Consensus

This document received wide review, including input from individuals
in the KITTEN and HTTP-AUTH Working Groups, and spanned at least two
Working Group Last Calls.  The consensus in the PRECIS Working Group
is to publish this document.

One of the major points of concern was how to handle case mapping in
usernames. In some protocols the case is significant, others it is
not. To address this concern, the consensus was to define two profiles
for usernames that protocols and applications are expected to choose
exactly one of: UsernameCaseMapped for when case is not significant,
and UsernameCasePreserved for when case is significant.

The other major point of concern was how to deal with changes to the
Unicode specifications (e.g., draft-klensin-idna-5892upd-unicode70).
This concern is not specific to this document -- or even to the PRECIS
Working Group -- but is relevant to all IETF technologies dealing with
internationalized text (e.g., IDNA2008 and PRECIS).  The issues are
complex and the IETF has not yet developed mitigations.  The rough
consensus of the Working Group was to proceed with the PRECIS work as
it stands since it is considered a signficant improvement over the
Stringprep-based approach, and to address these issues more
comprehensively once future mitigations have been developed.


3. Intellectual Property

There are no IPR claims against this document.


4. Other Points

This document does not create any new IANA registries.  It does
register three new profiles to the PRECIS Profiles Registry:
UsernameCaseMapped, UsernameCasePreserved, and OpaqueString.

There is one nit about a possible downref to a non-RFC document
(UNICODE);  the reference is correct and meets with the Working
Group's consensus.  Other nits are in regard to updated I-Ds this
document references; there is no concern that this document is
substantively outdated with regards to the references, and it is
expected the RFC Editor will make the appropriate reference updates
before publication.

1. Summary

Matthew Miller is the document shepherd, and Pete Resnick is the
responsible AD.  The document type is expected to be Proposed
Standard upon publication. This document will obsolete RFC 4013.

This document describes methods for handling internationalized
usernames and passwords. It provides for a more sustainable approach
than SASLprep (RFC 4013) by leveraging the PRECIS framework; this
includes better adaptability to future versions of Unicode. While
oriented toward SASL authentication schemes, the methods in this
document can be applied to other schemes, such as HTTP-based
authentication.


2. Review and Consensus

This document received wide review, including input from individuals
in the KITTEN and HTTP-AUTH Working Groups, and spanned at least two
Working Group Last Calls.  The consensus in the PRECIS Working Group is
to publish this document.

One of the major points of concern was how to handle case mapping in
usernames. In some protocols the case is significant, others it is not.
To address this concern, the consensus was to define two profiles for
usernames that protocols and applications are expected to choose
exactly one of: UsernameCaseMapped for when case is not
significant, and UsernameCasePreserved for when case is
significant.

The other major point of concern was how to deal with changes to the
Unicode specifications (e.g., draft-klensin-idna-5892upd-unicode70).
This concern is not specific to this document -- or even to the PRECIS
Working Group -- but is relevant to all IETF technologies dealing with
internationalized text (e.g., IDNA2008 and PRECIS).  The issues are
complex and the IETF has not yet developed mitigations.  The rough
consensus of the Working Group was to proceed with the PRECIS work as
it stands since it is considered a signficant improvement over the
Stringprep-based approach, and to address these issues more
comprehensively once future mitigations have been developed.


3. Intellectual Property

There are no IPR claims against this document.


4. Other Points

This document does not create any new IANA registries.  It does
register three new profiles to the PRECIS Profiles Registry:
UsernameCaseMapped, UsernameCasePreserved, and OpaqueString.

There is one nit about a possible downref to a non-RFC document
(UNICODE);  the reference is correct and meets with the Working
Group's consensus.  Other nits are in regard to updated I-Ds this
document references; there is no concern that this document is
substantively outdated with regards to the references, and it is expected
the RFC Editor will make the appropriate reference updates before
publication.

1. Summary

Matthew Miller is the document shepherd, and Pete Resnick is the
responsible AD.  The document type is expected to be Proposed
Standard upon publication. This document will obsolete RFC 4013.

This document describes methods for handling internationalized
usernames and passwords. It provides for a more sustainable approach
than SASLprep (RFC 4013) by leveraging the PRECIS framework; this
includes better adaptability to future versions of Unicode. While
oriented toward SASL authentication schemes, the methods in this
document can be applied to other schemes, such as HTTP-based
authentication.


2. Review and Consensus

This document received wide review, including input from individuals
in the KITTEN and HTTP-AUTH Working Groups, and spanned at least two
Working Group Last Calls.  The consensus in the PRECIS Working Group is
to publish this document.

One of the major points of concern was how to handle case mapping in
usernames. In some protocols the case is significant, others it is not.
To address this concern, the consensus was to define two profiles for
usernames that protocols and applications are expected to choose
exactly one of: UsernameCaseMapped for when case is not
significant, and UsernameCasePreserved for when case is
significant.

The other major point of concern was how to deal with changes to
the Unicode specifications.  This concern is not specific to this
document but is relevant to all of the PRECIS documents, and arose again
after draft-ietf-precis-framework entered the RFC Editor queue.  After
lengthy discussions inside and outside the WG, the consensus is to
reference the latest version of Unicode and accept any potential
differences that might arise in future versions.


3. Intellectual Property

There are no IPR claims against this document.


4. Other Points

This document does not create any new IANA registries.  It does
register three new profiles to the PRECIS Profiles Registry:
UsernameCaseMapped, UsernameCasePreserved, and OpaqueString.

There is one nit about a possible downref to a non-RFC document
(UNICODE);  the reference is correct and meets with the Working
Group's consensus.  Other nits are in regard to updated I-Ds this
document references; there is no concern that this document is
substantively outdated with regards to the references, and it is expected
the RFC Editor will make the appropriate reference updates before
publication.

1. Summary

Matthew Miller is the document shepherd, and Pete Resnick is the
responsible AD.  The document type is expected to be Proposed
Standard upon publication. This document will obsolete RFC 4013.

This document describes methods for handling internationalized
usernames and passwords. It provides for a more sustainable approach
than SASLprep (RFC 4013) by leveraging the PRECIS framework; this
includes better adaptability to future versions of Unicode. While
oriented toward SASL authentication schemes, the methods in this
document can be applied to other schemes, such as HTTP-based
authentication.


2. Review and Consensus

This document received wide review, including input from individuals
in the KITTEN and HTTP-AUTH Working Groups, and spanned at least two
Working Group Last Calls.  The consensus in the PRECIS Working Group is
to this document.

One of the major points of concern was how to handle case mapping in
usernames. In some protocols the case is significant, others it is not.
To address this concern, the consensus was to define to profiles for
usernames that protocols and applications are expected to choose
exactly one of: UsernameCaseMapped in cases where case is not
significant, and UsernameCasePreserved in cases where case is
significant.

The other major point of concern was how to deal with changes to
the Unicode specifications.  This concern is not specific to this
document but is relevant to all of the PRECIS documents, and arose again
after draft-ietf-precis-framework entered the RFC Editor queue.  After
lengthy discussions inside and outside the WG, the consensus is to
reference the latest version of Unicode and accept any potential
differences that might arise in future versions.


3. Intellectual Property

There are no IPR claims against this document.


4. Other Points

This document does not create any new IANA registries.  It does
register three new profiles to the PRECIS Profiles Registry:
UsernameCaseMapped, UsernameCasePreserved, and OpaqueString.

There is one nit about a possible downref to a non-RFC document
(UNICODE).  This reference is correct and meets with Working Group
consensus.  Other nits are in regard to updated I-Ds this document
references; there is no concern that this document is substantively
outdated with regards to the references, and it is expected the RFC
Editor will make the appropriate reference updates before publication.