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

[Robert Moskowitz <[e-mail]>]

On 01/29/2016 03:04 AM, Василий Долматов wrote:
>
>> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[e-mail] 
>> <mailto:[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.

I agree.  It is the perfect use of "security considerations" for a 
security technlogy.  None of the old "this whole document is about 
security".  The security considerations should contain what the 
risks/threats to the technology is and point out what is done to 
address/mitigate them.

>
> 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) 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
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > Cfrg mailing list
>>     > [e-mail] <mailto:[e-mail]>
>>     > https://www.irtf.org/mailman/listinfo/cfrg
>>     >
>>
>>
>>
>>     --
>>     "Man is born free, but everywhere he is in chains".
>>     --Rousseau.
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg