Re: [kernel-hardening] [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

From	Paul Koning <paulkoning@comcast.net>
Newsgroups	linux.kernel
Subject	Re: [kernel-hardening] [PATCH v4 06/13] iscsi: ensure RNG is seeded before use
Date	2017-06-17 21:00 +0200
Message-ID	<tTr6V-2I9-3@gated-at.bofh.it> (permalink)
References	(3 earlier) <tQ4zT-48O-3@gated-at.bofh.it> <tT7rz-5Uk-7@gated-at.bofh.it> <tTa65-7Jj-7@gated-at.bofh.it> <tTcUi-1gh-13@gated-at.bofh.it> <tTmTD-8lq-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

> On Jun 17, 2017, at 10:23 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> 
> On Fri, Jun 16, 2017 at 11:45 PM, Lee Duncan <lduncan@suse.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@suse.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

Thread

Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use Theodore Ts'o <tytso@mit.edu> - 2017-06-08 04:50 +0200
  Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is  seeded before use "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-08 14:20 +0200
    Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is  seeded before use Lee Duncan <lduncan@suse.com> - 2017-06-17 00:00 +0200
      Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is  seeded before use "Jason A. Donenfeld" <Jason@zx2c4.com> - 2017-06-17 02:50 +0200
        Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is  seeded before use Lee Duncan <lduncan@suse.com> - 2017-06-17 05:50 +0200
          Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is  seeded before use Jeffrey Walton <noloader@gmail.com> - 2017-06-17 16:30 +0200
            Re: [kernel-hardening] [PATCH v4 06/13] iscsi: ensure RNG is seeded before use Paul Koning <paulkoning@comcast.net> - 2017-06-17 21:00 +0200
          Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use Stephan Müller <smueller@chronox.de> - 2017-06-18 10:10 +0200

csiph-web