RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

David,
> 
> Before I launch into the latest response to Josh, I want to
> summarize the high level point I'm trying to make:
> 
> 	It isn't enough to just point to existing security 
> mechanisms and
> 	say "use these".  It's necessary to say how to use them with
> 	the protocol and what other assumptions must be true in order
> 	to achieve the desired security properties - some of these
> 	assumptions will be requirements on other components/protocols
> 	in the environment.

Thanks, and the point I'm trying to make is that iSCSI and IPSec/IKE can
pretty much work independently, with no compromise to security.  Having
IPSec and/or IKE become involved in iSCSI (or vice-versa) will increase
complexity while adding little additional value.

Note that I'm not necessarily saying the same about TLS.  I agree with
Julian that TLS may need something from iSCSI, since the SA's are bound to
the TCP socket.  But I am not as familiar with TLS, so maybe I shouldn't get
into this.

> 
> This is particularly true because iSCSI contains a naming architecture
> that does not match the identities used in existing security 
> mechanisms,
> resulting in a need to spell out in detail what is being authenticated
> using what sort of identities, the relationships (if any) among the
> different sorts of identities, and how those relationships 
> are achieved/
> assured.
> 
> There's nothing in principle wrong with the existing security 
> mechanisms
> being discussed - the devil is in the details of exactly how 
> they're used.
> The following set of responses to Josh provide some examples:
> 
> > There is an implied relationship in that once a set of SA's 
> is set up
> > between two IP addresses, each endpoint is completely 
> secure when talking
> to
> > the other endpoint.  This includes spoofing, man-in-middle, 
> eavesdropping,
> > etc...  If an iSCSI login comes
> > in from the other endpoint IP address=A, then I KNOW it is 
> coming from IP
> > address=A.  If that login from IP address=A says WWUI=XYZ, 
> then I can now
> > take action to allow or disallow WWUI=XYZ.
> 
> An important assumption underlying the "implied relationship" 
> is that the SA
> terminates at the iSCSI endpoints.  That's not in general the case for
> traffic passing through IPSec security gateways and hence is 
> the sort of
> thing that has to be spelled out if/when this sort of setup 
> is intended.

Agreed.

> 
> FWIW, "completely" is also not the right word - IPSec can set 
> up SAs that
> provide integrity but not confidentiality, and hence do not 
> protect against
> eavesdropping, but I'll bet that was just a poor choice of words
> on Josh's part.
> 
> > But what if it is really WWUI=PDQ just pretending that it 
> is WWUI=XYZ at
> IP
> > address=A?  Well, then there is already a public key authentication
> > mechanism defined in the current iSCSI draft, which 
> presents a digital
> > signature of the iSCSI login message. Since I have the 
> public key of the
> > real WWUI=XYZ, I can locally regenerate the required 
> digital signature of
> > the REAL WWUI=XYZ.  If it doesn't match, then I reject the login.
> 
> But how do one know that one has the *right* public key?  Since
> certificates aren't required in the current iSCSI draft, and the key
> distribution mechanism is not specified, all sorts of mischief is
> possible if naked public keys are being passed around.  Needless
> to say, that's not a particularly intelligent way to do key 
> distribution,
> but like the previous case, a discussion about what is required
> to assure that key distribution actually distributes the correct
> keys (and how to verify that if necessary) is in order.  The
> current iSCSI draft also includes a number of weaker authentication
> mechanisms that are vulnerable to man-in-the-middle attacks when
> there is not an end-to-end SA in contrast to public key mechanisms.

In this example, the public key comes from the X.509 certificate obtained
either from the iSNS or manually configured.  This certificate supposedly
can be bound to the WWUI and can be verified through the certificate
authority.  The iSNS spec describes this (section 5.5.16).

But note that this is only one method of iSCSI authentication.  Others
include the challenge handshake, shared secret password, kerberos, etc...see
the iSCSI spec.

The point is that IPSec provides the PER PACKET data
integrity/authentication and if desired, encryption.  The iSCSI login
process provides authentication AND authorization of the communicating
entities.  What more do you need?
> 
> > > - It opens up a set of attacks based on subverting the 
> mechanism (or
> > > 	lack thereof) used to associate IP addresses with iSCSI targets
> > > 	(and initiators). 	If iSCSI target T is supposed 
> to be behind
> IP address
> > > 	foo, and the adversary can convince initiator I to access T
> > > 	by instead opening up a tunnel-mode IPSec SA to a different
> > > 	IP address bar, the absence of any check between IP address
> > 
> > This could never happen.  Remember, initiator I has an SA 
> to IP address
> foo.
> 
> That's not correct.  The analogous attacks on DNS are old news.
> This class of attack targets the configuration/discovery/naming
> mechanism(s), convincing I to initially contact T at bar 
> rather than foo -
> once I makes this mistake, it's downhill from there.  It's necessary
> to spell out the base assumptions, some of which will be requirements
> on configuration/naming/discovery and authentication, and explain
> how to get from them to the conclusion that this sort of attack can't
> happen.h

For this attack to succeed, an attacker would have to penetrate the iSNS and
substitute T2 at IP addr 2 for the real target of T1 at IP addr 1.  It would
then also have to forge a public/private key pair and have it signed by the
"trusted" certificate authority.  And then it would have to get initiator I
to replace the real certificate of T1 with the forged certificate containing
the public key of T2.  I count at least 3 lines of defense, but the only one
that really matters IMO is the "trusted" certificate authority.

The difference between DNS and iSCSI is that DNS doesn't have an equivalent
to the iSCSI login message.  I think the combination of IPSec and iSCSI
login process to make the possibility of success for this attack extremely
unlikely against iSCSI.  If initiator I were to somehow talk to the wrong
target at the wrong IP address, more than likely this will be caught in the
iSCSI login, through either the public key authentication or one of the
other authentication mechanisms described in the current iSCSI draft.
> 
> > If the user chooses to deploy gateway-based security, then 
> of course there
> > must be other measures taken to secure against attacks 
> between the iSCSI
> > node and the gateway.
> 
> And some of those measures will almost certainly be
> mandatory-to-implement if there are no words in the spec
> about how the gateway SHOULD/MUST be related to the
> iSCSI nodes accessed through it.

The security measures I have in mind have more to do with physical security.
I do not believe the security gateway needs to be iSCSI (or WWUI) aware, nor
do I believe it would add significant security value if it were.

Remember that even if the standalone gateway was aware of iSCSI and WWUI, it
must make a decision to ingress traffic through the appropriate SA on a PER
PACKET basis, according to RFC 2401.  The WWUI only exists in the initial
iSCSI login PDU.  Therefore, the gateway must make a decision based upon
what exists and is visible in every packet (i.e., each individual TCP
segment).  This includes the Source and Dest IP addr, and source and dest
TCP port.  Therefore, physical security is required anyway, regardless of
whether the gateway is WWUI-aware, because the established TCP connection
(based on the initial iSCSI login PDU) can be hijacked.

The only real difference between a standalone gateway IPSec implementation
and an imbedded one is that physical security is pretty much assured, since
both IPSec and iSCSI exist on the same box.

And the only additional capability I can think of from making the IPSec
implementation iSCSI and WWUI-aware (for both gateway and embedded
implementations) is a capability to specify more than one security policy to
the same destination IP address.  Thus, if target A and B shared the same IP
address (or exist behind the same security gateway), you could say ESP/3DES
to target A, and AH/SHA-1 or no security to target B.  While that might be
an admirable capability in some settings, I certainly don't believe it
should be required.  Much implementation headache can be averted by simply
saying 3DES to everyone at IP address=A.  Yes, you would waste processing
power in this case if there were 50 targets sharing the same IP address (or
security gateway), and only one of them needed 3DES, but since you can't
configure a policy per WWUI, then all traffic to all 50 targets at that IP
address would have to be encrypted 3DES.  But once again, this will not hurt
security.

Josh

> 
> > However, I believe having the iSCSI node transfer its
> > WWUI to the gateway so that the gateway can set up an WWUI-based SA
> > is not practical.  How would you do it?  Would you need 
> another IPSec SA
> to
> > transfer the WWUI between the iSCSI node and the gateway?
> 
> The short answer is configuration of the SPD and related things on
> the gateway (assuming the gateway can use WWUI identities to set
> up SAs), but that misses the point.  The point is that just saying
> "use an IPsec gateway" isn't enough.  Something more needs to be
> said about *how* to use the gateway to achieve the desired security
> properties.  For example, a suitably secured iSNS may be one
> place to put the bindings between WWUIs and IP addresses, which
> would allow IPSec SAs based on IP address identities to be used
> to help assure WWUI-based authentication.
> 
> > There already is a public key authentication mechanism in 
> iSCSI.  I think
> > this is all that is required.
> 
> The text describing this in the -03 version of the draft needs some
> significant work.
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>