Subject: [http-auth] [Mutual] answers for FAQs (1) auth-domain and web-origin

From: Yutaka OIWA <[email-masked]>
Date: Fri, 4 Oct 2013 08:54:22 +0900

Dear all reviewers and readers of http-auth,

As an author of the Mutual drafts, I really thank all reviewers for
useful comments.  I quite appreciate these comments for further
improvement of our drafts.

I'm going to answer to each of these comments, but it seems that,
before doing that,
I need to make some answers for some "frequently asked questions".
The first one is relation between our auth-domain and Web origin concept.

Shortly answered, these two are quite different, if my understanding
of "Web origin"
correct (you mean as that in RFC 6454?) .  Our auth-domain is instead
quite similar
to the Domain attribute of the Cookie mechanism (RFC 6265).
The space established by the auth-domain and Cookie domain typically spans
over multiple spaces established by Web origins.  More precisely,
auth-domain has three
possible kinds of ranges (server-specific, host-specific, and domain-specific),
and only the narrowest range is equivalent to a single Web origin.

Intention of doing so is twofold:
  * Often Web services spans multiple sub-domains inside a single domain
     (typical examples are mail.google.com, drive.google.com, and so on),
     and domain-issued cookies is used as an authorization key.
     It is convenient to share a common password database for these use cases.

  * In these cases, it is quite easy to make an SSO-like behavior, provided that
     password information is well protected by protocol for accidental leakage.

Digest authentication had somewhat similar concept (domain parameter allowed
to contain fully-qualified URLs even within different web-origins).
However, these are not implemented, and doing so may introduce quite unwanted
security implications (leaking of password information which can
directly be used
for off-line dictionary attacks).
We plugged these holes by restricting validity of credentials to specific
limited Web spaces specified by the auth-domain parameter.

The availability of SSO functionality in this mechanism is as same as those
provided by a single cookie with "two-legged" implementation.
Cookies are also used for three-legged, federated style of authentications
and authorizations, such as OAuth, OpenID, SAML and many more.
We currently do not have plan to provide any alternatives to these three-legged
things (re-inventing the wheels), and we think our scheme should just provide
a possible vehicle for initial user authentication for these existing schemes.

-- 
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]