Subject: [Cfrg] [Request for comments] revision of state machine specification in draft-ietf-httpauth-mutual

From: Yutaka OIWA <[email-masked]>
Date: Fri, 11 Apr 2014 14:24:11 +0900

Dear readers of http-auth and cfrg,

I previously received some concerns about too-complex notion of
state machine definitions in my HTTP Mutual Authentication draft
[http://tools.ietf.org/html/draft-ietf-httpauth-mutual-01#section-9].
I am really grateful for the important feedbacks for our drafts.

Although my intention for using this was to ease non-security programmers to
implement a correct algorithm without caring about details of the
security designs,
it also raised concerns about the difficulty of verifying the
algorithm itself by experts.

I have written two straw-man expressions for replacing/supplementing the
original description in the current draft.
The first one is a simplified, equivalent state machine with
two boolean "switches" for controlling the behavior.
The second one is a further simplified pair of rule itemizations, but here the
important side conditions are expressed in more implicit way in English only.

I'd like to hear some impressions about these alternative representations
attached below, compared with the original notation in the draft above.
Even a simple comments like "I like the version 2" is very welcome.
I'll consider these for the -03 revision of the draft, hopefully.
(I have some plan for -02 revision very soon.)
The details of English texts will be further polished before actually
incorporated into the future submitted draft.

Thanks in advance,

Yutaka

Possible revision tactic (1) [state-machine with internal flags]

================================================================
Flags: F for "first request".
       SR for "reusing stored session now".

(1) Let (F, SR) = (1, 0).
    Guess whether the request URI is likely authenticated.
    * Yes -> Goto (4).
    * No  -> Continue to (2).

(2) Try sending a normal request.
    * Received 401 requesting authentication (401-INIT)
        -> Continue to (3).

(3) F := 0.
    Determine if you know the user-name and password for the given realm.
    * Yes -> Continue to (4).
    * No -> Ask user for it. [status = AUTH-REQUESTED].

(4) Determine whether you have a possibly-valid stored session for
    the given realm.
    * Yes -> SR := 1, Goto (6).
    * No  -> Continue to (5).

(5) SR := 0.
    Send key exchange from client (KEX-C1).
    * Received server key exchange response (401-KEX-S1)
          -> F := 0, Continue to (6).
    * Received normal authentication request (401-INIT)
          -> Authentication Failed [status = AUTH-REQUESTED].

(6) Send client-side key verification (VFY-C).
    * Received server-side key verification (200-VFY-S)
          -> Check server verifier token.
         If OK: Authentication Succeeded [status = AUTH-SUCCEED].
            NG: Fatal communication error.
    * Received normal authentication request (401-INIT)
          -> Authentication Failed [status = AUTH-REQUESTED].
    * Received stale session reply (401-STALE)
          -> If SR = 1: F := 0, Goto (5).
                SR = 0: ERROR.

Other responses:
  * Normal response:
      if F = 1: no authentication provided [status = UNAUTHENTICATED].
       F = 0: ERROR.
  * Authentication request (401-INIT) for a different realm:
        if F = 1: Goto (3).
     F = 0: ERROR.
================================================================

Possible revision tactic (2): Highly implicit version.

================================================================

The label "[Continue]" means you should go back to "What to send"
and continue sending another request in sequence.

The labels "[status = XXX]" means the successful termination
of the request/response loop.

The label "[Error]" means fatal communication error.

  * What to send:

   - If URL is not likely to be authenticated:
     send a normal request.

   - Else, authentication is somehow requested or guessed.
     If user name or password is not known, ask users for it.
     [status = AUTH-REQUESTED]

   - Else if there is a possibly-valid stored session,
     try sending VFY-C directly using that session.

   - Else, send a key exchange KEX-C1.

  * What to receive:

   - You may receive server-side key verification (200-VFY-S)
     only for VFY-C.
          -> Check server verifier token.
         If OK: Authentication has succeeded [status = AUTH-SUCCEED].
            NG: Fatal communication error [Error].

   - You may receive server key exchange response (401-KEX-S1)
     only for KEX-C1.
          -> continue to sending VFY-C [Continue].

   - You may receive stale key notification (401-STALE)
     against VFY-C.
          -> You may continue to send KEX-C1 [Continue],
         ONLY IF you have not yet sent KEX-C1 in the request sequence.
         Otherwise, [Error].

   - You may receive non-authenticating response.
         -> You may accept it [status = UNAUTHENTICATED],
         ONLY WHEN the request was the "first" one
         for a request sequence.
         Otherwise, [Error].

   - You may receive authentication request for another realm.
         -> You may accept it [Continue],
         ONLY WHEN the request was the "first" one
         for a request sequence.
         Otherwise, [Error].

   - You may receive an authentication request (400-INIT).
         -> OK if the request was a normal request. Start authentication
         [Continue].
      -> OK if the request was VFY-C.
         It means credential was wrong and authentication was failed.
         [status = AUTH-REQUESTED]
      -> OK if the request was KEX-C1.
         It also means authentication was failed, where
         server is not even accepting trial for authentication.
         [status = AUTH-REQUESTED]

   - All other unexpected responses are [Error].

================================================================

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