Re: [storm] [kitten] Kerberos Considerations for iSCSI Authentication

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

Nico,

Thank you for the prompt and useful review.

Comments inline ...

Thanks,
--David

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

I'm afraid so ... sorry.

> > ------------------
> >
> > 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.
> 
> 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.
 
> > 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]:
> 
> The first sentence of the above para says nothing to me :(  Remove it?
> 

Sure.

> >           - 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
> 
> 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.

> > As Kerberos V5 is capable of providing mutual authentication, implementations
> > SHOULD support mutual authentication by default for login authentication.
> 
> 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 :-).

> > 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.
> 
> 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
> --