Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes

["Stanislav V. Smyshlyaev" <[e-mail]>]

Hello, Mike and Grigory!

Mike, I definitely agree with you that it is impossible to choose a single
solution for all PAKE applications. For example, now in Russia for the
current moment we have two fields where SESPAKE is used:
- protection of a channel between a PC and a cryptographic token (mostly
for the case of Bluetooth-tokens);
- draft implementations of IKEv2 with Russian crypto.
We have distinct issues with counters of attempts here – as you mentioned,
DoS prevention is crucial for many protocols, for IKE v2 particularly.
However, this does not mean that counters should not be controlled at all –
the whole PAKE idea would be nearly useless in this case – this only means
that counters must be managed sensitively and accurately: some of the
counters can be optional or can be controlled at other levels.

For example, in our SESPAKE RFC draft (
https://www.ietf.org/id/draft-smyshlyaev-sespake-01.pdf) we stress (Section
4, notes 5 and 6) that different counters must be handled in different
ways.
The most important point here is that any PAKE security proof exploits
limitations of password trials – so the connected issues must be
represented in some way (with one or another level of strictness) in any
PAKE protocol description.

Therefore, I would correct my consideration on PAKE requirements slightly.
It is of highly importance to add the requirement: a description of a PAKE
protocol MUST include descriptions and usage recommendations of the
following counters:
-          counters of unsuccessful connections in a row,
-          counters of unsuccessful connections for the particular password,
-          counters of the total connections (successful and unsuccessful)
for the current password.


Best regards,
Stanislav V. Smyshlyaev, Ph.D.,
Head of Information Security Department,
CryptoPro LLC


2016-01-28 23:45 GMT+03:00 Grigory Marshalko <[e-mail]>:

> Hi, for these heuristics we can use approaches like fuzzy extractors and
> the corresponding theory in order to determine corresponding limitations.
> But this of cause would require training phases.
>
> Regards,
> Grigory Marshalko,
> expert,
> Technical committee for standardisation "Cryptography and security
> mechanisms" (ТC 26)
> www.tc26.ru
>
> 28 января 2016 г., 21:10, "Mike Hamburg" <[e-mail]
> <[e-mail]%3E>> написал:
>
> Hello Dr Smyshlyaev,
>
> It's worth noting that in many systems, the risk of DoS weighs against the
> risk of password guessing. The designers of these systems may not find it
> acceptable to hard lock an account based on a global count of attempts,
> especially if most of their adversaries are not powerful. For example,
> eBay doesn't want people to lock out the accounts of their competitors just
> by trying 10 times to log in.  In these systems, heuristics are used
> (based eg on IP, CAPTCHAs or browser metrics) to deter guessing.  The same
> sort of work is applicable to PAKE systems. So I don't think brute force
> prevention will be so one-size-fits-all.
> Cheers,
> -- Mike
>
> Sent from my phone.  Please excuse brevity and typos.
>
> On Jan 28, 2016, at 02:59, Stanislav V. Smyshlyaev <[e-mail]>
> wrote:
>
>
>
> Good afternoon!
> The order of most security bounds of PAKE protocols is determined by the
> value  $q{send}/|D|$, where $D$ is a size of a password set and $q_{send}$
> is a number of the adversary’s active impacts on the channel. The active
> impact assumes that the adversary can intercept a data in the channel and
> change it. A PAKE protocol is secure if a little number of such impacts
> cannot lead to the adversary’s success for some threat. It means that for
> the secure protocol any active impact leads to the fail abortion of the
> protocol. The bounds of the security can be reflected in the particular
> values if there are limitations for the value $q_{send}$.  In practice it
> can be achieved with counters that limit the number of unsuccessful
> authentication attempts. These limitations are the essential part of the
> protocol as they define the final security. For example, their absence
> leads to the vulnerability of the protocol to the online password brute
> force attack.
> So we think that it is of highly importance to add the following
> requirement: the description of the protocol of the PAKE type MUST include
> the limitations and detailed description of the following counters:
> -          counters of the fail connections in a row,
> -          counters of the fail connections for the particular password,
> -          counters of the total connections (successful and unsuccessful)
> for the current password.
> Best regards,
> Stanislav V. Smyshlyaev, Ph.D.,
> Head of Information Security Department,
> CryptoPro LLC
> <[e-mail]> wrote:
>
> Dear Jörn,
> Thank you for the document.
> Here are some comments:
> 1. It is somewhat misleading to differ balanced and augmented by a type of password storage in Section 3.1 because in balanced PAKE protocols passwords can be stored as elements generated with a one-way function. As you already wrote in the second paragraph, the difference is whether it is providing KCI or not.
> 2. In Section 3.3, “~ while the second one proposes a generic construction that allows transferring any two-party PAKE into a GPAKE protocol.”. However, there are other papers to convert 2-party PAKE to group PAKE (e.g., [ACGP11]).
> M. Abdalla et al., “Contributory Password-Authenticated Group Key Exchange with Join Capability,”' CT-RSA 2011
> Best regards,
> Shin
> ------------------------------------------------------------------------------
> SeongHan Shin
> Information Technology Research Institute (ITRI),
> National Institute of Advanced Industrial Science and Technology (AIST),
> 8F, AIST Tokyo Waterfront Bio-IT Research Building,
> 2-4-7 Aomi, Koto-ku, Tokyo, 135-0064, Japan
> Tel : [phone]
> E-mail : [e-mail]
> ------------------------------------------------------------------------------
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>
>