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