Mutual Authentication using CHAP
Chandra Seetharaman
I am using RHEL 5.4 open-iscsi SW initiator
(iscsi-initiator-utils-6.2.0.871-0.12.el5_4.1)
I tried to use CHAP for mutual authentication with my NetApp box.
It fails
----------------
[root@test146 tmp]# iscsiadm -m discovery -t st -p 10.0.0.22 -I eth1
iscsiadm: Login authentication failed with target
iscsiadm: discovery login to 10.0.0.22 failed, giving up
----------------
Note that one way CHAP works as expected.
Checked for bugs submitted in RedHat, and found
https://bugzilla.redhat.com/show_bug.cgi?id=265881, which was filed long
back and still in NEW/NEEDINFO state.
Has this been fixed ? Any pointers ?
Thanks,
chandra
Mike Christie
There have been two bugs with CHAP.
1. If you stored your discovery settings in the discovery db, but then
ran the discovery command again, the iscsid.conf info was used instead
of the discovery db info. You are probably not hitting that. You might
be hitting the reverse where you are using the db info but wanted to use
the iscsid.conf info. You must do iscsiadm -m discovery -p ip -o delete
to remove the old settings before using the iscsid.conf ones.
2. When using the discovery db settings when doing
iscsiadm -m discovery -ip -l
(note there is not type passed in)
then CHAP was failing because we length of the fields were not getting
set right.
I do not think you are hitting either of these problems. I just tried a
netapp box and open-iscsi here and it worked. On the target I ran:
iscsi security add -i iqn.2005-03.org.open-iscsi:mnc -s CHAP -p myinpass
-n myinname -o myoutpass -m myoutname
Then in iscisd.conf I had:
discovery.sendtargets.auth.username = myinname
discovery.sendtargets.auth.password = myinpass
discovery.sendtargets.auth.username_in = myoutname
discovery.sendtargets.auth.password_in = myoutpass
I am a little surprised that worked for me, because I though Netapp had
some password length restrictions. I cannot remember for sue, but I
think some Netapp boxes require you to use a min of 16 chars for the
password or have some other restriction. I think IBM's Mike Anderson
reported a bug where for iscsistart that program was only allowing 12
chars for the password but netapp wanted 16. For the password on netapp
boxes I normally run
iscsi security generate
to create passwords.
If you cannot get it to work send your iscsid.conf, the output of "iscsi
security show" and a ethereal trace. So maybe on
Chandra Seetharaman
mailing list :(
-------------------------------------------------------------------------
On Mon, 2010-02-15 at 14:48 -0800, Chandra Seetharaman wrote:
Found the issue. I was using the same username and password for both
directions.
Read the RFC (RFC 372) and learned that it is not correct.
(
Any CHAP secret used for initiator authentication MUST NOT be
configured for authentication of any target, and any CHAP secret used
for target authentication MUST NOT be configured for authentication
of any initiator.
)
Changed the username/password to be different on both directions and it does
connect fine.
regards,
chandra
Simone Morellato
Please note that CRC32C data digest checking was not included in the iSCSI package available through the yum update for CentOS 5.x.
The package version is: iscsi-initiator-utils 6.2.0.871-0.10.el5
Thanks,
Simone Morellato
Ulrich Windl
> I am a little surprised that worked for me, because I though Netapp had
> some password length restrictions. I cannot remember for sue, but I
> think some Netapp boxes require you to use a min of 16 chars for the
> password or have some other restriction. I think IBM's Mike Anderson
> reported a bug where for iscsistart that program was only allowing 12
> chars for the password but netapp wanted 16. For the password on netapp
> boxes I normally run
>
Maybe some "cookbooks" (i.e.: A success tory combined with a step-by-
step howto) on a web site would be nice for open-iscsi. Specifically
mention the version numbers involved. I and possibly many others have
tried several configuration options to find out that things didn't work
as expected.
(e.g. Two-way CHAP for the MPX 100 doesn't work, maybe partially HP's
ignorance on open-iscsi plays a role here as well)
Regards,
Ulrich
Ulrich Windl
> I sent it yesterday.. but for whatever reason, it didn't show up in the
> mailing list :(
> -------------------------------------------------------------------------
> On Mon, 2010-02-15 at 14:48 -0800, Chandra Seetharaman wrote:
>
> Found the issue. I was using the same username and password for both
> directions.
>
> Read the RFC (RFC 372) and learned that it is not correct.
> (
> Any CHAP secret used for initiator authentication MUST NOT be
> configured for authentication of any target, and any CHAP secret used
> for target authentication MUST NOT be configured for authentication
> of any initiator.
> )
>
> Changed the username/password to be different on both directions and it does
> connect fine.
That restriction makes sense: If you have multiple initiators using two-
way CHAP, all the initiators would know the other initiator's secrets
then, effectively making authentication useless. (They could
authenticate as the other initiator)
Regards,
Ulrich
Mike Christie
> On 16 Feb 2010 at 10:50, Mike Christie wrote:
>
>> I am a little surprised that worked for me, because I though Netapp had
>> some password length restrictions. I cannot remember for sue, but I
>> think some Netapp boxes require you to use a min of 16 chars for the
>> password or have some other restriction. I think IBM's Mike Anderson
>> reported a bug where for iscsistart that program was only allowing 12
>> chars for the password but netapp wanted 16. For the password on netapp
>> boxes I normally run
>>
>
> Maybe some "cookbooks" (i.e.: A success tory combined with a step-by-
> step howto) on a web site would be nice for open-iscsi. Specifically
Yeah, right good idea. Maybe also target quirks section for each target
vendor and type too. I am working on some new documentation and will
include this info.