Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1660688 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1660688 — Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

On Tue, Jun 06, 2017 at 07:47:57PM +0200, Jason A. Donenfeld wrote:
> It's not safe to use weak random data here, especially for the challenge
> response randomness. Since we're always in process context, it's safe to
> simply wait until we have enough randomness to carry out the
> authentication correctly.
> 
> While we're at it, we clean up a small memleak during an error
> condition.

What was the testing that was done for commit?  It looks safe, but I'm
unfamiliar enough with how the iSCSI authentication works that I'd
prefer getting an ack'ed by from the iSCSI maintainers or
alternativel, information about how to kick off some kind of automated
test suite ala xfstests for file systems.

Thanks,

					- Ted

[toc] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jun 8, 2017 at 4:43 AM, Theodore Ts'o <tytso@mit.edu> wrote:
> What was the testing that was done for commit?  It looks safe, but I'm
> unfamiliar enough with how the iSCSI authentication works that I'd
> prefer getting an ack'ed by from the iSCSI maintainers or
> alternativel, information about how to kick off some kind of automated
> test suite ala xfstests for file systems.

Only very basic testing from my end.

I'm thus adding the iSCSI list to see if they'll have a look (patch reattached).

Jason

[toc] | [prev] | [next] | [standalone]

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

On 06/08/2017 05:09 AM, Jason A. Donenfeld wrote:
> On Thu, Jun 8, 2017 at 4:43 AM, Theodore Ts'o <tytso@mit.edu> wrote:
>> What was the testing that was done for commit?  It looks safe, but I'm
>> unfamiliar enough with how the iSCSI authentication works that I'd
>> prefer getting an ack'ed by from the iSCSI maintainers or
>> alternativel, information about how to kick off some kind of automated
>> test suite ala xfstests for file systems.
> 
> Only very basic testing from my end.
> 
> I'm thus adding the iSCSI list to see if they'll have a look (patch reattached).
> 
> Jason
> 

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?
-- 
Lee Duncan
SUSE Labs

[toc] | [prev] | [next] | [standalone]

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

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.

Jason

[toc] | [prev] | [next] | [standalone]

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

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.
> 
> Jason
> 

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.
-- 
Lee Duncan

[toc] | [prev] | [next] | [standalone]

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

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.

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

[toc] | [prev] | [next] | [standalone]

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

> 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

[toc] | [prev] | [next] | [standalone]

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

Am Samstag, 17. Juni 2017, 05:45:57 CEST schrieb Lee Duncan:

Hi Lee,

> In your testing, how long might a process have to wait? Are we talking
> seconds? Longer? What about timeouts?
>

In current kernels (starting with 4.8) this timeout should clear within a few 
seconds after boot.

In older kernels (pre 4.8), my KVM takes up to 90 seconds to reach that 
seeding point. I have heard that on IBM System Z this trigger point requires 
minutes to be reached.

Ciao
Stephan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web