|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ISCSI: User authentication vs. Machine Authentication for iSCSI
John Hufferd wrote:
Bill,
You are correct, in my opinion, on the problem statement, but not
on the
solution.
The IKE stuff will Get a system identified, and perhaps ensure that
a
encrypted connection is put in place. This then give the Source
and Target
the Freedom to exchange stuff that would otherwise be in the clear,
such as
iSCSI Node Names etc. But after the iSCSI session is established,
it is
between an OS and a target. The OS, is the thing that actually
owns the
resource, it only loans the resources, in some manor, to applications.
I was having a similar problem to what you stated, at the Irvine meeting,
and kept digging and objecting (off-stage) until I got the following
more
acceptable response.
Environment 1: (Use of IKE with complete Certificates processing ( or
pre-Shared password), with ESP equal to something other then Null)
1. We use IKE to get a mutually authenticated and Encrypted communication
link. This means that the Target knows that (at the IKE/TCP Layer)
there
is, at the other end, an authorized thing. (What or who that
thing is,
relative to iSCSI is not really known). This secure link can
be
established either via Certificates or via a pre-Shared password.
2. An iSCSI Login can now be done, over a secure link, so the iSCSI
Initiator Name, and iSCSI Target Name etc can be exchanged securely.
Please note, just because you passed the IKE certificate gate does
not mean
you are the iSCSI Initiator that you claim to be.
John,
Do i miss something? Why not use Certificate where
the subjectname is the iSCSI name (iqn or eui)?.
So as soon as the IPSEC SA are established each side
knows what intitiator/target is the other side.
There no need for extra password or alias.
The only problem with that is that some directory
as you mentionned below wouldn't support subjectname
as long as an iqn?
Regards,
Pierre
Therefore, a password,
for example, that is associated with the iSCSI Initiator Name can now
be
used to perform an iSCSI validation of the Initiator. (Please
note, this
could, instead of a password, be a Kerberos type Validation etc.)
3. David, and perhaps other used the words "User" or "Application"
name to
address what was being addressed in 2 above. But there was more
to this
then just assuming that the iSCSI Initiator Name was the User name.
Since
folks may actually want to use existing infrastructure, to handle the
password management and authentication process, they will need to assign
what I might call an "Alias for the iSCSI Initiator" which can actually
be
saved in the existing infrastructure user authentication repository.
The
point that was made to me, is that iSCSI Initiator Name (iqn or eui)
will
not "fit" into things that contain "User Names" so we need to have
a
corresponding "User Name" that we can actually authenticate using,
for
example Microsoft Active Directory etc. Hence the need for a "Alias
for the
iSCSI initiator. (I really hate this, and wish there was something
else we
could do.)
Home
Last updated: Tue Sep 04 01:03:50 2001
6315 messages in chronological order
|