Re: [http-auth] I-D Action: draft-ietf-httpauth-mutual-algo-00.txt

[Yutaka OIWA <[e-mail]>]

Dear Ilari,

2014-07-05 21:44 GMT+09:00 Ilari Liusvaara <[e-mail]>:

> Section 2.2&2.3:
>
> 2.2 has:
>> The value of K_s1 MUST satisfy 1 < K_s1 < q-1.  If this condition
>> is not held, the server MUST retry using another value for S_s1.
>
> And 2.3:
>> The value of K_s1 MUST represent a valid curve point and satisfy
>> [4] * P'(K_s1) <> 0_E. If this condition is not satisfied, the
>> server MUST retry using another value for S_s1.
>
> If K_c1 has certain relationship (extremely unlikely) with
> J(pi), that will fail over and over again (no S_s1 works).
>
> Values of S_s1 that don't work are AFAICT very rare anyway (making
> failures be dominated by all sorts of calculation errors in K_s1).

I've checked and analyzed our current draft and original ISO specification.
Current our specification is exactly corresponding to the
original spec in this aspect.

However, as you have mentioned,

If (J(pi) + [t_1] * K_c1') = 0_E or similar, the K_s1 will always be 0_E,
regardless of the choice of S_s1.
The value t_1 is also derived from K_c1 using a hash function.
If this happens, it causes a denial-of-service condition on server-side.
It depends on how J(pi) is stored in the server-side.

If J(pi) is computed on server-side from the plain-text password pi,
finding S_c1 which causes this problem is pretty hard.
It can be done off-line by clients, but it requires brute-force search on
the whole candidates of S_c1.

However, if J(pi) is provided from client-side, it is easy to cause
the problematic condition, by
 * choose an arbitrary S_c1 randomly,
 * compute J as -([t_1] * K_c1'), and send it to server as J(pi),
 * talk to server with per-determined S_c1.
The similar problem also exists in DL setting.
Verifying whether J is valid (correctly derived from some
plain-text password pi) is impossible.

Could someone double-check my observations above?

The fix is quite easy in one of two ways:
 * check that [4] * (J(pi) + [t_1] * K_c1') <> 0_E upon
    reception of K_c1, or
 * limit number of retries of S_s1 selection (to some small numbers).
In either ways, if the client is not malicious, possibility of
invoking this condition accidentally is cryptographically negligible.
I'll incorporate one of these additional checks into the next revision.

-- 
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: <[e-mail]>, <[e-mail]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]