Subject: [http-auth] Commonarities discussion: technical side, feature sets

From: Yutaka OIWA <[email-masked]>
Date: Tue, 12 Nov 2013 06:16:47 +0900

Dear all,

We had a discussion on possible merging of common features between drafts
in Vancouver.
Commonalities lies in two aspects: basic technical functionality (e.g.
key management)
and a user-interface/application-semantics facilities (e.g. log-out).
This mail is about the former.

In the past, I wrote a draft
http://tools.ietf.org/id/draft-oiwa-httpauth-multihop-template-00.txt
as a possible starting point at that time.
I'm not sticked to this previous proposal, but it might be a good
starting point for exploring "what features" the commonarities might have.

The requirements and the provision of my previous drafts are as follows:

Requirements: the key exchange primitives to be implemented must:

   * exchange two or more messages between servers and clients.
     (currently limited to client-first type of exchange, but it can
be extended)

   * generate a shared key between peers after that.
      The shared key agrees between peers when authentication succeeds,
      of differs when authentication fails.

...yes, these are quite simple.

Provisions: the template will then provide the following common facilities:

   * a discovery mechanism for required authentication algorithms
      (as usual as the 401 message in Basic, in an RFC 2617 way)

   * opportunistic shared key caching between peers
      - time- and number-based expiry of shared keys
      - nonce management for preventing replay attacks
      - automatic renegotiation for expired keys
      - both peer may freely drop/forget almost any cached keys and
protocols still work

   * short-cut exchange (sometimes called reauthentication) using
cached shared keys
     - 1RT with known URL, with cached keys
     - normal RTs with known URL, keys expired
     - +1RT for unknown URL, for an additional 401 message

   * channel binding with lower layers (HTTP and TLS)

   * (optional) channel binding with higher layers (binding key provision)

How do you think about these feature sets?
Do we have something missing?
If you have any idea on the missing features, please let me know.

Thanks,

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