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

["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).

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

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