[storm] Kerberos Considerations for iSCSI Authentication

"Black, David" <david.black@emc.com> Wed, 29 May 2013 14:43 UTC

Return-Path: <david.black@emc.com>
X-Original-To: storm@ietfa.amsl.com
Delivered-To: storm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2F51E21F9007; Wed, 29 May 2013 07:43:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7J-yaSf0WNTd; Wed, 29 May 2013 07:43:45 -0700 (PDT)
Received: from mexforward.lss.emc.com (hop-nat-141.emc.com []) by ietfa.amsl.com (Postfix) with ESMTP id D909321F8D31; Wed, 29 May 2013 07:43:39 -0700 (PDT)
Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEhRAi023690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 May 2013 10:43:38 -0400
Received: from mailhub.lss.emc.com (mailhubhoprd05.lss.emc.com []) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Wed, 29 May 2013 10:43:07 -0400
Received: from mxhub05.corp.emc.com (mxhub05.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id r4TEh6qB008150; Wed, 29 May 2013 10:43:06 -0400
Received: from mx15a.corp.emc.com ([]) by mxhub05.corp.emc.com ([]) with mapi; Wed, 29 May 2013 10:43:05 -0400
From: "Black, David" <david.black@emc.com>
To: "kitten@ietf.org" <kitten@ietf.org>
Date: Wed, 29 May 2013 10:43:04 -0400
Thread-Topic: Kerberos Considerations for iSCSI Authentication
Thread-Index: Ac5cetOj5lUqLotRRMCSm1pg3XhHmw==
Message-ID: <8D3D17ACE214DC429325B2B98F3AE71296A3C67D@MX15A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "storm@ietf.org" <storm@ietf.org>
Subject: [storm] Kerberos Considerations for iSCSI Authentication
X-BeenThere: storm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Storage Maintenance WG <storm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/storm>, <mailto:storm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/storm>
List-Post: <mailto:storm@ietf.org>
List-Help: <mailto:storm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/storm>, <mailto:storm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 14:43:51 -0000

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.


--David (storm WG co-chair)
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754