[storm] Kerberos Considerations for iSCSI Authentication

["Black, David" <[e-mail]>]

The storm WG's consolidated iSCSI draft (draft-ietf-storm-iscsi-cons-08)
has a few issues from IESG evaluation that need attention, one of which
is that some security considerations text for Kerberos needs to be added.
I don't know of any Kerberos authentication for iSCSI that's currently in
use, although it has been implemented at least once, and hence the
decision has been made to retain its specification as part of the iSCSI
protocol update in this draft.

I'd appreciate comments on the following text, and please at least cc:
me (preferably also the storm mailing list).  Note that KRB_AP_REQ
and KRB_AP_REP are the client message and server's response message
as defined in RFC 4120.

I do want to head off one area of comments - please send any "you
should use GSS-API" comments to /dev/null.  iSCSI was specified to use
Kerberos w/o GSS-API a long time ago, so GSS-API for iSCSI would be a
new iSCSI authentication mechanism that should be in a separate draft,
as opposed to this update (which is already long enough).

------------------

9.2.3 Kerberos Considerations for iSCSI Authentication
 
iSCSI uses Kerberos via "bare" tokens - i.e. does not use GSS-API ([RFC4121]) -
for authenticating the two Kerberos principals during the iSCSI Login process.
This implies that iSCSI implementations supporting the KRB5 AuthMethod
(Section 12.1) are directly involved in the Kerberos protocol. Specifically,
the following actions MUST be performed as specified in [RFC4120]:

          - Target MUST validate the KRB_AP_REQ to ensure that the
			initiator can be trusted
          - When mutual authentication is selected, the initiator
			MUST validate KRB_AP_REP

to determine the outcome of mutual authentication
 
As Kerberos V5 is capable of providing mutual authentication, implementations
SHOULD support mutual authentication by default for login authentication.
Note however that Kerberos authentication only assures that the server
(iSCSI target) can be trusted by the Kerberos client (initiator) and
vice-versa; an initiator should employ appropriately secured service
discovery techniques (e.g. iSNS, Section 4.2.7) to ensure that it is
talking to the intended target principal.

------------------

Thanks,
--David (storm WG co-chair)
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
[phone]             FAX: [phone]
[e-mail]        Mobile: [phone]
----------------------------------------------------