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

Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 29 January 2016 13:22 UTC

Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148241ACC89 for <cfrg@ietfa.amsl.com>; Fri, 29 Jan 2016 05:22:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.901
X-Spam-Level:
X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_RUURL=3, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBAtTi5Xiq4D for <cfrg@ietfa.amsl.com>; Fri, 29 Jan 2016 05:22:35 -0800 (PST)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4100E1AC3F0 for <cfrg@irtf.org>; Fri, 29 Jan 2016 05:22:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id EAA00621A5; Fri, 29 Jan 2016 08:22:33 -0500 (EST)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w3kLc8tCRSey; Fri, 29 Jan 2016 08:22:19 -0500 (EST)
Received: from lx120e.htt-consult.com (unknown [192.168.160.20]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 665F1621A4; Fri, 29 Jan 2016 08:22:18 -0500 (EST)
To: Василий Долматов <vdolmatov@gmail.com>, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
References: <CAMr0u6=76q4n-u1Vpv5vWjSNgi4CtaOJoX0EmvcbXH+9C4w2mg@mail.gmail.com> <78D9D0BF-4ADE-4DDB-88A4-BF03DD6336BA@shiftleft.org> <9c878c6b6b505414f71fa53442e4a33a@mail.tc26.ru> <CAMr0u6nzV_Y87ghnAcmhgkzk4fgdKtC3Kj8NqPyawHrjhGVySg@mail.gmail.com> <CACsn0ckKX7pKZ5qU0y6cR3jyGV8JmL1V8EAUwU6b4ShDYVxmYw@mail.gmail.com> <CAMr0u6kvc1B8MY7Nqs2NLd1tHPU6wiv7ti9QDQ5gvu6iRgw+2g@mail.gmail.com> <930102DC-F5B3-4233-BF6B-1EC631B4ABF5@gmail.com>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <56AB6787.1010302@htt-consult.com>
Date: Fri, 29 Jan 2016 08:22:15 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <930102DC-F5B3-4233-BF6B-1EC631B4ABF5@gmail.com>
Content-Type: multipart/alternative; boundary="------------060202000405090600000509"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/qUb7EtN-yReGtLH9SqCiRd5vnuc>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Subject: Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jan 2016 13:22:40 -0000


On 01/29/2016 03:04 AM, Василий Долматов wrote:
>
>> 29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <smyshsv@gmail.com 
>> <mailto:smyshsv@gmail.com>> написал(а):
>>
>> 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 <watsonbladd@gmail.com 
>> <mailto:watsonbladd@gmail.com>>:
>>
>>     On Thu, Jan 28, 2016 at 9:19 PM, Stanislav V. Smyshlyaev
>>     <smyshsv@gmail.com <mailto:smyshsv@gmail.com>> 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
>>     <marshalko_gb@tc26.ru <mailto:marshalko_gb@tc26.ru>>:
>>     >>
>>     >> 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" <mike@shiftleft.org
>>     <mailto:mike@shiftleft.org>> написал:
>>     >>
>>     >> 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
>>     <smyshsv@gmail.com <mailto:smyshsv@gmail.com>>
>>     >> 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
>>     >> <seonghan.shin@aist.go.jp <mailto:seonghan.shin@aist.go.jp>>
>>     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 : seonghan.shin@aist.go.jp
>>     <mailto:seonghan.shin@aist.go.jp>
>>     >>
>>     >>
>>     ------------------------------------------------------------------------------
>>     >>
>>     >>
>>     >>
>>     >> _______________________________________________
>>     >> Cfrg mailing list
>>     >> Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>>     >> https://www.irtf.org/mailman/listinfo/cfrg
>>     >
>>     >
>>     >
>>     > _______________________________________________
>>     > Cfrg mailing list
>>     > Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>>     > https://www.irtf.org/mailman/listinfo/cfrg
>>     >
>>
>>
>>
>>     --
>>     "Man is born free, but everywhere he is in chains".
>>     --Rousseau.
>>
>>
>> _______________________________________________
>> Cfrg mailing list
>> Cfrg@irtf.org <mailto:Cfrg@irtf.org>
>> https://www.irtf.org/mailman/listinfo/cfrg
>
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg