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

[Василий Долматов <[e-mail]>]

> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[e-mail]> написал(а):
> 
> A major number of cryptography failures follows from incorrect embedding of lower-level protocols to high-level ones – if you prove the security of PAKE under specific assumtions on counter handling and then someone implements it without knowledge of them, you have a practical vulnerability. We do not create protocols for vacuum, we make them for practice and must write security considerations (a specific "Security considerations" section in RFC can be used for discussing these issues, if someone thinks that they are not important enough to be in the main part).
I think that idea of moving these recommendations and notice about importance of correct setting of these counters to the «Security consideration» section is a good one.

dol@

> 
> To be more concrete: if one increments "insuccessful login attemps" counter only after the full protocol (agreement + key confirmation) in case of key confirmation failure and forgets to increment it in case of protocol interruption after agreement, a password guessing technique that is based on zero point can be easily applied.
> 
> You don't have to specify concrete scenarios, but you must at least give recommendations that are based on the assumptions you have in the security proof.
> 
> 
> Best regards,
> Stanislav V. Smyshlyaev, Ph.D.,
> Head of Information Security Department,
> CryptoPro LLC
> 
> 
> 
> 
> 
> 2016-01-29 8:34 GMT+03:00 Watson Ladd <[e-mail] <mailto:[e-mail]>>:
> On Thu, Jan 28, 2016 at 9:19 PM, Stanislav V. Smyshlyaev
> <[e-mail] <mailto:[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 <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] <mailto:[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 <http://www.tc26.ru/>
> >>
> >> 28 января 2016 г., 21:10, "Mike Hamburg" <[e-mail] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> >>
> >> ------------------------------------------------------------------------------
> >>
> >>
> >>
> >> _______________________________________________
> >> Cfrg mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> >
> >
> >
> > _______________________________________________
> > Cfrg mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> >
> 
> 
> 
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg