PRECIS Y. Oiwa
Internet-Draft RISEC, AIST
Intended status: Standards Track T. Nemoto
Expires: January 9, 2014 Keio University
B. Kihara
Lepidum
July 8, 2013
HTTPAuthPrep: PRECIS profile for HTTP Authentication
draft-oiwa-precis-httpauthprep-00
Abstract
This document describes how to handle Unicode strings representing
user names and passwords for HTTP authentication.
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 9, 2014.
Copyright Notice
Copyright (c) 2013 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.
Oiwa, et al. Expires January 9, 2014 [Page 1]
Internet-Draft PRECIS for HTTP Authentication July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. User Names . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Definition . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2. Preparation . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Passwords . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. Definition . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Preparation . . . . . . . . . . . . . . . . . . . . . . 5
3. Application Notes . . . . . . . . . . . . . . . . . . . . . . . 6
4. Design principles . . . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Normative References . . . . . . . . . . . . . . . . . . . 8
7.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Document History (to be removed) . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Oiwa, et al. Expires January 9, 2014 [Page 2]
Internet-Draft PRECIS for HTTP Authentication July 2013
1. Introduction
1.1. Overview
This document describes how to handle Unicode strings representing
user names and passwords for HTTP authentication.
For a long time starting HTTP/1.0 [RFC1945], character encodings of
HTTP authentication related parameters are defined and handled quite
loosely. [RFC1945] defined user-names of Basic authentication to be
a subset of ASCII strings (token), and passwords to be assumed as
ISO-8859-1 by recipients. Initial version of HTTP/1.1 [RFC2068] and
later revisions define grammar rules which indirectly (through the
definition of "TEXT" element) insist that both user-names and
passwords are in ISO-8859-1. In any way, these definitions are quite
often disregarded, and implementations tend to use their local
character sets and encodings, which has caused several
interoperability problems.
At the time of being (writing this document), the most promising way
of solving this problem is to use Unicode [UNICODE] character set
along with UTF-8 encoding [RFC3629] as a common vehicle. However,
just using UTF-8 does not completely solve the problem, or even makes
it worse, because of the non-unique encoding nature of Unicode
character sets.
Recently, a PRECIS [I-D.ietf-precis-framework] framework is being
standardized to cover this problem set. It defines a framework to
resolve non-uniqueness problem of Unicode character sets for
information-comparison purposes, especially useful for user
identifications. This document describes how to apply the PRECIS
framework for general HTTP user authentications, who to implement
such framework, and how to use it.
1.2. Applicability
The rules defined in this document can be used in two ways: one way
is to use them as MUST- (or SHOULD-) obey rules, by referring it from
another standard or non-standard document. In such case, the rules
defined in this document will have a normative property.
Another way is to use them as "best current practices", when some
specific HTTP authentication scheme does not define any specific
method of string preparations. In such case, any implementations are
not required to implement (or not to implement) the string
preparation rule in this document, but using it may sometimes improve
interoperability between implementations.
Oiwa, et al. Expires January 9, 2014 [Page 3]
Internet-Draft PRECIS for HTTP Authentication July 2013
Any specific authentication scheme MAY define its own string
preparation method, especially when an underlying software layer
supporting the authentication scheme (such as SASL) defines (or
recommends) its own string preparation method. In such cases,
implementations SHOULD NOT use the preparation rules described in
this document, and these SHOULD obey the scheme-specific requirement.
It is not feasible to implement the string preparation within all
HTTP implementations. For interoperability of authentication
process, only a small portion of involved softwares are required to
actually implement the string preparation algorithms. To this
purpose, general application notes are provided in the latter part of
this document.
1.3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
2. Rules
This section defines two PRECIS string preparation rules for user
names and passwords.
Note: the RFC 2119 requirements keywords such as "MUST" within this
section are effective as the RFC keywords only when the application
of these rules are either REQUIRED or RECOMMENDED by any
authentication scheme definitions.
2.1. User Names
2.1.1. Definition
User names are strings to identify the user in HTTP authentication.
username = 1*(idpoint)
;
; an "idpoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the PRECIS "IdentifierClass"
;
Note that some authentication schemes like Basic MAY restrict several
characters to be used in username.
Oiwa, et al. Expires January 9, 2014 [Page 4]
Internet-Draft PRECIS for HTTP Authentication July 2013
Note also that some authentication schemes like Digest modifies
users' inputs to other forms like quoted-string. This document
specifies only string preparation.
2.1.2. Preparation
A user name MUST NOT be zero bytes in length. This rule is to be
enforced after any normalization and mapping of code points.
Each username MUST conform to the definition of the PRECIS
IdentifierClass provided in [I-D.ietf-precis-framework], where the
width mapping, additional mapping, case mapping, normalization, and
directionality rules are as described below.
1. Fullwidth and halfwidth characters MUST be mapped to their
decomposition equivalents.
2. Additional mappings SHOULD NOT be applied, such as those defined
in [I-D.ietf-precis-mappings], unless there are implementation-
dependent reasons to do so, or these are exceptionally required
by specific authentication schemes.
3. Case mapping is not applied.
4. Unicode Normalization Form C (NFC) MUST be applied to all
characters.
With regard to directionality, the "Bidi Rule" provided in [RFC5893]
applies.
2.2. Passwords
2.2.1. Definition
Passwords are strings to authenticate the user in HTTP
authentication.
password = 1*(freepoint)
;
; a "freepoint" is a UTF-8 encoded
; Unicode code point that conforms to
; the PRECIS "FreeformClass"
;
Note that some authentication schemes MAY restrict several characters
to be used in passwords.
2.2.2. Preparation
A password MUST NOT be zero bytes in length. This rule is to be
enforced after any normalization and mapping of code points.
Oiwa, et al. Expires January 9, 2014 [Page 5]
Internet-Draft PRECIS for HTTP Authentication July 2013
A password MUST be treated as follows, where the operations specified
MUST be completed in the order shown:
1. Width mapping is not applied.
2. Map any instances of non-ASCII space to ASCII space (U+0020).
3. Case mapping is not applied.
4. Apply Unicode Normalization Form C (NFC) to all characters.
5. Ensure that the resulting string conforms to the definition of
the PRECIS FreeformClass.
With regard to directionality, the "Bidi Rule" (defined in [RFC5893])
and similar rules do not apply.
3. Application Notes
Implementation of the above rules are sometimes resource-consuming
and not realistic, especially when the implementation is not aware of
any Unicode string and is handling the authentication credentials as
opaque byte strings. This section provides a general application
notes for how to realize the above string preparation in the real
software.
Note: the note for RFC keywords in the previous section does apply
also for this section.
The general principle for the application is: "to send the string
correctly, by some means." In particular, if there is "some"
provision (either manually or automatically) to ensure the correct
encoding and preparation of string at the time of sending, it is
considered enough. As a definitive rule, the following provisions
are to be taken:
o Recipient side (i.e. HTTP servers) MAY omit any part of string
preparation, including Unicode normalization. It MAY process any
received strings as is.
o Senders which forward already-prepared strings (i.e. HTTP proxies
etc.) MAY omit any part of string preparation.
o Interactive clients which receive human users' input, as form of
"characters", have an obligation to prepare the input string into
a correct UTF-8 string with regards to the scheme-specific
preparation rules. When the authentication scheme specifies that
the preparation is a MUST, they MUST do it.
o Clients which receive credentials in a form of "list of octets"
(such as those within configuration files) MAY require its users
to prepare the string correctly within configuration phases, and
MAY omit any part of string preparation at runtime.
As a reverse to these rules, any recipients MUST be prepared to
Oiwa, et al. Expires January 9, 2014 [Page 6]
Internet-Draft PRECIS for HTTP Authentication July 2013
receive any unprepared byte lists or character lists as inputs. Such
recipients MAY prepare the string by its own, MAY reject such inputs
explicitly, or MAY process these inputs silently when it will lead to
failed authentication attempts. However, Such recipients MUST NOT
process such inputs in any way which leads to false authentication
successes (modulo cryptographically negligible level of
probabilities).
4. Design principles
Note: the content of this section is not normative.
The design of the rules provided in previous sections are made under
the following concerns and observations.
o ASCII transparency:
Every code-point within U+0020 to U+007E MUST be preserved,
distinguished, and mapped to its one-byte equivalent respectively.
This is a strong requirement for compatibility with existing HTTP
authentication.
o Latin-1 preservation:
Code-points U+00A1 to U+00FE SHOULD be preserved and distinguished
in the output string. This enables non-crashing mapping from
existing ISO-8859-1 user databases, and, if applicable, enables
backward-compatible server-side implementation for Basic plain-
text authentication.
o Case (non-)mapping:
As a subset of the above two rules, no case mapping shall be
applied (as a basic rule). Without this, some existing user
database will become non-useful, especially when it has already
used a non-mapped credentials, and its entries are hashed or one-
way encrypted. The opposite case (case-mapped existing databases)
can be at least worked around by users, server implementations, or
both.
Of course, some authentication schemes designed for specific use-
cases can always define a case-folded mappings whenever needed.
o Strong normalizations:
All representations (decomposed and composed) of every single
"character" within Unicode MUST be normalized to exactly one UTF-8
byte sequence. Without this, virtually all "non-Basic"
authentication may become broken with regard to internationalized
username and passwords (e.g. Digest).
5. Security Considerations
As mentioned previously, any recipients MUST NOT assume that senders
Oiwa, et al. Expires January 9, 2014 [Page 7]
Internet-Draft PRECIS for HTTP Authentication July 2013
will always send a correctly-prepared strings. Care must be taken
that incorrectly-prepared strings MUST lead to either a correct
result or an authentication failure.
6. IANA Considerations
[[TBD: more precise IANA Considerations here.]]
The IANA shall add the following two entries to the PRECIS Usage
Registry:
----
Applicability: User Names in HTTP Authentication.
Base Class: IdentifierClass.
Subclass: No.
Replaces: No.
Width Mapping: Map fullwidth and halfwidth characters to their
decomposition equivalents.
Additional Mappings: None.
Case Mapping: None.
Normalization: NFC.
Directionality: The "Bidi Rule" defined in RFC 5893 applies.
Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
the number issued for this specification.]
----
----
Applicability: Passwords of HTTP Authentication.
Base Class: FreeformClass
Subclass: No.
Replaces: No.
Width Mapping: None.
Additional Mappings: Map non-ASCII space to ASCII space (U+0020).
Case Mapping: None.
Normalization: NFC.
Directionality: The "Bidi Rule" defined in RFC 5893 does not apply.
Specification: RFC XXXX. [Note to RFC Editor: please change XXXX to
the number issued for this specification.]
----
7. References
7.1. Normative References
[I-D.ietf-precis-framework]
Saint-Andre, P. and M. Blanchet, "PRECIS Framework:
Oiwa, et al. Expires January 9, 2014 [Page 8]
Internet-Draft PRECIS for HTTP Authentication July 2013
Preparation and Comparison of Internationalized Strings in
Application Protocols", draft-ietf-precis-framework-08
(work in progress), April 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for
Internationalized Domain Names for Applications (IDNA)",
RFC 5893, August 2010.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version
6.1", 2012,
<http://www.unicode.org/versions/Unicode6.1.0/>.
7.2. Informative References
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[I-D.ietf-precis-mappings]
Yoneya, Y. and T. NEMOTO, "Mapping characters for PRECIS
classes", draft-ietf-precis-mappings-02 (work in
progress), May 2013.
Appendix A. Document History (to be removed)
Initial submit.
Oiwa, et al. Expires January 9, 2014 [Page 9]
Internet-Draft PRECIS for HTTP Authentication July 2013
Authors' Addresses
Yutaka Oiwa
National Institute of Advanced Industrial Science and Technology
Research Institute for Secure Systems
3-11-46 Nakouji
Amagasaki, Hyogo
JP
Email: mutual-auth-contact-ml@aist.go.jp
Takahiro Nemoto
Keio University
Graduate School of Media Design
4-1-1 Hiyoshi, Kohoku-ku
Yokohama, Kanagawa 223-8526
Japan
Email: t.nemo10@kmd.keio.ac.jp
Boku Kihara
Lepidum Co. Ltd.
#602, Village Sasazuka 3
1-30-3 Sasazuka
Shibuya-ku, Tokyo
Japan
Oiwa, et al. Expires January 9, 2014 [Page 10]