[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8nHX2r9cfQ0gNeJAUrgSfAS8V16dVHv35BRnLn-YprZCg@mail.gmail.com>
Date: Sat, 17 Jun 2017 10:23:09 -0400
From: Jeffrey Walton <noloader@...il.com>
To: Lee Duncan <lduncan@...e.com>
Cc: "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>, open-iscsi@...glegroups.com
Subject: Re: Re: [PATCH v4 06/13] iscsi: ensure RNG is
seeded before use
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.
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.
Jeff
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.
