Subject: [http-auth] scim data format and structured credentials delivery/installations

From: Yutaka OIWA <[email-masked]>
Date: Tue, 14 Aug 2012 13:09:28 +0900

Dear SCIM people,

<background>
I am currently proposing a new HTTP authentication protocol for
enabling secure mutual authentication using shared credentials
(including pre-shared keys or passwords).
There are many features beyond conventional authentication methods,
but from the viewpoint of key/credential management (related to scim),
this authentication scheme have two properties concurrently:

 * enables use of encrypted (hashed) passwords on the server side
    - somewhat similar to Basic/Form
    - contrary to CHAP/Digest (which require passwords-equivalent),
 * allows non-plaintext exchange on-wire
    - similar to, but much stronger than CHAP/Digest
    - contrary to Basic/Form.

Server-side encrypted passwords are per-server basis,
so any stolen credential cannot be reused by other people,
provided that the client-side credentials have fair amount of entropy
(unlike 1234, password or xhtdj).
</background>

Under this background, my point asking on this mail is:
we have one missing feature on our protocol design: delivery of encrypted
passwords from clients to servers on the first registration phase.
Currently we have two ways for first-time registration:
 * letting servers know the plaintext passwords, and encrypt them on
the server side.
 * encrypting the passwords manually on the client side, while carefully
   inputing protocol-dependent security parameters that the server gives.
But both of them are unsatisfactory.
We have planned to develop a common format in the next steps
for exchanging such authentication parameters between peers
for single account registrations using Web browsers/Web Forms or other clients.

Looking beyond our proposal, there are also many key/credential formats
which requires key deliveries from clients to servers on the first
registration, including such as X.509 certificates (either full-certificate or
just DN part), unsigned RSA public keys, JWKs, SSH pubkeys,
machine-generated strong secrets, and even unix-hashed passwords.
We now aware that many parts of requirements for such use-cases are
common with what SCIM requires, and we should avoid designing two
similar parts on the same table.
I remember that in Vancouver SCIM session, some people also raised
requirements for deploying such non-plaintext secret within SCIM framework.

So, I'd like to reuse current data format for SCIM exchange for such purposes.
To do that, I plan to propose a generic extension mechanism for putting key
formats other than just plaintext passwords.   Such format may be useful for
other credentials as well,  and it can, of course, be used for SCIM-based
account management.
So I think that this extension satisfies some needs for SCIM as well as
other use cases.

Feedbacks are appreciated.

-- 
Yutaka OIWA, Ph.D.              Leader, Software Reliability 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]