Subject: [storm] Kerberos Considerations for iSCSI Authentication

From: "Black, David" <[email-masked]>
Date: Wed, 29 May 2013 10:43:04 -0400

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
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Black, David" <[email-masked]>
Date: Wed, 29 May 2013 20:18:33 -0400

Nico,

Thank you for the prompt and useful review.

Comments inline ...

Thanks,
--David

> -----Original Message-----
> From: Nico Williams [mailto:[email-masked]]
> Sent: Wednesday, May 29, 2013 4:16 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> Subject: Re: [kitten] Kerberos Considerations for iSCSI Authentication
> 
> On Wed, May 29, 2013 at 9:43 AM, Black, David <[email-masked]> wrote:
> Other comments to head off:
> 
>  - Kerberos <-> IPsec binding?  never mind; we failed to get uptake on RFC5660.

I'm afraid so ... sorry.

> s/tokens/PDUs/  (and define the term: Protocol Data Unit).  Or better:
> 
> NEW:
>    iSCSI uses raw Kerberos V5 [RFC4120] for authenticating a client
> (iSCSI initiator) principal to a service (iSCSI target) principal.
> Note that iSCSI does not use the Generic Security Services Application
> Programming Interface (GSS-API) [RFC2743] nor the Kerberos V5 GSS-API
> security mechanism [RFC4121].

+1 on the new text - we'll take it.
 
> The first sentence of the above para says nothing to me :(  Remove it?
> 

Sure.

> Yes.  (Assuming there's text elsewhere saying that these PDUs have to
> be sent and received in order to validate them :)

Yes, there is, and we'll double-check.

> Is there a reason not to make this a MUST?

Yes, a lot of deployed iSCSI authentication is one-way - initiators (host)
authenticate to targets (storage), but not vice-versa; forcing defaults
to never match common usage has some analogies to trying to teach a pig
to sing ... one gets no music and only succeeds in annoying the pig :-).

> Some text somewhere should note that Kerberos is not used to provide
> integrity nor confidentiality protection to the iSCSI protocol (and
> that only IPsec does, and so on).

Sure, good suggestion, we'll add a sentence to that effect.

> Nico
> --

---

From: Nico Williams <[email-masked]>
Date: Wed, 29 May 2013 15:15:32 -0500

> as opposed to this update (which is already long enough).

Other comments to head of:

 - Kebreros <-> IPsec binding?  never mind; we failed to get uptake on RFC5660.

NEW:

Nico
--