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