Subject: [precis] About precis-httpauth-prep plan

From: Yutaka OIWA <[email-masked]>
Date: Mon, 1 Jul 2013 18:49:54 +0900

Dear PRECIS list members,

Corresponding to the request by Yoneya-san in Orlando,
I am considering for a precis profile for HTTP-authentication.

A straw-man I-D text is about to be prepared, but before submitting it,
I'd like to have some comments on what is to be written.
The following is a list-style summary of the possible content.
If you have any suggestions/comments/whatever, these are really appreciated.

Thanks,
Yutaka

[http-prep]

= Importance of string preparation in HTTP authentications

  * needs for I17N
  * existing movements for I17N

= applicability and scope

  * Generally applicable for all HTTP-(p7-)based authentications
  * It is only for the "default" algorithm
  * Specific authentication schemes MAY define alternative preparation to use
    (e.g. SASL-tunnelling, NTLM etc.)
  * Applicable for both Web and non-Web usages
  * Non-HTTP (e.g. HTML Form-based) authentications are out-of-scope
    * httpauth-prep will never require e.g. HTML-based auths to use this
    * however, it MAY be referred to/used by such applications if they want

= technical requirements (non-normative)

  * ASCII transparency (MUST-requirement)
    * Every codepoint within U+0020 to U+007E MUST be preserved, and
      mapped to its 1-byte equivalent respectively.
    * This is a requirement for existing HTTP auth compatibility

  * Latin-1 preservation (SHOULD requirement)
    * codepoints U+00A1 to U+00FE SHOULD be preserved.
    * this enables non-crashing mapping from existing ISO-8859-1 user databases.

  * strong normalization
    * all representations (decomposed and composed) of every single "character"
      MUST be normalized to exactly one unicode character sequence.
    * NFC is to be taken.
    * Without this, virtually all "non-Basic" authentication may become broken
      with regard to internationalized username and passwords (e.g. Digest).
      * Not only passwords but also username will need this, as
        usernames are often hashed with passwords before key exchange.
    * Example: "Japanese katakana GA" = U+30AC or
      U+30AB U+3099 ... should be prepared to U+30AC.

= Definition of preparation rule (the main part, normative)

    * To be written, a technical content

= Discussions

  * case mapping

    * ASCII transparency rule automatically excludes any kinds of case mappings.

    * Is this OK? ... This is the "safer" rule for existing system compatibility

    * When prep does not use case mapping...

      * Case-sensitive existing systems:
        * Basic: OK
        * Digest etc: OK for ASCII username/passwords

      * Case-insensitive existing systems
        * Basic: OK (server-side may case-mapping if they want)
        * Digest etc: to require users to input their name/passwords
in specific case
          (workaround relatively easy)

    * When prep forces use of case mapping... (e.g. lower-case mapping)

      * Case-sensitive existing systems:
        * Basic: NG for names/passwords containing mapped (capital) characters
          (workaround hard to imprement, sometimes impossible)
        * Digest etc: NG, ditto (workaround impossible)

      * Case-insensitive existing systems
        * Basic: OK
        * Digest etc: OK for ASCII username/passwords

--
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <[email-masked]>, <[email-masked]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Jul 2013 12:21:46 -0600

> I am considering for a precis profile for HTTP-authentication.

Hi Yutaka,

My apologies for the delayed reply. I see that you have already posted
your I-D. I can provide detailed feedback, but first I wonder: why not
just use draft-ietf-precis-saslprepbis for usernames and passwords,
instead of defining a new PRECIS profile for HTTP authentication? Is
there something special about HTTP authentication that makes the profile
defined in draft-ietf-precis-saslprepbis unusable? Also, it seems
preferable to use the same profile for both SASL and HTTP (shared code,
common user expectations, etc.).

Thanks!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 10 Jul 2013 16:42:05 -0400

> common user expectations, etc.).

same credentials carried over multiple apps...

Marc.

> 
> Thanks!
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> _______________________________________________
> precis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/precis

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Jul 2013 14:48:55 -0600

> same credentials carried over multiple apps...

Yes, that too! :-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Yutaka OIWA <[email-masked]>
Date: Thu, 11 Jul 2013 10:20:15 +0900

> Is there something special about HTTP authentication that makes the profile
> defined in draft-ietf-precis-saslprepbis unusable?

Simply speaking, case mapping.
To interoperate with existing user DBs, and to use with
case-sensitive existing systems, case mapping for
general-purpose HTTP authentication is a MUST-NOT.
We also expect that existing ASCII-only systems will
not implement the HTTPAUTHprep, and the existing
HTTP authentication is case-sensitive (or ASCII octetwise),
we SHOULD keep ASCII transparency, which means case-sensitive.

As you might have already read, HTTPAUTHprep will be
one of the simplest PRECIS profile.
(Possibly it may be called a SIMPLE precis profile instead.)
Given that there is a simple-enough case-insensitive
profile, I will be happy to merge with it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Jul 2013 13:19:42 -0600

Hi Yutaka,

Your feedback is consistent with the feedback that Nico and Jeffrey have
provided about the replacement for SASLprep. Since we will change
draft-ietf-precis-saslprepbis to make casemapping completely optional, I
think we will be able to define a general-purpose HTTP-auth profile of
that spec which forbids casemapping (whereas, say, XMPP might require or
recommend casemapping).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/