2002 - cesnet

16.3.1 No SecurityThe initiator is not authenticated and transferred data and commands are notencrypted in this mode. This approach can only be applied in situations wherepotential security risks are minimal and configuration flaws are not likely.16.3.2 Initiator–Target AuthenticationIn this mode, the target authenticates the initiator (or/and vice versa). This approachprevents unauthorized access to data spaces by faking the identity ofthe initiator (spoofing). After completing the authentication process, all othercommands and data are sent in an unencrypted form. This method can be usedonly if man-in-the-middle attacks, wiretapping, and modifications of data sentare excluded.The iSCSI draft (see [SSC02] and [ATW02]) assumes authentication forms inaccordance with table 16.4.KRB5SPKM1SPKM2SRPCHAPNoneKerberos V5Simple public-key generic security service (GSS),application programming interface (API) mechanismSimple public-key GSS API mechanismSecure Remote PasswordChallenge Handshake Authentication ProtocolNo authenticationTable 16.4: Available iSCSI authentication types16.3.3 Authentication and EncryptionWithin this solution, the authentication is secured using one of the previouslymentioned mechanisms and the data transfer security is maintained with theencryption on the IP level.From the viewpoint of the draft, a device is considered iSCSI-compatible if it hasthe IPSec support implemented. With respect to the demands for bandwidthand relating difficulties within the encryption, the draft permits the IPSec implementationin a front-end device. The pair of devices (iSCSI router and the IPSecdevice) is then considered to be a device complying with the draft requirements.None of the tested devices had the IPSec technology implemented.Linux: Authentication using a locally defined list of initiators, CHAP protocol.High-speed National Research Network and its New Applications 2002181