[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 17 Jun 2017 14:50:50 -0400
From: Paul Koning <paulkoning@...cast.net>
To: open-iscsi@...glegroups.com
Cc: Lee Duncan <lduncan@...e.com>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Theodore Ts'o <tytso@....edu>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
kernel-hardening@...ts.openwall.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
David Miller <davem@...emloft.net>,
Eric Biggers <ebiggers3@...il.com>,
"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
Chris Leech <cleech@...hat.com>
Subject: Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use
> On Jun 17, 2017, at 10:23 AM, Jeffrey Walton <noloader@...il.com> wrote:
>
> On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan <lduncan@...e.com> wrote:
>> On 06/16/2017 05:41 PM, Jason A. Donenfeld wrote:
>>> Hi Lee,
>>>
>>> On Fri, Jun 16, 2017 at 11:58 PM, Lee Duncan <lduncan@...e.com> wrote:
>>>> It seems like what you are doing is basically "good", i.e. if there is
>>>> not enough random data, don't use it. But what happens in that case? The
>>>> authentication fails? How does the user know to wait and try again?
>>>
>>> The process just remains in interruptible (kill-able) sleep until
>>> there is enough entropy, so the process doesn't need to do anything.
>>> If the waiting is interrupted by a signal, it returns -ESYSRESTART,
>>> which follows the usual semantics of restartable syscalls.
>>>
>> In your testing, how long might a process have to wait? Are we talking
>> seconds? Longer? What about timeouts?
>>
>> Sorry, but your changing something that isn't exactly broken, so I just
>> want to be sure we're not introducing some regression, like clients
>> can't connect the first 5 minutes are a reboot.
>
> CHAP (https://www.rfc-editor.org/rfc/rfc1994.txt) and iSCSI
> (https://www.ietf.org/rfc/rfc3720.txt) require random values. If iSCSI
> is operating without them, it seems like something is broken. From RFC
> 3720, Section 8.2.1, CHAP Considerations:
>
> When CHAP is performed over a non-encrypted channel, it is vulnerable
> to an off-line dictionary attack. Implementations MUST support use
> of up to 128 bit random CHAP secrets, including the means to generate
> such secrets and to accept them from an external generation source.
> Implementations MUST NOT provide secret generation (or expansion)
> means other than random generation.
That only applies to the generation of the secret, which is configured into iscsi, not created by it. A utility to generate the secret might be supplied, of course, just as one might have utilities to generate strong passwords, but it's not a component of the iSCSI protocol.
> CHAP actually has a weaker requirement since it only requires _unique_
> (and not _random_). From RFC 1994, Section 2.3, Design Requirements:
>
> Each challenge value SHOULD be unique, since repetition of a
> challenge value in conjunction with the same secret would permit an
> attacker to reply with a previously intercepted response. Since it
> is expected that the same secret MAY be used to authenticate with
> servers in disparate geographic regions, the challenge SHOULD exhibit
> global and temporal uniqueness.
>
> But its not clear to me how to ensure uniqueness when its based on
> randomness from the generators.
A strong RNG of length n will produce numbers likely to be unique until you approach the birtday limit 2^(n/2). So, say, a 128 bit challenge will be adequate.
paul
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
