Subject: Re: [Cfrg] Requirements for PAKE schemes

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 28 Jan 2016 13:59:10 +0300

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

<[email-masked]> 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 : +81-3-3599-8001
> E-mail : [email-masked]
> ------------------------------------------------------------------------------
>
>
>

---

From: Mike Hamburg <[email-masked]>
Date: Thu, 28 Jan 2016 10:09:24 -0800

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 <[email-masked]> 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 total connections (successful and unsuccessful) for the current password.
> 
> 
> Best regards,
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Grigory Marshalko" <[email-masked]>
Date: Thu, 28 Jan 2016 20:45:44 +0000

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"  написал:

Hello Dr Smyshlyaev,

Cheers,
-- Mike

On Jan 28, 2016, at 02:59, Stanislav V. Smyshlyaev  wrote:

Good afternoon!

 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 : +81-3-3599-8001 E-mail : [email-masked] (mailto:[email-masked]) ------------------------------------------------------------------------------

_______________________________________________
Cfrg mailing list
[email-masked] (mailto:[email-masked])
https://www.irtf.org/mailman/listinfo/cfrg (https://www.irtf.org/mailman/listinfo/cfrg)

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 29 Jan 2016 08:19:13 +0300

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,

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

> 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,
> 28 января 2016 г., 21:10, "Mike Hamburg" <[email-masked]
> <[email-masked]%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
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 28 Jan 2016 21:34:28 -0800

On Thu, Jan 28, 2016 at 9:19 PM, Stanislav V. Smyshlyaev
<[email-masked]> wrote:
> - protection of a channel between a PC and a cryptographic token (mostly for
> the case of Bluetooth-tokens);
> 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.
> 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.
>

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.

>> 28 января 2016 г., 21:10, "Mike Hamburg" <[email-masked]> написал:
>>
>> Hello Dr Smyshlyaev,
>>
>> 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
>>
>> 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.
>> 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]).

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

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 29 Jan 2016 09:26:42 +0300

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,

2016-01-29 8:34 GMT+03:00 Watson Ladd <[email-masked]>:

> represented
> eBay
> leads
> >> M. Abdalla et al., “Contributory Password-Authenticated Group Key
> Exchange
> >> with Join Capability,”' CT-RSA 2011
> >> Best regards,
> >> Shin
> >>
> >>

---

From: Василий Долматов <[email-masked]>
Date: Fri, 29 Jan 2016 11:04:13 +0300

> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[email-masked]> написал(а):
> 
> 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,
> 2016-01-29 8:34 GMT+03:00 Watson Ladd <[email-masked] <mailto:[email-masked]>>:
> <[email-masked] <mailto:[email-masked]>> wrote:
> > Hello, Mike and Grigory!
> >
> > (https://www.ietf.org/id/draft-smyshlyaev-sespake-01.pdf <https://www.ietf.org/id/draft-smyshlyaev-sespake-01.pdf>) we stress (Section
> > 2016-01-28 23:45 GMT+03:00 Grigory Marshalko <[email-masked] <mailto:[email-masked]>>:
> >>
> >> www.tc26.ru <http://www.tc26.ru/>
> >>
> >> 28 января 2016 г., 21:10, "Mike Hamburg" <[email-masked] <mailto:[email-masked]>> написал:
> >>
> >> Hello Dr Smyshlyaev,
> >>
> >> On Jan 28, 2016, at 02:59, Stanislav V. Smyshlyaev <[email-masked] <mailto:[email-masked]>>
> >> wrote:
> >>
> >>
> >>
> >> Good afternoon!
> >> <[email-masked] <mailto:[email-masked]>> wrote:
> >>
> >> Dear Jörn,
> >> E-mail : [email-masked] <mailto:[email-masked]>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> >
> >
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
> >
> 
> 
> 
> --

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 29 Jan 2016 08:22:15 -0500

On 01/29/2016 03:04 AM, Василий Долматов wrote:
>
>> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[email-masked] 
>> <mailto:[email-masked]>> написал(а):
>>
>> 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,
>>     > 2016-01-28 23:45 GMT+03:00 Grigory Marshalko
>>     <[email-masked] <mailto:[email-masked]>>:
>>     >>
>>     <mailto:[email-masked]>> написал:
>>     >>
>>     >> Hello Dr Smyshlyaev,
>>     >>
>>     >> On Jan 28, 2016, at 02:59, Stanislav V. Smyshlyaev
>>     >> M. Abdalla et al., “Contributory Password-Authenticated Group
>>     Key Exchange
>>     <mailto:[email-masked]>
>>     >>
>>     >>

---

From: Yoav Nir <[email-masked]>
Date: Sat, 30 Jan 2016 11:49:51 +0200

> On 29 Jan 2016, at 3:22 PM, Robert Moskowitz <[email-masked]> wrote:
> 
> 
> 
>>> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[email-masked] <mailto:[email-masked]>> написал(а):
>>> 
> 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.

I’m not sure about that. These considerations are true for any PAKE. In fact, they’re true for any kind of password scheme. You could even make the case that they’re true for any authentication scheme, because letting the opponent keep guessing is at least creating a DoS on the attacked authentication server. 

We generally write in the Security Considerations section stuff that is relevant for that particular scheme, not for a whole class of schemes. So it may be fine to have a BCP document for “Deploying Password Authentication on the Internet”, but I don’t think we need some boilerplate text that goes into the security considerations of any password-related RFC.

Yoav

---

From: "Grigory Marshalko" <[email-masked]>
Date: Sat, 30 Jan 2016 12:15:32 +0000

It is very important to have such security considerations be written somewhere, especially if they are common and obvious for security experts. The problem is that for many implementors they are not obvious, and this is always the root of flawed implementations.

Regards,
Grigory Marshalko,
expert,

30 января 2016 г., 12:50, "Yoav Nir"  написал:

On 29 Jan 2016, at 3:22 PM, Robert Moskowitz  wrote: 
 On 01/29/2016 03:04 AM, Василий Долматов wrote: 

29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev  написал(а): 

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. 
I’m not sure about that. These considerations are true for any PAKE. In fact, they’re true for any kind of password scheme. You could even make the case that they’re true for any authentication scheme, because letting the opponent keep guessing is at least creating a DoS on the attacked authentication server. 

Yoav

---

From: Станислав Смышляев <[email-masked]>
Date: Sat, 30 Jan 2016 15:19:40 +0300

‎Hello, Yoav!

Thank you for your opinion; you are absolutely right that no one needs trivial considerations like "number of login attempts MUST be controlled" in each RFC (as much as "users MUST NOT store their passwords on sheets of paper pinned on their monitors", "Dual EC DRBG MUST NOT be used for generating both confidential and public data etc).

Moreover, including such an obvious recommendation is harmful for security of implementations. If one reads such a phrase, he'll probably stop reading "Security considerations" section and won't read really important info that should be there next: specific recommendations of handling login attempt counters‎ such as "counter value MUST be incremented before sending [i]-th message of the [xyz]PAKE protocol".

General recommendations shouldn't be there, but specific ones must.

Kind regards,

Stanislav

От: Yoav Nir

Отправлено: суббота, 30 января 2016 г., 12:49

Кому: Robert Moskowitz

Копия: Василий Долматов; Stanislav V. Smyshlyaev; [email-masked]

Тема: Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes

Yoav

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Sat, 30 Jan 2016 15:27:20 +0300

‎Hello, Yoav!

Thank you for your opinion; you are absolutely right that no one needs
trivial considerations like "number of login attempts MUST be controlled"
in each RFC (as much as "users MUST NOT store their passwords on sheets of
paper pinned on their monitors", "Dual EC DRBG MUST NOT be used for
generating both confidential and public data" etc).

Moreover, including such an obvious recommendation is harmful for the
security of implementations. If one reads such a phrase, he'll probably
stop reading "Security considerations" section and won't read really
important info that should be there next: specific recommendations of
handling login attempt counters‎ such as "counter value MUST be incremented
before sending [i]-th message of the [xyz]PAKE protocol".

Kind regards,
Stanislav

2016-01-30 15:15 GMT+03:00 Grigory Marshalko <[email-masked]>:

> It is very important to have such security considerations be written
> somewhere, especially if they are common and obvious for security experts.
> The problem is that for many implementors they are not obvious, and this is
> always the root of flawed implementations.
>
> Regards,
> Grigory Marshalko,
> expert,
> 30 января 2016 г., 12:50, "Yoav Nir" <[email-masked]
> <[email-masked]%3E>> написал:
>
>
>
>
> A major number of cryptography failures follows from incorrect embedding
> of lower-level protocols to high-level ones – if you prove the security of
> I’m not sure about that. These considerations are true for any PAKE. In
> fact, they’re true for any kind of password scheme. You could even make the
> case that they’re true for any authentication scheme, because letting the
> opponent keep guessing is at least creating a DoS on the attacked
> authentication server.
> We generally write in the Security Considerations section stuff that is
> relevant for that particular scheme, not for a whole class of schemes. So
> it may be fine to have a BCP document for “Deploying Password
> Authentication on the Internet”, but I don’t think we need some boilerplate
> text that goes into the security considerations of any password-related RFC.
> Yoav
>
>