RE: security model

[Joshua Tseng <jtseng@NishanSystems.com>]

Yaron,

>However, I believe that there is no escape from defining an iSCSI security.
Due
>to the need for data integrity and the infeasibility of it in Gbit
Ethernet, we
>must implement some digestion mechanism to insure it. This feature cannot
be
>implemented with IPSEC.

Can you explain what you mean by "This feature cannot be implemented with
IPSEC."?
Are you aware of the IP Authentication Header (AH) protocol defined by IPSec

(RFC 2402)?

Josh

-----Original Message-----
From: Yaron Klein [mailto:klein@sanrad.com]
Sent: Thursday, September 07, 2000 5:34 AM
To: Joshua Tseng
Cc: Dave Nagle; ips@ece.cmu.edu
Subject: Re: security model


Hi Joshua,

We are now investigating the IPSEC and how to integrate it in the security
mechanism. Our considerations are:

The security scheme should be as flexible as possible. One of the options in
the negotiation will be IPSEC. However, additional options will be
available.

The security is per session, not per TCP connection (established in the
login
phase).

Regarding IPSEC policies, I m checking the possibility of defining a policy
for
iSCSI. It may be something proprietary if the standardization procedure will
take to long.

However, I believe that there is no escape from defining an iSCSI security.
Due
to the need for data integrity and the infeasibility of it in Gbit Ethernet,
we
must implement some digestion mechanism to insure it. This feature cannot be
implemented with IPSEC.

Hope to get the security and login chapter soon, so we can all discuss it.
Any
ideas are more than welcomed.

Yaron Klein
SANRAD

Joshua Tseng wrote:

> Yaron,
>
> My suggestion WRT security is to take a good look at IPSec.
> IPSec has several advantages I can think of over SSL or TLS.
>
> 1)  Standardized key distribution methodologies already exist
> (ISAKMP/IKE) and have been implemented for use with IPSec.
>
> 2)  IPSec has the advantage that it is flexible, and security
> policies can be granularly applied to each iSCSI conversation,
> even when multiple conversations are going over the same TCP
> connection.  iSCSI can thus decide to encrypt only data PDU's,
> or only certain conversations, etc...  The precise granularity
> is implementation-specific.
>
> With TLS, everything sent through a TCP socket will use the
> same security policy.  If multiple iSCSI conversations are
> taking place over the same TCP connection, then all will be
> uniformly handled by the same security policy, whether it's
> 3DES or no encryption at all.  If this is desired, then that's
> fine, but I believe there will be cases where the user wants
> to only authenticate Command PDU's, while encrypting &
> authenticating data PDU's, for example.
>
> The following is an excerpt from section 4.4.1 of RFC 2041
> (Security Architecture for IP).  In this case, "application"
> refers to iSCSI.
>
>   "In host systems, applications MAY be allowed to select what security
>    processing is to be applied to the traffic they generate and consume.
>    (Means of signalling such requests to the IPsec implementation are
>    outside the scope of this standard.)  However, the system
>    administrator MUST be able to specify whether or not a user or
>    application can override (default) system policies.  Note that
>    application specified policies may satisfy system requirements, so
>    that the system may not need to do additional IPsec processing beyond
>    that needed to meet an application's requirements.  The form of the
>    management interface is not specified by this document and may differ
>    for hosts vs. security gateways, and within hosts the interface may
>    differ for socket-based vs.  BITS implementations.  However, this
>    document does specify a standard set of SPD elements that all IPsec
>    implementations MUST support."
>
> -----Original Message-----
> From: Yaron Klein [mailto:klein@sanrad.com]
> Sent: Sunday, September 03, 2000 3:53 AM
> To: Dave Nagle
> Cc: ips@ece.cmu.edu
> Subject: Re: security model
>
> We are now working on the on integrating the security model in the iSCSI
> draft.
> Some remarks considering your model:
>
> The data privacy (number 5) should be solved in a higher level, i.e., the
> block
> should be encrypted or digested by some hash before it is sent to the
> target.
> This issue is not in the scope of the transfer protocol.
>
> Number 2 should be expanded to initiator and target masquerading. If the
> enemy
> masquerades as the target, he can get all our secrets...
>
> Furthermore, the security considerations are affected by the performance
> consideration, i.e., the computation power and the transfer rate. Thus, in
> high-speed network, compromise should be made (it is not feasible or very
> expensive to totally secure the data in 1G). The security model should
> adjust
> itself to the nature of the iSCSI features. It should enable partial
> security
> (only command, only headers, digestion of data etc.)
>
> We are now in an intensive work to integrate the security issue in the
next
> draft. The login chapter will enable to establish a flexible and
negotiable
> security/authentication model for the iSCSI session.
>
> Any ideas, comments and solution regarding security, let me know,
>
> Reagrds,
>
> Yaron
>
> Dave Nagle wrote:
>
> > From: Banu Ozden & Mike Reiter
> >
> > We suggest the attached extensions to the security model proposed in
> > the iSCSI draft (Section 6).
> >
> > The existing iSCSI security model covers "communication security"
> > between an initiator and a target. It does not address "data
> > security".  Data security provides protection against possible attacks
> > to the data stored at the target. These include threats like
> > unauthorized disclosure of data at the target to administrators or
> > other clients of the target, and unauthorized modification of data at
> > the target.
> >
> > Our main motivation is to enhance the security model for storage
> > outsourcing environments where the Storage Service Provider (SSP)
> > personnel is not necessarily trusted or where the sharing of target
> > between different customers of the SSP raises a security concern.
> >
> > We are working on a security architecture for storage outsourcing.
> > We would like to know whether there is interest on including data
> > security considerations to iSCSI in addition to communication
> > security.
> >
> > Banu Ozden & Mike Reiter
> >
> > Bell Labs
> > 600 Mountain Ave.
> > Murray Hill, NJ 07974
> > http://www.bell-labs.com/who/ozden
> > http://www.bell-labs.com/who/reiter
> >
> > _______________________________________________________________
> > Threat Model
> >
> > T1. Disclosure of message contents to an eavesdropper intercepting
> >     communication between an initiator and a target.
> >
> > T2. An attacker masquerading as the initiator to a target or the target
> >     to an initiator. This includes an attacker manipulating
communication
> >     between an initiator and a target, e.g., to introduce false
messages,
> >     modify passing messages, or delete messages.
> >
> > T3. Disclosure of data to personnel maintaining the target or to other
> >     customers of the target.
> >
> > T4. The modification of data by the target or other customers of the
> >     target.
> >
> > Security Model
> >
> > 1. No Security (same as described in the iSCSI draft)
> >
> >      This mode does not authenticate nor does it encrypt data. This mode
> >      should be used in environments where there is minimal security risk
> >      and little chance for configuration errors.
> >
> > 2. Entity Authentication (referred to as End-to-End Authentication in
the
> >    iSCSI draft)
> >
> >      The initiator's and/or target's identity is authenticated.
> >      Once the client is authenticated, all messages are
> >      sent and received in the clear.  This mode should only be used when
> >      there is minimal risk to man-in-the-middle attacks,
> >      eavesdropping, message insertion, deletion, and modification.
> >
> > 3. Message Integrity (new)
> >
> >      This mode protects against T2 types of threats. It provides
> >      communication integrity.
> >
> > 4. Message Integrity Combined with Encryption (referred to as Encryption
> in
> >    the iSCSI draft)
> >
> >      This mode protects against threats T1 and T2. Thus, it provides
> >      communication integrity and communication privacy. It protects
> against
> >      man-in-the-middle attacks, eavesdropping, message insertion,
> deletion,
> >      and modification.
> >
> > 5. Data Privacy (new)
> >
> >      This mode protects against T3 types of threats. The initiator
> >      encrypts/decrypts data. The target stores encrypted data.
> >
> > 6. Data Privacy with Data Integrity
> >
> >      This mode protects against threats T3 and T4.
> >
> > 7. Some combinations of the above security options
> >
> >    For example, data privacy with message authentication (5 & 3)
> >    protects against threats T1, T2 and  T3.