[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Suggested resolution of the IESG discuss comment on RFC 2486bis
I'm concerned about the way the documents formal syntax attempts to bring in the SASLprep
work; it seems likely that an implementor might believe that only the mapping and normalization
steps of saslprep are required, where I believe the intent is to prohibit characters which are not
legal output characters according to SASLprep. The document says this:
c =/ %x80-ff ; UTF-8 allowed (not in RFC 2486)
; c must also satisfy rules in Section 2.4
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8 characters (this
; was not allowed in RFC 2486)
Section 2.4, in turn, says:
In order to ensure a canonical representation, characters of the
username portion in an NAI MUST fulfill the requirements specified in
[I-D.ietf-sasl-saslprep]. In addition, the use of certain special
characters (see grammar rule c) are prohibited as well in order to
retain compatibility with the previous version of this RFC.
SASLprep has multiple aspects; mapping, normalization, and prohibited
output. If the authors mean to disallow the prohibited output set of
characters from SASLprep, I believe the statement in the formal syntax
should reference the prohibited set. Other mechanisms which make
clear whether the prohibited output set is or is not allowed in a username
side would be fine as well.
I agree with the issue that was raised.
Here's an attempt to correct the problem. What I want to do is
to make the requirement explicit, both in the ABNF and in the
text. Here's the relevant part of the new ABNF
c =/ %x80-FF ; UTF-8-Octet allowed (not in RFC 2486)
; Where UTF-8-octet is any octet in the
; multi-octet UTF-8 representation of a
; unicode codepoint above %x7F.
; Note that c must also satisfy rules in
; Section 2.4, including, for instance,
; checking that no prohibited output is
; used (see also Section 2.3 of
; [I-D.ietf-sasl-saslprep]).
x = %x00-FF ; all 128 ASCII characters, no exception;
; as well as all UTF-8-octets as defined
; above (this was not allowed in
; RFC 2486). Note that c must nevertheless
; again satisfy the Section 2.4 rules.
and new text in Section 2.4:
2.4 International Character Sets
This specification allows both international usernames and realms.
International usernames are based on the use of Unicode characters,
encoded as UTF-8 and processed with a certain algorithm to ensure a
canonical representation. The realm part internationalization is
based on International Domain Name (IDN) [RFC3490].
In order to ensure a canonical representation, characters of the
username portion in an NAI MUST fulfill both the ABNF in this
specification as well as the requirements specified in
[I-D.ietf-sasl-saslprep]. These requirements consist of the
following:
o Mapping requirements, as specified in Section 2.1 of
[I-D.ietf-sasl-saslprep]. Mapping consists of mapping certain
characters to others (such as SPACE) in order to increase the
likelihood of correctly performed comparisons.
o Normalization requirements, as specified in Section 2.2 of
[I-D.ietf-sasl-saslprep], also designed to assist comparisons.
o Prohibited output. Certain characters are not permitted in
correctly formed strings that follow Section 2.3 of
[I-D.ietf-sasl-saslprep]. Ensuring that NAIs conform to their
ABNF is not sufficient, it is also necessary to ensure that they
do not contain prohibited output.
o Bidirectional characters are handled as specified in Section 2.4
of [I-D.ietf-sasl-saslprep].
o Unassigned code points are specified in Section 2.5 of
[I-D.ietf-sasl-saslprep].
The realm name is an "IDN-unaware domain name slot" as defined in
[RFC3490]. That is, it can contain only ASCII characters. An
implementation MAY support internationalized domain names (IDNs)
using the ToASCII operation; see [RFC3490] for more information.
--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>