Re: iSCSI authentication requirements

[David Jablon <dpj@theworld.com>]

A primary decision for the WG to consider is whether
item (e), preventing "dictionary attack", is important.

To determine this, some basic questions come to mind, that the
WG needs to answer.

-- How are login authenticators intended to be distributed?
-- Are people ever in the loop?
-- If so, where, when, and how are they likely to handle these authenticators?
-- If not, then what kind of automated key selection and distribution
        system can be expected or mandated to be used?

Other comments are embedded below.

At 01:03 PM 3/26/02 -0800, Bernard Aboba wrote:
>...
>e. Dictionary attack resistance
>...
>Goals
>...
>Pre-shared key support is important since this is likely to be the most common use of iSCSI login authentication. The pre-shared key should be unique to the two parties, and not suceptible to man-in-the-middle attack, as opposed to the Group Pre-Shared key that is so widely implemented within IPsec VPN clients, and that enables man-in-the-middle vulnerabilties. Sufficient entropy is required to avoid brute-force attacks.

If the use of pre-shared key authenticators is the desired goal, then it should
openly state that "all compliant applications must enforce machine-generated
of high-quality keys, and preclude the use of passwords or hashed
passwords directly as keys".  Otherwise it will lead to the same kind of
false-advertising problems that have plagued other standards.

On the other hand, if pre-shared password authenticators is a common use
case, whether or not it's the dominant case, this naturally imposes more
stringent requirements than "pre-shared key".

>Non-goals
>
>iSCSI login authentication can be used with or without IPsec. When IPsec is not used, the iSCSI connection can be hijacked, but this is not something that login authentication can protect against.

Goal (d) should be restated as "resistance to session hijacking".
Strong authentication protocols can defend against "hijacking" of the secret
credentials themselves, whereas other protocols may not.

>One of the reasons that SRP was chosen was its resistant to dictionary attack when weak secrets are used. However, it is not clear that this is useful functionality for iSCSI login authentication.
>
>Mounting iSCSI volumes is inherently a machine activity, since access to that volume, when mounted, is determined by the operating system and its access controls rather than security services within the wire protocol.
>
>As a result, the credentials used for iSCSI login may be machine credentials, which can be assumed to be pre-shared keys with significant entropy, rather than a user password.

Those three paragraphs make one point -- that passwords are not needed
when machines will always choose and distribute these keys,
with no human involvement.

Q for the WG:  Can this be true for all compliant products?

>The once scenario in which a user password might be relevant is mounting an iSCSI volume via a storage service provider. However, this is exactly the scenario in which IPsec protection of iSCSI would be most likely. Therefore, I would claim that dictionary attack resistance is not important here either.

I don't understand that argument. What distinction is being drawn here
for use vs. non-use of IPsec?  And why are passwords relevant in that
scenario, but not others?

>If certificate authentication is possible and desired, this can be provided within IKE Main Mode. As a result, certificate-based authentication is not required within iSCSI login.

-- David