Subject: iSCSI authentication requirements

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 26 Mar 2002 13:03:11 -0800

In order to move forward on selecting an alternative mandatory iSCSI login 
authentication method, it is important to understand what the requirements 
are. I would like to suggest that the following requirements are essential:

a. Mutual authentication
b. Pre-shared key support with sufficient key size (e.g. 128 bits)
c. Resistance to man-in-the-middle attack

On the other hand, I would argue that the following requirements are *not* 
important:

d. Resistance to hijacking
e. Dictionary attack resistance
f. Support for certificate authentication

Goals

Mutual authentication is important so that not only can the iSCSI Target 
authenticate the Initiator, but also the Initiator can authenticate the 
Target. The ability to detect a rogue Target is important, especially since 
iSCSI can be used for booting and rogue Targets could fools Initiators into 
making use of bogus data. The ability of the Target to authenticate the 
Initiator is important so that the Target can control access.

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.

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.

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.

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.

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.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

---

From: David Jablon <[email-masked]>
Date: Wed, 27 Mar 2002 15:42:55 -0500

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

---

From: Theodore Tso <[email-masked]>
Date: Wed, 27 Mar 2002 22:57:32 -0500

> item (e), preventing "dictionary attack", is important.

We need to be a bit more nuanced here.  The question is not just
whether or not a particular scheme is vulnerable to a dictionary
attack, but under what circumstances is it vulnerable to a dictionary
attack.  If the attack requires the use of an active attack, where the
attacker has to be on communications path, *and* the attacker must
interpose him/herself between the client and the server, *and* the
attack causes the attempted authentication to fail, such that the
client knows something might be going on --- how bad is it that under
these sorts of circumstances, a dictionary attack might be possible?

Also, if we posit that the authentication target has a public key,
which can be optionally cached by the client (in an ssh-style type
approach), then the server can sign its challenge with its public key,
and then even the possibility of an active attack is limited to the
first time the client talks to a particular server or iSCSI target.

Is this as good as an EKE, SPEKE, or PDM-style authentication scheme?
Nope; but it's close.  And as I articulated during the IETF
open-plenary, we are an engineering organization, and engineering
always involves tradeoffs.  Some of these tradeoffs are not
necessarily strictly technical, but involve real-world
business/financial issues.

The problem at this point is that the IP situation with respect to all
of these schemes is cloudy, and that may prevent some companies from
being able to implement the spec.  Also, if any of these patent claims
are true, then it certainly will rule out open-source, reference
implementations from being able to fully implement the specification.
Such reference implementations have for other working groups been a
significant force towards helping assure interoperability.  (Also,
consider that as Linux continues to make inroads into the server
platforms, it would be a real shame if Linux were not able to make
authenticated connections to iSCSI devices thanks to the patent
issues; you'd be essentially eliminating part of the iSCSI device
manufacturers' market thanks to the patent issue.)

How important are these issues?  Well, I will be the first to admit
that if some patented technology conferred overwhelming advantage over
all other alternatives (such as back in the bad old days when RSA and
D-H was the only game in town for doing public-key cryptography), then
the concerns which I've articulated probably would not outweigh the
technical advantage conferred by the IP-encumbered technology.  (And
even in that case, the fact that the technology was encumbered
probably delayed the wide-spread use of protocols which specified the
use of public-key technology by close to a decade.)

In this particular case, however, I would submit that the advantage
confered by using EKE, SPEKE, PDM, or other related technologies is at
best marginal.  There are other technical solutions, which I've
outlined above, that provide almost the same amount of protection,
without having to deal with the headaches of settling with potentially
two or three patent holders.  We also avoid eliminating at one stroke
all possibilities of compliant/legal open-source implementations of
the technology.  Because of both downsides, in this particular case,
the engineering tradeoffs simply isn't worth it.

							- Ted

---

From: David Jablon <[email-masked]>
Date: Thu, 28 Mar 2002 20:13:42 -0500

Ted,

>> item (e), preventing "dictionary attack", is important.

Your thoughtful, rather lengthy reply warrants a response.

I feel it is necessary for me to point out where exaggeration
invalidates your argument and is also damaging to the process
of arriving at a consensus on the best all-around solution.
I will clarify these points here.

>these sorts of circumstances, a dictionary attack might be possible?

Ok.  On the one hand, you sure do make that attack sound hard.
But stated in other words, an attacker can inject just a couple
bogus packets, a mere hiccup from the user's view, and then he
gets unlimited offline guessing to crack the password.  Some
might consider that a *bad thing* indeed.

>first time the client talks to a particular server or iSCSI target.

Sure, posit that.  Strong password methods work well for securing
initial connections, or generally in remote retrieval of data when a
local credential cache has been cleared or needs updating.
If this standard used SSH, or proposed such caching, then, I'd argue,
a person should use a strong password method to protect that
initial connection.

Furthermore, limiting the attack window to *just* the first time may
not significantly decrease the problem.  It depends on other
assumptions.  In some cases it may be like locking all but one door
of your house.  A good burglar will try them all, or wait for the
appropriate time, etc.  In contrast, a strong password method closes
all these doors to offline cracking of network messages, forcing the
burglar to try something different.

>business/financial issues.

I do love those "real-world" arguments, implying that the opponent
is living on some other planet. So, for the record, I, also an Earthling,
believe that these tradeoffs must be made. Let's start:

        Is it OK for proposal X to allow active attack?

        Is it OK for proposal Y to allows both passive and active
        attack, perhaps in the theory that people or applications that
        use passwords as keys deserve to be hacked?

        Do Z, W, U, and V really work as advertised in preventing both
        active and passive attacks, and if so how much is it worth?

        Are X or Y truly less encumbered than the others, and if so,
        is this fact significant?  For example, has the WG established
        that costs would likely be onerous for anyone who implements
        any of the others?

I have no problem in letting the WG decide these things.

But the IETF *cannot* make proper business/engineering tradeoffs
by political fiat.  As an organization, the IETF cannot investigate pricing
or license policies.  And no decree from on high can take into
consideration the concerns or nuances of each specific application.
This is a job that must be done by individual WG members.
And they should not be discouraged or preempted from doing that job.

>being able to implement the spec.  ...

No, the IP situation is very clear for several of the patented schemes.

>... Also, if any of these patent claims
>significant force towards helping assure interoperability. ...

That is false.  Open source and reference implementations are
no problem per-se for patented techniques.  Open source at a basic
level relates to copyright protection, not patents. And there are
several examples of open source software for patented methods.

>... (Also,

Again, this is false.  Even that last requirement can be met.
While it is true that free use and distribution products like Linux
can pose a different problem for a patent holder, it is surmountable.
And finally, as you almost point out, all these interoperability
problems go away when a patented technique is standardized as
a SHOULD implement method.

>use of public-key technology by close to a decade.)

First, you'll forgive me if I doubt that you'd be the *first* to
stand in line to use anybody's patent.  Let's be honest.
I do appreciate your role here.  Unnecessary encumbrances should be
discouraged.  So, in this case, why not lighten up on the preaching
and exaggeration, state the IETF policy, or, as you see it, the
general-but-unwritten IETF philosophy, and let people determine for
themselves how easy or hard it is to use such methods.  And if a
patented technique is still acceptable to the group, then so be it.

>two or three patent holders. . . .

Again, why exaggerate?  Anyone who properly investigates this field can
find out that, for several methods, there is exactly one patent holder, and
among these there is a clear and free choice of more than one such holder.
It is also obvious that different people have different views on the
significance of the technical benefits, and this is clearly a factor
in establishing a fair price.

>... We also avoid eliminating at one stroke

I'll argue the reverse.  With your "one stroke", you might prevent all
possibility of anyone benefitting from an entire class of technology.
THAT seems to be the bigger threat.

 From here on down, I feel compelled to make some philosophical points,
so readers purely focused on iSCSI should feel free to skip to the last
couple paragraphs, if indeed, you've held on this long.

Ted, I have no problem with your concerns, your *personal* philosophy,
or even the longstanding IETF tradition to prefer unpatented technology
to any *equivalent* patented technology.  I also have no problem with
you trying to focus on the need for these methods in specific narrow
times and places (which, incidently, sound like fine bargaining points
to negotiate a lower price).

But here's where I do see some big problems, only some of which are
actually contained in your message:

* I disagree with the somewhat arbitrary line you've drawn between active
and passive attacks.  It seems contrived to fit your agenda.

* I disagree with the concept of making *uninformed* business/engineering
tradeoffs.

* I disagree with idea of retrofitting requirements to fit certain methods,
which I believe that some people are trying to do.

* I think it's up to the working group members to decide what technology is
truly equivalent to an optimal case for its purposes, without undue pressure
or interference from "outsiders" (including me too of course).

* I object to the idea of IETF watchdogs too-closely directing actions of a
working group, or discouraging them, especially using false statements,
from properly investigating relevant technical and business
issues to be able to make the necessary tradeoffs.

* I believe it is wrong for all IETF participants to promote an unwritten
extremist anti-patent agenda onto others in this or any working group.
I think that you, and others, should simply stop encouraging exaggerated
fears in this regard.

Patent infringement is not some criminal thing, like oh, say, a copyright
violation.  You can't go to jail over a patent.  The worst that might
happen is that a truly extreme infringer who gets caught might overpay.
In a majority of day-to-day cases of people using other people's patents,
nobody takes any real action or pays anything.  In this specific field there
is no monopoly position blocking this class of technology.  And if in the
worst case, should some patent holder abuse it's power and position,
the process is ultimately self-correcting as you yourself have argued.

Let's keep this in perspective.

The problem is that actions like yours may prevent people from being
able to obtain the benefits in the first place.  Using IETF standards are
important, and standardization is required for some people to invest in
using a technology.  No standards organization should create a blockade
to the legitimate use of any general class of patented technology.

And, for those people who have an inordinate fear that the mere mention in
an IETF standard of some patented technique will somehow establish a
huge business monopoly of some sort, all I can say is come back to Earth.
These documents don't have *that* much power.  The existence of a
standard doesn't compel any vendor to have to implement every little
thing in it, especially when there are alternatives.
People can always pick and choose what they want to implement,
based on value and price.  There are no standards-compliance
police twisting peoples arms.  It just doesn't work that way.

In the context of this working group, it appears to me that forces have
gathered to try to downgrade a MUST-implement security method to a MAY,
or to do away with it entirely, and in this process are retroactively adjusting
the requirements to fit certain techniques.  That this may be done without
full investigation of the actual cost of the tradeoff from a business
perspective, and with only hasty discussion of the technically equivalent
methods, as well as other non-equivalent tradeoffs, seems wrong to me.

The general practice of *avoiding* patents at any cost is damaging
to patent holders, and to the world at large.  Such a practice is forbidden
in other standards organizations, for these reasons.

Yes, we all know that IETF is a *different kind* of standards body.
I just think that you're promoting a too-extreme position in this regard.

All of this discussion may be premature, as I'm not absolutely sure that
password-based authentication was the real goal here.  I think there's good
evidence that this was indeed the case, after all, if not, then why SRP?
Yet, I believe that some participants may be afraid of the consequences
of speaking up, even to just discuss technical issues, for fear of violating
the default IETF religion. That is not a good thing.

If one of the goals here is to allow people to use passwords to authenticate
the establishment of these device connections, then I think there are many
paths to an optimal engineering solution.

If not a MUST, then why not a SHOULD for some variant of EKE, SPEKE, SRP, 
or an equivalent?

How about asking a vendor to back up their claim of being able to provide
this freely to all, as was suggested in Minneapolis?

Why not ask if people have ever had trouble licensing these schemes on
reasonable terms from any available sources?

I see several paths that can result in wide-scale deployment of optimally
engineered solutions here.  And where there are real (or "real-world")
requirements for strong password methods, I will do my best to get my
company to assist in this process.

-- David

---

From: Theodore Tso <[email-masked]>
Date: Thu, 28 Mar 2002 19:15:36 -0500

> might consider that a *bad thing* indeed.

Nope, not that easy.  As I said, the attacker has to be on the network
communications path between the client and the server.  Also, the
attacker has to prevent the original packets from the client to the
server from getting through.  This is not necessarily trivial --- it's
*not* just a matter of "injecting a few bogus packets".

> burglar to try something different.

Again, nope.  It's like saying that while the house is being built,
there is a small window when the deadbolt hasn't been installed yet.
But once the deadbolt has been installed, the burgler can't get in.

Given the usage patterns of clients talking to disks, most of the time
you're talking the same disk where you had previously stored data.  So
most of the time, it's *not* the first time a client is talking to a
disk, and by definition, that vulnerability only happens once.  For
that reason, limiting the vulnerability to an active attack during the
initial attack window is quite significant.

Also, note that if the public key of the server is (optionally)
certified by some well-known CA, then even the initial attack window
(if people think it's important) can be avoided.  And if you think
that's impractical, note that significant amounts of e-commerce is
done using precisely level of protection.

> a SHOULD implement method.

Nope.  Security mechanisms have to be a MUST implement.  If we have a
non-encumbered MUST implement mechanism, then whether or not we have
an encumbered SHOULD mechanism at some level is less important.  Most
people will probably depend on the MUST implement for
interoperability.  So then, people will only pay whever are costs (in
money, legal uncertainty, etc.) for using said encumbered technology
if said encumbered technology really provides enough value that it's
worth the cost.

In some sense, this might be the best result.  As I said, it really is
all about engineering tradeoffs.  Are the benefits worth the costs?
If there is a MUST implement which is unencumbered, then instead of
arguing about the relative costs and benefits, vendors will be able to
decide for themselves whether or not it's worth it to trade in the
encumbered technology.

> * I disagree with the concept of making *uninformed* business/engineering

Ultimately, we always have to make decisions based partial
information.  There have been cases where a patent holder has
publically stated during the standardization process that the patent
will be free for people implementing the specific protcol, in that
case, the working group can make decisions based on that knowledge.

But if the statement which is made is only the stock "reasonable and
non-discriminatory", that can mean many things.  It can mean a no-cost
license, or it could mean "everyone gets to pay $10 million dollars",
where while the terms might be non-discriminatory, it could lock out
all but the largest companies, which many would say is a Bad Thing.

But just because we don't know doesn't mean that we should freeze and
not make any decision.  At the same time, we can't assume that
companies will be utterly benign with their patent licensing policies.
All we can do is make the best possible decision we can based on the
information we have.  And that's something that we always have to do,
no matter what the field of endeavor.

> or interference from "outsiders" (including me too of course).

The security area of the IETF, and the security AD's of the IESG are
not "outsiders".  They are part of the IETF community.  And the IETF
community *has* made some global decisions for the entire IETF.  For
example, in the past, the IETF as a whole had decided that despite
export control regulations, strong cryptography would be required,
despite the desires of some working groups, which were dominated by
vendors who were motivated by a desire to ship products that could be
exported outside of the U.S.  The general policy that strong
cryptography would be required for all working groups, despite any
nation's export control policy was termed the "Danvers Doctrine", from
the IETF plenary meeting in Danvers, Massachusetts, where it was clear
this consensus was reached.

More recently, the IETF decided that standardizing wiretap-friendly
provisions into protocols was bad from an engineering standpoint, and
so this was something that the IETF would not engage in.

So there is in fact a rich history of the IETF community as a whole
(and not just an individual working group) making statements which
take into account the entire Internet community, sometimes to the
frustration of parties whose priorities are solely based on monetary
motivations, or by people who only care about law enforcement's
concerns.  Personally, I believe this is a Good Thing.

						- Ted

P.S.  I will note that in the case of public key technology, it seems
pretty clear that the patent issue very much did inhibit its
deployment.  Most recently at this Minneapolis IETF meeting, we
enjoyed the integration of dynamic DNS updates and DHCP, which
involved the use of public key technology.  The standards involved
were developed while the RSA patent was in force, but in fact,
widespread deployment of RSA technology in IETF protocols really
didn't happen before the RSA patent expired.  And at this Minneapolis
IETF meeting, the dynamic DNS update demonstration was spearheaded by
open source implementations: the ISC dhcp server, the ISC dhcp server,
and ISC BIND implementation were all involved.  None of these open
source implementations could have used the RSA technology while the
patent was still in force.

Make no mistake.  Patents have their costs.  If you want your protocol
to be widely deployed across the Internet, use of patented technology
(unless that patent has been freely licensed) has historically been a
strike against your protocol.

---

From: David Jablon <[email-masked]>
Date: Sat, 30 Mar 2002 16:25:43 -0500

Ted, on some relevant points, I think we may be closer to
agreement than you think, for example, I think we could probably
tweak the following into a mutually agreeable form:

1)  A MUST implement CHAP-based method would surely promote
free interoperability for all, with security for some.

2)  A SHOULD implement method in the SRP category would permit 
implementors the opportunity to make an engineering/business tradeoff,
and if desired, to use a method optimally resistant to dictionary attack,
with a chance for widespread interoperability in this regard too.

I think there are clearly ways that the standard can let people
pay "whatever they think it's worth", as you've characterized it,
to use a method like SRP, and still maximize interoperability
among applications that use either that approach or a
guaranteed-free but not-equivalent alternative.

The next job would seem to be to insure that the SRP-like option
is specified in a way that makes a decision to use it as easy
and as inexpensive as possible.

I'll respond below to some points where we have had or may
still have disagreement,

At 07:15 PM 3/28/02 -0500, Theodore Tso wrote:
>> [...] But stated in other words, an attacker can inject just a couple
>> gets unlimited offline guessing to crack the password [...]
>
>Nope, not that easy.  As I said, [...] This is not necessarily trivial --- it's

In order for either of us to prove our points, someone has to specify the
exact protocol you've been thinking about. Maybe it's not exactly the
EZ-to-crack thing I was thinking of.  SRP and well-known equivalents
are established protocols that have survived years of public scrutiny.
But I'll be glad to to spend a few minutes looking at the new proposal
when it's ready.  ;-)

>> of your house.  [...]
>But once the deadbolt has been installed, the burgler can't get in. [...]

That "nope" is not so well supported.  Essentially, I think you've argued
that you know how the application can be built and is likely to be used
in a way that greatly reduces this window of vulnerability, so therefore
everything is A-OK.

But I think the real test is in how applications interpret the standard,
and how people use those applications, and it seems pretty early to
know that, and therefore hard to predict how big that "window" might be.

In getting rid of that window entirely, one reduces the risk of failure
due to unanticipated application and user behavior, which can't be
easily specified.

>> And finally, as you almost point out, all these [freeware] interoperability
>an encumbered SHOULD mechanism at some level is less important. ...

That "Nope" is inappropriate.  I was arguing almost the same point.

One difference is that I think at least a SHOULD for something like SRP
is still important, since before all the IP rumors, people thought it was
a MUST.  Anything less seems like a downgrade.

Yet, another possibility to fit your original point, is for a MUST SRP and
MUST CHAP standard.  Everything that implements the standard is 
interoperable, and it still allows for (somewhat-non-compliant) freeware
implementations that fully interoperate with all standard ones.
(Yes. I know. This is surely politically incorrect.)

But I also wonder if the interoperable freeware debate is based on the
assumption that there are no other IP encumbrances on this standard,
which seems like it might be an open question.  If there are other
encumbrances, discussion about freeware may be irrelevant.

> ... Most
>interoperability.

I'd rather not debate predictions.  We clearly agree that a MUST
method provides a baseline for interoperability.

>... So then, people will only pay whever are costs (in

That sounds reasonable to me.  People can pay what they think it's worth.

>community *has* made some global decisions for the entire IETF. ...

Ok.  There are definitely legitimate reasons for global decisions to be
made in the IETF.  You cited some great examples involving
governmental entanglements.

My point is that it seems to be a very bad thing for the IETF to start
making global top-down decisions about specific competing technologies
that merely involve business/engineering tradeoffs. I think we're talking
about the difference between a light hand and a heavy hand.

A relevant sentence in RFC2026, 10.3.2:
  "(B)  The IESG disclaims any responsibility for identifying the
      existence of or for evaluating the applicability of any claimed
      copyrights, patents, patent applications, or other rights in the
      fulfilling of the its obligations under (A), and will take no
      position on the validity or scope of any such rights."

In the act of proposing specific alternative technology to avoid
specific patents, there is at least the appearance that the IESG
is indeed taking on this responsibility.  And it certainly seems
to be "taking a position" here.

>PS.

P.S.
If by "you" and "your", you mean me and mine, I object to personalizing
the debate. I think we all know that I invented one of the contenders.
Otherwise, if you were just using the "royal you", please don't. Thanks.