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

[Watson Ladd <[e-mail]>]

On Thu, Jan 28, 2016 at 9:19 PM, Stanislav V. Smyshlyaev
<[e-mail]> wrote:
> 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.

Upper-layer protocols and applications can limit the number of login
attempts. PAKEs that limit offline guessing and force online are
sufficient, as most protocols already implement login limits. I don't
see why site-specific policy needs to be put in an RFC.

>
>
> 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]> написал:
>>
>> 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
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.