SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: ISCSI: User authentication vs. Machine Authentication for iSCSI



    
    From a who-owns-what point of view, it's the end user or application
    that owns the data on a device.  Neither the device nor the application
    really cares about targets or even LUNs; this is all above SCSI.  I
    have a picture of this that I used in the interim meeting to discuss
    iSCSI authentication requirements; it's at:
    
    ftp://ftpeng.cisco.com/mbakke/iscsi/Visio-iscsi-security-rqmts.pdf
    
    Anyway, the user or application (perhaps a database, or file system
    on a host, or just a raw device that's used for something special)
    would be, in an ideal world, the entity we might want to authenticate
    before granting access to a device.  This is not currently practical,
    however, since most operating systems assume responsibility for the
    device on behalf of the user or application, and are trusted by the
    users and applications sharing an OS to keep track of who-gets-what,
    and enforce these rules properly.
    
    Back to iSCSI-land, we can't authenticate anything that's at a
    higher layer than the InitiatorName, so from the device's point
    of view, the InitiatorName is as far as we can go.  However, an
    implementer of an initiator could have the ability to do things
    like provide multiple InitiatorNames in the same driver, and have
    these InitiatorNames represent more abstract entities than just
    the machine itself.  It's the implementation's binding of an iSCSI
    InitiatorName to something at a higher level that allows iSCSI to
    provide the "user level security" that Steven is talking about.
    Most of today's operating systems don't necessarily provide an
    easy way to do this, but by allowing the notion of an Initiator
    to be separate from the notion of a machine means that future
    implementors (or perhaps clever current implementors) will have
    a way to provide a more "network-capable" storage stack.
    
    On the target side, there's more potential for flexibility, since
    the implementor is not generally subject to regular operation system
    stacks and semantics, and can implement whatever access control and/or
    authentication scheme he or she wants.  In the end, it would be the
    device that matters from an access control point-of-view; this device
    can appear behind any number of LUNs behind any number of targets, so
    there are a lot of creative ways in which these can be correlated and
    different points at which access control can be done.
    
    However, the simplest place to provide access control is at the iSCSI
    target.  Considering that a target is no longer bound to one interface,
    there is no need for a device to appear behind multiple targets for an
    initiator to have multiple paths to it.  This makes the iSCSI target
    a very nice, centralized point at which to do access control.  If an
    {application, user, O/S} needs another device, it can simply be added
    as a logical unit behind a target to which that entity already has the
    appropriate access.  If the target device adds another port or changes
    addresses, it's added in front of the target itself, and does not matter.
    Doing access control at the iSCSI target means that setting it up once
    is sufficient; it need not be modified in order to add access to storage,
    or add interfaces.  This means that in some cases, the complexity of
    SCSI-level access control can be avoided.
    
    At any rate, Josh is also right; iSCSI can only worry about authenticating
    its initiator and target endpoints.  However, an implementation at either
    end can "map" these endpoints to whatever it wants; there is no restriction
    that an initiator or target be mapped to a machine, interface port, or any
    other piece of hardware.  Implementations that find ways to map initiators
    and targets to the entities that the user really understands will have the
    opportunity to provide authentication closer to the "user-level security"
    that may be what people really want.
    
    (BTW, I include "applications" as equals to "users"; the "user" for most
    block-level storage is usually a filesystem or database, rather than an
    actual person).
    
    This was some of what the slide I had presented was getting at; that
    although iSCSI cannot be aware of the layers above it, at least it provides
    the flexibility in its endpoints to be mapped to upper layers in creative,
    and hopefully easier to manage, ways.
    
    (Oh, also BTW, please don't confuse the term "user" in this email with
    the "username" used by the CHAP and SRP protocols; they are also separate
    concepts).
    
    --
    Mark
    
    Joshua Tseng wrote:
    > 
    > Stephen,
    > >
    > > I agree with Jim Hafner.  The notion of `user level security' is
    > > exactly what iSCSI needs, due to the unique combination of factors
    > > that compose an iSCSI system.  In the initial case, where the iSCSI
    > > client is the host OS, the OS is fully capable of representing an
    > > identity (being a user) and hiding that identity from unprivileged
    > > users of that system.
    > 
    > iSCSI is a transport protocol.  Its role is to transport SCSI commands
    > and data.  Therefore, the security associations negotiated during the
    > inband iSCSI security login phase should be bound to the principals
    > that define the iSCSI endpoints.  I believe this is the "iSCSI Name"
    > (formerly WWUI).  Attempting to bind iSCSI security to something that
    > sits above iSCSI is a layering violation.  This includes SCSI, OS, or
    > user identities, which all should be transparent to iSCSI.
    > 
    > >
    > > > I'm not sure the problem you mentioned is specific to iSCSI
    > > as I have seen
    > > > a user-level Fibre Channel driver in action.
    > >
    > > True.  However, the user-mode driver is granted full `control'
    > > (i.e. root) privs if it is allowed to execute arbitrary SCSI commands.
    > >
    > > Access to raw storage has traditionally been a rigidly protected
    > > resource, which when granted, gives complete control of the associated
    > > domain (which might be more than one system in a SAN or cluster).
    > > This is a well-understood characteristic of the raw storage trust
    > > model.
    > 
    > This is SCSI's problem.  You should bring this up with T10.
    > 
    > Josh
    > 
    > >
    > > In the Berkeley networking model (praise the mighty), access to
    > > network communication (other than evesdropping) is not a rigidly
    > > protected resource.  The assumption is that the local endpoint is not
    > > granted any additional power by being able to communicate arbitrarily,
    > > and the remote endpoint must protect itself as appropriate to the
    > > service it offers.
    > >
    > > > The issue here is that the notion of user is an operating system
    > > > abstraction and has no meaning in domains in which the
    > > > OS has no administrative control (such as a SAN).
    > >
    > > Not really.  A user is an authenticable identity in any form.  The
    > > control is the access provided.
    > >
    > > > Extending the notion of an user outside the domain of an OS requires
    > > > primitives current SAN technology does not support (yet!)
    > >
    > > I agree that the present infrastructure doesn't support this idea
    > > well.  However, what we should do is define our security in such a way
    > > that the SAN infrastructure can evolve towards the same type of
    > > identity mechanisms that other networking services (try to) support.
    > >
    > > If we do this right (and I think Jim's got the idea) it can support
    > > both `the OS is completely trusted' (for now) and `each user has their
    > > own credentials' (later) models.  We just need to make sure we don't
    > > do anything stupid like claim that authenticable entity == IP address
    > > in the protocol itself.  At present we're not in risk of doing that,
    > > but maybe I should come out in support of it just in case :^)
    > >
    > > I don't think there's any concrete change to what's already specified
    > > to support this.  We certainly don't have to dot every I and cross
    > > every T on the multiple identities per system model
    > > (i.e. authentication and authorization infrastructure needn't
    > > instantly be created to solve the full problem), but I guess we should
    > > be aware of what we're shooting for as we specify additional security
    > > behavior.
    > >
    > > Steph
    > >
    
    -- 
    Mark A. Bakke
    Cisco Systems
    mbakke@cisco.com
    763.398.1054
    


Home

Last updated: Tue Sep 04 01:03:48 2001
6315 messages in chronological order