Subject: RE: Security Use Requirements

From: [email-masked]
Date: Tue, 6 Feb 2001 08:54:03 +0200

Bernard,

The enquiry David took upon himself to make is that if we have a strong
requirement to have digests that include authentication and integrity as a
minimal requirement or if we could work with a sequence (listed here in
order "increasing" integrity/security) that looks like:

1-none
2-data integrity(CRC) and/or authentication of the parties at session start
3-full security through TLS and transport-IPSec

The answer to this seems to be (as we expected) that as long as the
negotiation is done in a proper way eliminating the possibility of getting
drawn down to a weak security scheme when at least one of the parties wants
a higher level we can go with the outlined sequence of schemes.

The additional point we will have to ponder is where we want to draw the
line for a "minimal compliant" iSCSI.  The current (true for June 2000)
consensus between the authors was "implementation - somewhere within 2 and
deployment at 1" - with CRCs mandatory to implement (optional to use) and
all the rest is optional to use and implement.

Considering the spectrum of devices and applications for iSCSI I think that
this is a reasonable choice.

Regards,
Julo

"Bernard Aboba" <[email-masked]> on 06/02/2001 01:26:13

Please respond to "Bernard Aboba" <[email-masked]>

To:   [email-masked], [email-masked]
cc:   "RJ Atkinson" <[email-masked]>, "Smb@Research. Att. Com"
      <[email-masked]>
Subject:  RE: Security Use Requirements

It is hard for me to see how you could
get away with no security services at all
(e.g. no per-packet authentication and integrity
protection for iSCSI PDUs).

After all, we're talking about facilities
that are used by the world's major financial
institutions. If this data isn't worth protecting,
I don't know what is. Do you really want
attackers to be able to manipulate the contents
of bank accounts at will over the Internet?

Furthermore, there really isn't a sound technical
argument for dispensing with security. There are
chipsets available that can provide IPSEC
integrity and authentication services at
speeds of 1 Gbps or higher.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Monday, February 05, 2001 12:54 PM
To: [email-masked]
Subject: Security Use Requirements

In Orlando, I picked up an action item to determine what
the requirements are for *use* of security features,
as opposed to requirements for *implementation*.  I
believe the answer to be that it is acceptable to
specify security measures weaker than those one would
want to use in full generality on a public network,
where "weaker" includes no security.

There are two important caveats that apply:
- Security of the negotiation mechanism becomes
     very important when this is done, as there's
     an obvious man-in-the-middle attack on the
     negotiation mechanism to get the endpoints
     to negotiate weaker security than they intended.
- The weaker security mechanisms need to be documented
     in terms of their security properties (and lack
     thereof), as well as environments in which they
     are appropriate.  The "Security Considerations"
     section of RFC 2338 (VRRP) has been recommended
     as a good example of this.

--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Tue, 6 Feb 2001 05:52:52 -0800 (GMT-0800)

> all the rest is optional to use and implement.

CRCs only provide integrity protection, but not authentication since they 
are not keyed. Thus, it provides no protection against spoofing 
attacks. Even if the CRC is non-linear, it is not hard to build 
a device that will change packets on the fly without fear of detection. The 
TCP checksum is non-linear but it can be guessed right about half the 
time. 

An example of the kinds of attacks that are possible is found at:
http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html. I'm sure the
folks at Berkeley will be happy to provide an equivalent analysis for
iSCSI. 

Do you really want to enable attackers to insert or change data destined 
a SAN disk at will? Even if the iSCSI SAN is using linklocal addressing, 
and therefore is not accessible from the Internet, there is still risk from 
internal attack. 

A more reasonable approach would be to require at least authentication 
and integrity protection (e.g. IPSEC AH or ESP null).

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 6 Feb 2001 13:21:14 -0800

>Both IPSec and TLS will be in the standard.   

Including *both* IPSEC and TLS as options will probably result
in both much higher cost to customers as well as fewer vendors
implementing either. Choosing one or the other (IPSEC is my 
preference) would be a better choice.

In general, it is a bad idea to have too many security options in
a standard. Options are bad because you have to implement them
to be able to interoperate with those people who do, yet you cannot
guarantee that the work will be used. In particular, including both
IPSEC and TLS would cause vendors to try to implement both on
the same NIC, since they could never be sure which security scheme
would be used on a given iSCSI target. This would drive up the cost 
enormously since the acceleration architectures are very different 
between the protocols. 

>As we are talking about speeds that will be in excess of 1GBs 
>even on modest disk controllers we were all hesitant if to make 
>anything in this category mandatory to implement today.

As Ran noted, making implementation mandatory doesn't mean that
users have to turn it on. But not making it mandatory will probably
ensure that security will not be available in most cases. Given
the modest cost of adding IPSEC acceleration hardware (today
IPSEC accelerated NICs are available for around $100) it is hard
to see how this would be a worthwhile tradeoff. 

Right now, SSL/TLS acceleration hardware is a lot more expensive than
IPSEC accelerators (at least $2000), so I could understand if SSL/TLS
were left out of the standard.

>We assume that all those who require security beyond CRC 

CRC provides only integrity protection, but since it is not keyed,
there is no per-packet authentication or protection against spoofing
or modification. CRC therefore has little or no security value. 

> session authentication 

All session authentication does is guarantee the user identity
at the beginning of the session. Unless you have per-packet
authentication and integrity protection, all bets are off after
that. In particular, session authentication provides no protection
against TCP session hijacking. 

>However those that build a Storage Area Newtork within a 
>small enterprise completely isolated from the
>internet will not have to pay for what they do not need.

Actually, the decision made above will guarantee that all users
will need to pay a huge incremental cost for security, because
of the over abundance of security options. In reality, given the
projected cost of 1+ Gbps iSCSI accelerated adapters, the incremetal 
cost of implementing IPSEC security would be minimal.

---

From: Joshua Tseng <[email-masked]>
Date: Tue, 6 Feb 2001 17:22:46 -0800

David,

Question:  Does your "mandatory-to-implement" mean
"mandatory-to-implement-on-the-same-box", or 
"mandatory-to-implement-on-the-same-or-different-box"?

:-)

IPSec security gateways are widely available now, from
many different vendors.  Are you ruling out their use
to fulfill the security requirement?

Josh

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, February 06, 2001 3:32 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Some related clarifications:
> 
> >         I suspect that failing to make security mandatory-to-
> > implement will tend to prevent the specification(s) from 
> > ever becoming IETF standards-track RFC(s).  However, the WG
> > can certainly *try* to slide by.
> 
> My original post was about mandatory-to-use, NOT
> mandatory-to-implement.  As for making security not
> mandatory-to-implement ... NOT on my watch ... and
> remember that Steve Bellovin is one of the ips WG
> co-chairs, making me a "good cop" by comparison on
> this sort of issue ;-).
> 
> >         Another customary IETF position is to work on the basis that
> > all IETF protocols are likely (in practice) to be deployed over
> > The Global Internet.  So the threat model discussions normally
> > MUST include those kind of threats and can't be limited to threats 
> > on a private intranet.
> 
> That is also correct ... and I say that with my WG co-chair
> hat firmly in place.  There is also language to this
> effect in the ips WG charter.
> 
> It's unfortunate that Julian focussed only on integrity
> in his response.  Going back to the Pittsburgh (summer
> 2000) minutes, secure authentication will be mandatory to
> implement ... so sayeth the AD.  I also believe that some
> form of cryptographically authenticated integrity will
> likewise be mandatory to implement (otherwise it's too
> easy to hijack an authenticated connection).  This means
> signed cryptographic checksums, not just CRCs (as Bernard
> explained).  OTOH, it's not clear that confidentiality
> will be mandatory to implement.
> 
> The whole point on mandatory-to-implement vs. mandatory-to-use
> is to adapt available security technologies to the circumstances.
> One simple example is that confidentiality is NOT mandatory-to-use
> in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone
> who uses that comment as a jumping off point to open the debate
> about whether AH should exist at all on this list.
> 
> I'm not sure that the statement that both IPsec and TLS
> will be in the spec is the rough consensus of the WG at
> this point.  I also want to caution folks that simply
> requiring these technologies to be implemented is not
> sufficient to address all the security issues - one example
> for iSCSI is that something will need to be said about
> the relationship of target names to the identities used
> for IPsec and/or TLS authentication.  Let me point everyone
> to Jeff Schiller's security tutorial from the San Diego
> IETF meeting at: http://jis.mit.edu/sectutorial/  which
> covers this and a bunch of related material on security
> at a level that should be accessible to almost everyone.
> 
> Thanks,
> --David

---

From: [email-masked]
Date: Wed, 7 Feb 2001 08:08:23 +0200

Bernard,

This is becoming an interesting thread.

The reason we went after TLS is that it can be used for session
authentication with stronger schemes than
and it is very popular for software implementations.

As for the cost of the hardware - the figures you quote are for 100Mbs (and
even there the NIC numbers are higher).
The low-end iSCSI adapters will cost well under $100 (at 1GBbs).

I don't envision all the options becoming necessary for hardware
implementations.  The pieces we wanted from TLS can be implemented in
software.

If we where forced to select one I would too go for IPsec (and that is what
we have in the current draft) but then we have
to specify session authentication on our own and keep updating it as new
schemes enter the world.  It seems far better
to rely on a specialized standard and TLS fits the bill.

Regards,
Julo

"Bernard Aboba" <[email-masked]> on 06/02/2001 23:21:14

To:   Julian Satran/Haifa/IBM@IBMIL
cc:   [email-masked], [email-masked], "RJ Atkinson" <[email-masked]>,
      "Smb@Research. Att. Com" <[email-masked]>, Ofer
      Biran/Haifa/IBM@IBMIL
Subject:  RE: Security Use Requirements

---

From: [email-masked]
Date: Wed, 7 Feb 2001 13:19:16 +0200

It would be interesting to findout if the chips support transport IPsec or
tunneling IPsec or both.
For tunneling IPsec you have to be a "believer" - i.e., you'll have to
believe that there is such a think on the wire
as iSCSI  is oblivious to it.  However if provided in an external box it
can provide excellent security.
The "required to implement" statement - if made by iSCSI - would have only
propaganda value
as it can't be assessed in a compliance testing suite.

Julo

"John Hufferd" <[email-masked]> on 07/02/2001 11:37:05

Please respond to "John Hufferd" <[email-masked]>

To:   RJ Atkinson <[email-masked]>
cc:   [email-masked]
Subject:  RE: Security Use Requirements

RJ,
I can not tell, from the obvious intensity of your note, if you agree with
me are not.  As Julian pointed out the prices were probably for the 100
Mb/s links.  In any event. the need is for security is at least 3DES.
Also the cost of a Gigabit chip for 3DES, I just found out, is $300 for
Samples.  If you go from Cost to street price, you will probably have a 3x
difference.  Now, that is a bit much for only one of the key componets on
an iSCSI/TOE HBA that is suppose to be competitive to Fibre Channels.

Therefore, I am reconsidering my statements, that we Must Implement.  Your
opinion might be useful here.  I had thought that in the real world,
separate box IPSec/ TLS, at the edge of the secure network might be all
that is required.

Since we must also consider the SW implementations on Desktops and Laptops
perhaps IPSec is OK there, since the volume of data will be relatively
slow.

Now, I am beginning to think that it is reasonable for one of the following
approaches to be OK. That is, one of those approaches should meet the
requirement for "Must Implement".
1. Only implementing an interface to the external IPSec/TLS box
2, SW implementation of IPSec/TLS
3. HW IPSec/TLS

In this case, if the customer wants protection, they either pay for the
separate IPSec/TLS box (can be shared by many connections), or the HW
IPSec/TLS or accept the overhead and lack of speed in SW implementations.

OK folks, lets here all your opinions on this.

.
.
.
John L. Hufferd
Senior Technical Staff Member (STSM)
IBM/SSG San Jose Ca
(408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
Internet address: [email-masked]

RJ Atkinson <[email-masked]>@ece.cmu.edu on 02/06/2001 01:29:38 PM

Sent by:  [email-masked]

To:   John Hufferd/San Jose/IBM@IBMUS
cc:   "Bernard Aboba" <[email-masked]>, <[email-masked]>,
      <[email-masked]>, "RJ Atkinson" <[email-masked]>, "Smb@Research.
      Att. Com" <[email-masked]>
Subject:  RE: Security Use Requirements

At 16:21 06/02/01, John Hufferd wrote:

>I think that Julian addressed this, but, an installation might want only
>the connection to the local environment, and if so administratively tell
>the iSCSI ends to not do the encryption etc.  Especially if some of the
>ends are Laptops and Desktops.  But all side must implement the features.

        Implement != turn on operationally.  The above explains
why clever vendors might have a configuration knob to turn off
security.  The above does NOT make any kind of case for not
always *implementing* security.

>By the way you might have slightly overstated the IPSec chips going at
full
>gig speed, when you talk about triple Des.  And if there are some they are
>not within the normal costs one would expect for a iSCSI NIC HBA.

        So if you believe the costs are so high, implement single DES.
For a lot of threat environments DES-CBC is sufficient and it surely beats
the hell out of nothing.  By the way, the crypto parts vendors
that I'm talking with must be giving me better prices than you,
which I find surprising, since by the parts quotes I'm seeing
Bernard's math works just fine.

        Nothing anyone has said here has given any kind of reasonable
excuse to not make implementing security mandatory.  There has been
lots of rationale for making it optional for the user to turn on
for a given box, but nothing for making it optional to implement.
(Implement in the box != deploy operationally).

Ran
[email-masked]

---

From: Scott Bradner <[email-masked]>
Date: Wed, 7 Feb 2001 08:51:44 -0500 (EST)

it should be noted that the IPS working group was not given the option
of not having a mandatory to implement security scheme in the standard
The IESG will not approve an IPS standard that does not define a specific
mandatory to implement security scheme.

Scott

---

From: [email-masked]
Date: Wed, 7 Feb 2001 09:42:55 -0500

> "mandatory-to-implement-on-the-same-or-different-box"?

Mandatory-to-implement means "how the protocol behaves
on the wire" -- i.e., if one party starts to use a mandatory-to-
implement mechanism, the other party must respond
appropriately.  Whether 1, 5, or 15 boxes are used 
is not something a protocol spec should care about,
although if more than one box is used, whoever assembles
those boxes will have to deal with the security issues
that arise on the interfaces among the boxes.

> to fulfill the security requirement?

I'm definitely not ruling out such gateways, but I want to make
sure everyone understands that there will probably be interactions
between such gateways and iSCSI in the area of naming - we
are going to have to say something about how IPSec's notion
of identities (e.g., X.509 certificates, and in the SAD/SPD) match
up with iSCSI's notions (i.e., initiator and target names).
If the gateway is completely independent of the iSCSI system,
it'll fall to some higher level of management software or possibly
manual configuration to make sure that the gateway and the
corresponding iSCSI system(s) are configured consistently.

> In Orlando the agreement was that authentication digests can be left to
> specialized protocols (IPsec  and TLS) and iSCSI
> is not mandated to have them specified outside such a protocol. 

Good thing, as there are lots of ways to get authentication protocols
and the related integrity digests subtly wrong.

> The issue you raised - can now be translated should we make IPsec or TLS
> mandatory to implement?

That is correct - we are headed in the direction of making at least one of
those two mandatory to implement.  Note that it will NOT be acceptable to
say "implement at least one of these" and let implementers choose which
one because then an implementation that chose IPSec will not interoperate
with one that chose TLS (which is a wrong answer).

--David

---

From: Scott Bradner <[email-masked]>
Date: Wed, 7 Feb 2001 10:23:11 -0500 (EST)

> That pretty much settles the discussion by assertion.

the iesg does impose requirements on working groups from time to
time where it feels the security, stability or scaleability of the
net is an issue.

> Is it acceptable to say that a minimal compliant iSCSI implementation MUST
> include either:
> 
> - a minimal tunneling IPsec  gateway
> - a minimal transport IPsec    

as a general rule there is a requirement for "a mandatory to implement" 
so that there is at least one sure to work technology - some working
groups have added flexbility by having servers having more than one
mandayory to implement where clients can chose one of the set that
servers have to implement

I think its up to the WG to decide this one

Scott

---

From: [email-masked]
Date: Wed, 7 Feb 2001 17:06:45 +0200

Scott,

?

Regards,
Julo

Scott Bradner <[email-masked]> on 07/02/2001 15:51:44

Please respond to Scott Bradner <[email-masked]>

To:   [email-masked]
cc:

Scott

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 7 Feb 2001 08:17:57 -0800

Scott, et.al.,
Julian's first option below, was perhaps the same as my first option.  That
is, it could be acceptable to have a gateway box included in the must
implement.  I believe, with nothing to back it, that there are "driver to
Gateway" responses that an implementation can use and therefore be
validated that the implementation adheres to the must implement statement.

Does this sound right you Scott?

For reference here is my previous statement:

.
.
.
John L. Hufferd

Julian Satran/Haifa/IBM@[email-masked] on 02/07/2001 07:06:45 AM

To:   [email-masked]
cc:   Ofer Biran/Haifa/IBM@IBMIL
Subject:  RE: Security Use Requirements

Scott,

?

Regards,
Julo

To:   [email-masked]
cc:

Scott

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 7 Feb 2001 12:13:35 -0800

> that arise on the interfaces among the boxes.

The Security WG has invested a lot of time and effort defining "tunnel
mode", and its good to see that this can be leveraged for iSCSI.

> up with iSCSI's notions (i.e., initiator and target names).

ISAKMP has an optional field for identification, defined in section 3.8 of
RFC 2408.  IKE uses this to identify the initiator and responder.  Here is
the text from RFC 2409:

     IDx is the identification payload for "x".  x can be: "ii" or "ir"
     for the ISAKMP initiator and responder respectively during phase
     one negotiation; or "ui" or "ur" for the user initiator and
     responder respectively during phase two.  The ID payload format for
     the Internet DOI is defined in [Pip97].

As far as a host-based IPSec implementation is concerned, we could use this
for the WWUI to identify the initiator and target (I don't think its
feasible to have external security gateways use WWUI).  An IKE negotiation
between iSCSI devices could thus use the WWUI to set up the IPSec SA's.
However, RFC 2407 section 4.6.2.1 (IPSec DOI) indicates the only identifiers
usable (at least at the time of writing of RFC 2407) are FQDN's, IP
addresses or subnets, X500 names, or X509 certificates as the identifier.
If iSCSI intends to use WWUI, we would need to coordinate with IANA to add
in WWUI as another identifier type.

But I wonder if this is all really necessary???  Isn't it sufficient to have
the IP addresses identify the SA endpoints?  Isn't this what most ISAKMP
implementations are doing?  Is anyone aware of any other application that
use something other than IP addresses or FQDN's to negotiate IPSec SA's???

This leads to the original point I was trying to make at the interim
meeting, that for all practical purpposes, IPSec SA's really need only be
negotiated between IP addresses.  Once a connection has been secured between
the IP addresses, then WWUI's are used for authorization in the iSCSI login
exchange.  Sure, if we really wanted we could go in and include the WWUI in
the ISAKMP exchange, but I question if this adds any value at all.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 7 Feb 2001 12:20:22 -0800

Ran,

>         It is illogical to argue that having NO SECURITY is
> better than having DES-CBC.  Since you appear to be doing
> precisely this, I must be confused by your words and not
> following you clearly.  Can you kindly clarify ?
> 

It's often been said that the only thing worse than NO SECURITY
is the ILLUSION of security.  Single DES is known to be cracked.
John is correct that 3DES is needed for a system to be "secure".

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 7 Feb 2001 13:48:57 -0800

Ran,

> At 15:20 07/02/01, Joshua Tseng wrote:
> 
> >is the ILLUSION of security.  
> 
> Some security keeps the kiddies away, no security doesn't.
> I'd much rather have DES-CBC than nothing, because it visibly
> increases the work function for the adversary.
> 
> >Single DES is known to be cracked.
> 
> That is a false statement.  It hasn't been cracked.  The best
> attack known in the public literature is Biham-Shamir, which 
> requires ~O(2^^56) operations and some non-trivial preconditions.  
> There have been some specific brute-force attacks on DES that worked, 
> but they weren't real-time attacks and required a significant amount 
> of computational power.

Yes, thank you.  Cracked is the wrong word.  Brute-forced is
the term I meant to use.

While we're on the topic of security, my source (Schnieder)
indicates that in 1995, it takes 3.5 hrs average to brute-force
single DES.  They also estimated that by 2000, the CPU power
available would reduce that time to an average of 21 minutes. 
On the other hand, with 128-bit keys (and 3DES has 168-bit keys) 
would still require on the  10**17 years.

This attack doesn't need to happen real-time.  All I need is
a sniffer, and I could do all the attacks offline.  Once I have
the key(s), all your data is mine.

Regardless, your point is well taken.  Some encryption is better
than nothing--in MOST cases.

Josh
> 
> I'm not arguing against 3DES in preference to DES-CBC, but it 
> is just wrong to claim either that DES-CBC is cracked or 
> that running in the clear is better than running with DES-CBC
> (assumes reasonable cryptographic authentication in all cases).
> Note also that my comments are constrained to what is in the 
> published literature...
> 
> Ran
> [email-masked]
> 
> 
>

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 7 Feb 2001 15:01:13 -0800

David,

See below:

> There are definitely people out there using X.509 
> certificates for this
> purpose.
> The most common certificates bind keys to DNS domains, but 
> the domain in
> the cert need not be the FQDN of the machine using the cert (e.g.,
> www.foo.com
> may consist of a bunch of machines behind a web load balancer, all of
> which present the same certificate to browsers - note that 
> this is actually
> an SSL/TLS example, but the same thing can be done in IPSec).  I don't
> know what else is in common use - Ran or Bernard?

I agree absolutely this is always the case for SSL/TLS.  The Cert either has
the FQDN or hostname of the machine.  I don't know if there are IPSec
implementations doing this, although it wouldn't surprise me if there were.

> If I understand this correctly, Josh is advocating that there 
> be no required
> relationship between the IP addresses used to authenticate 
> IPSec SAs and
> the WWUIs used to authenticate iSCSI login ... allow me to 

There is an implied relationship in that once a set of SA's is set up
between two IP addresses, each endpoint is completely secure when talking to
the other endpoint.  This includes spoofing, man-in-middle, eavesdropping,
etc...  If an iSCSI login comes
in from the other endpoint IP address=A, then I KNOW it is coming from IP
address=A.  If that login from IP address=A says WWUI=XYZ, then I can now
take action to allow or disallow WWUI=XYZ.

But what if it is really WWUI=PDQ just pretending that it is WWUI=XYZ at IP
address=A?  Well, then there is already a public key authentication
mechanism defined in the current iSCSI draft, which presents a digital
signature of the iSCSI login message. Since I have the public key of the
real WWUI=XYZ, I can locally regenerate the required digital signature of
the REAL WWUI=XYZ.  If it doesn't match, then I reject the login.

> demolish this
> strawman :-) ... I have at least two significant concerns about this
> approach:
> - It opens up a set of attacks based on subverting the mechanism (or
> 	lack thereof) used to associate IP addresses with iSCSI targets
> 	(and initiators). 	If iSCSI target T is supposed 
> to be behind
> IP address
> 	foo, and the adversary can convince initiator I to access T
> 	by instead opening up a tunnel-mode IPSec SA to a different
> 	IP address bar, the absence of any check between IP address

This could never happen.  Remember, initiator I has an SA to IP address foo.
It should be able to defeat any spoofing attacks, including those from bar
or anywhere else.

> 	and target identity makes the adversary's job 
> significantly easier.
> 	FCIP has a similar issue in its tunnel configuration.
> - It also opens up a set of man-in-the-middle attacks based on the
> 	adversary being *between* one of the iSCSI nodes and its IPSec
> 	gateway.  Many IPSec gateways are located one or more hops
> 	from the endpoints that they protect, and it's not in general
> 	correct to assume that the network protected by the gateway
> 	is inherently secure.

If the user chooses to deploy gateway-based security, then of course there
must be other measures taken to secure against attacks between the iSCSI
node and the gateway.  However, I believe having the iSCSI node transfer its
WWUI to the gateway so that the gateway can set up an WWUI-based SA is not
practical.  How would you do it?  Would you need another IPSec SA to
transfer the WWUI between the iSCSI node and the gateway?

> Given the choice, I'd much rather lay down a set of rules and 
> guidelines
> for identity checking than resort to running an end to end 
> authentication
> and cryptographic integrity protocol inside an IPSec tunnel.

There already is a public key authentication mechanism in iSCSI.  I think
this is all that is required.

Josh
> 
> With my WG co-chair hat on, I want to clarify the above by 
> stating that
> I believe that the WG must consider the two classes of attacks/threats
> that I itemized above, but also that the "Given the choice" sentence
> above is probably not a comprehensive taxonomy of the possible
> countermeasures.
> 
> Thanks,
> --David

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 07 Feb 2001 16:58:07 -0500

>would still require on the  10**17 years.

        I'm assuming you meant Schneier.  It isn't just time;
it is both time and capital cost.  You omitted the cost
portion of the graph (Schneier, 2nd Edition, page 153, table 7.1).
For 3.5 hours in 1995, the hardware cost was $1E9.  Most folks
don't have ready access to hardware with that capital cost.
The book estimates (same page, just above the table) that
to get to the 3.5 hour mark in 2000, the hardware cost would
be around $1E6.  There is probably some real data on what the
EFF DES box cost and its brute-force rate, but this entire
paragraph is mostly sidebar to the main point that some kind
of security is needed.

>the key(s), all your data is mine.

        How often does the key change ?  How many keys do you 
have to break brute-force to get the interesting data ?  
How much data can you steal with a given key ? 

Good key management practices are an important part of security.  

>than nothing--in MOST cases.

        Thanks.

Cheers,

Ran

---

From: Joshua Tseng <[email-masked]>
Date: Wed, 7 Feb 2001 22:56:07 -0800

David,
> 
> Before I launch into the latest response to Josh, I want to
> summarize the high level point I'm trying to make:
> 
> 	It isn't enough to just point to existing security 
> mechanisms and
> 	say "use these".  It's necessary to say how to use them with
> 	the protocol and what other assumptions must be true in order
> 	to achieve the desired security properties - some of these
> 	assumptions will be requirements on other components/protocols
> 	in the environment.

Thanks, and the point I'm trying to make is that iSCSI and IPSec/IKE can
pretty much work independently, with no compromise to security.  Having
IPSec and/or IKE become involved in iSCSI (or vice-versa) will increase
complexity while adding little additional value.

Note that I'm not necessarily saying the same about TLS.  I agree with
Julian that TLS may need something from iSCSI, since the SA's are bound to
the TCP socket.  But I am not as familiar with TLS, so maybe I shouldn't get
into this.

> 
> This is particularly true because iSCSI contains a naming architecture
> that does not match the identities used in existing security 
> mechanisms,
> resulting in a need to spell out in detail what is being authenticated
> using what sort of identities, the relationships (if any) among the
> different sorts of identities, and how those relationships 
> are achieved/
> assured.
> 
> There's nothing in principle wrong with the existing security 
> mechanisms
> being discussed - the devil is in the details of exactly how 
> they're used.
> The following set of responses to Josh provide some examples:
> 
> > between two IP addresses, each endpoint is completely 
> secure when talking
> to
> An important assumption underlying the "implied relationship" 
> is that the SA
> terminates at the iSCSI endpoints.  That's not in general the case for
> traffic passing through IPSec security gateways and hence is 
> the sort of
> thing that has to be spelled out if/when this sort of setup 
> is intended.

Agreed.

> 
> FWIW, "completely" is also not the right word - IPSec can set 
> up SAs that
> provide integrity but not confidentiality, and hence do not 
> protect against
> eavesdropping, but I'll bet that was just a poor choice of words
> on Josh's part.
> 
> > But what if it is really WWUI=PDQ just pretending that it 
> is WWUI=XYZ at
> IP
> But how do one know that one has the *right* public key?  Since
> certificates aren't required in the current iSCSI draft, and the key
> distribution mechanism is not specified, all sorts of mischief is
> possible if naked public keys are being passed around.  Needless
> to say, that's not a particularly intelligent way to do key 
> distribution,
> but like the previous case, a discussion about what is required
> to assure that key distribution actually distributes the correct
> keys (and how to verify that if necessary) is in order.  The
> current iSCSI draft also includes a number of weaker authentication
> mechanisms that are vulnerable to man-in-the-middle attacks when
> there is not an end-to-end SA in contrast to public key mechanisms.

In this example, the public key comes from the X.509 certificate obtained
either from the iSNS or manually configured.  This certificate supposedly
can be bound to the WWUI and can be verified through the certificate
authority.  The iSNS spec describes this (section 5.5.16).

But note that this is only one method of iSCSI authentication.  Others
include the challenge handshake, shared secret password, kerberos, etc...see
the iSCSI spec.

The point is that IPSec provides the PER PACKET data
integrity/authentication and if desired, encryption.  The iSCSI login
process provides authentication AND authorization of the communicating
entities.  What more do you need?
> > This could never happen.  Remember, initiator I has an SA 
> to IP address
> foo.
> 
> That's not correct.  The analogous attacks on DNS are old news.
> This class of attack targets the configuration/discovery/naming
> mechanism(s), convincing I to initially contact T at bar 
> rather than foo -
> once I makes this mistake, it's downhill from there.  It's necessary
> to spell out the base assumptions, some of which will be requirements
> on configuration/naming/discovery and authentication, and explain
> how to get from them to the conclusion that this sort of attack can't
> happen.h

For this attack to succeed, an attacker would have to penetrate the iSNS and
substitute T2 at IP addr 2 for the real target of T1 at IP addr 1.  It would
then also have to forge a public/private key pair and have it signed by the
"trusted" certificate authority.  And then it would have to get initiator I
to replace the real certificate of T1 with the forged certificate containing
the public key of T2.  I count at least 3 lines of defense, but the only one
that really matters IMO is the "trusted" certificate authority.

The difference between DNS and iSCSI is that DNS doesn't have an equivalent
to the iSCSI login message.  I think the combination of IPSec and iSCSI
login process to make the possibility of success for this attack extremely
unlikely against iSCSI.  If initiator I were to somehow talk to the wrong
target at the wrong IP address, more than likely this will be caught in the
iSCSI login, through either the public key authentication or one of the
other authentication mechanisms described in the current iSCSI draft.
> > node and the gateway.
> And some of those measures will almost certainly be
> mandatory-to-implement if there are no words in the spec
> about how the gateway SHOULD/MUST be related to the
> iSCSI nodes accessed through it.

The security measures I have in mind have more to do with physical security.
I do not believe the security gateway needs to be iSCSI (or WWUI) aware, nor
do I believe it would add significant security value if it were.

Remember that even if the standalone gateway was aware of iSCSI and WWUI, it
must make a decision to ingress traffic through the appropriate SA on a PER
PACKET basis, according to RFC 2401.  The WWUI only exists in the initial
iSCSI login PDU.  Therefore, the gateway must make a decision based upon
what exists and is visible in every packet (i.e., each individual TCP
segment).  This includes the Source and Dest IP addr, and source and dest
TCP port.  Therefore, physical security is required anyway, regardless of
whether the gateway is WWUI-aware, because the established TCP connection
(based on the initial iSCSI login PDU) can be hijacked.

The only real difference between a standalone gateway IPSec implementation
and an imbedded one is that physical security is pretty much assured, since
both IPSec and iSCSI exist on the same box.

And the only additional capability I can think of from making the IPSec
implementation iSCSI and WWUI-aware (for both gateway and embedded
implementations) is a capability to specify more than one security policy to
the same destination IP address.  Thus, if target A and B shared the same IP
address (or exist behind the same security gateway), you could say ESP/3DES
to target A, and AH/SHA-1 or no security to target B.  While that might be
an admirable capability in some settings, I certainly don't believe it
should be required.  Much implementation headache can be averted by simply
saying 3DES to everyone at IP address=A.  Yes, you would waste processing
power in this case if there were 50 targets sharing the same IP address (or
security gateway), and only one of them needed 3DES, but since you can't
configure a policy per WWUI, then all traffic to all 50 targets at that IP
address would have to be encrypted 3DES.  But once again, this will not hurt
security.

Josh

> 
> > However, I believe having the iSCSI node transfer its
> > WWUI to the gateway so that the gateway can set up an WWUI-based SA
> > is not practical.  How would you do it?  Would you need 
> another IPSec SA
> to
> The short answer is configuration of the SPD and related things on
> the gateway (assuming the gateway can use WWUI identities to set
> up SAs), but that misses the point.  The point is that just saying
> "use an IPsec gateway" isn't enough.  Something more needs to be
> said about *how* to use the gateway to achieve the desired security
> properties.  For example, a suitably secured iSNS may be one
> place to put the bindings between WWUIs and IP addresses, which
> would allow IPSec SAs based on IP address identities to be used
> to help assure WWUI-based authentication.
> 
> The text describing this in the -03 version of the draft needs some
> significant work.
> 
> Thanks,
> --David

---

From: [email-masked]
Date: Thu, 8 Feb 2001 09:33:53 -0500

> Many posts ago, there was mention of three levels of security for iSCSI
>         
>	1: none
> 	2: iSCSI authentication
>	3: tls or IPsec
> 
> these level seems to correspond to what is in the version 3 draft.
>
> The trend in the current discussion seems to be that security must be
implemented.
> Correct me if I am wrong, but I am under the impression that fibre channel
currently
> is used at level 1 (although there is CRC).  I was also under the
impression that
> one of the main motivations of iSCSI was the belief that ethernet would
win over
> Fibre Channel as a network technology and hence the desire to send SCSI
over ethernet.

Oh, I wish Sean hadn't gone there.  Fibre Channel has some rather weak
authentication
and access control mechanisms, but the current state of Fibre Channel
security would
never have made it past an IETF Area Director, let alone out as a
standards-track RFC.
Small scale Fibre Channel SANs provide valid arguments for choosing not to
use
security in some cases - larger scale Fibre Channel deployments are
providing
much stronger arguments for why security implementation should be mandatory,
and there's quite a bit of work going on in the Fibre Channel world to do
something
about security after the fact.  In other words, Fibre Channel is not a valid
analogy
to argue about whether security should be mandatory to implement.

Beyond that, Sean is correct that there are a lot of details are missing
from the
security section of the -03 draft, and that in general, specifying fewer
mechanisms
is preferable.

--David

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 8 Feb 2001 22:10:45 -0800

>and it is very popular for software implementations.

SSL/TLS has many nice features, including better API support in
most cases, more flexible certificate policies, and lightweight
ciphers (e.g. RC4) This often makes it an attractive choice
for applications requiring ~ 100 Mbps throughput (e.g. your
average web server).

>even there the NIC numbers are higher). The low-end iSCSI adapters will
>cost well under $100 (at 1GBbs).

Really? Mind if I order a few thousand to use as ordinary Gigabit
Ethernet NICs? Our server farms need an inexpensive upgrade for
the 100 Mbps adapters ;)

>implementations.  The pieces we wanted from TLS can be implemented in

Well, if you only have a few sessions per card, you can do
session establishment in software. However, even though RC4
is very light weight, it is very hard to get close to 1 Gbps
throughput on it, even with a 1 Ghz processor. So you will
be likely to bottleneck at relatively low interface
utilization unless you have more than one CPU to throw at it.

>If we where forced to select one I would too go for
>IPsec (and that is what we have in the current draft)
> but then we have to specify session authentication
> on our own and keep updating it as new schemes enter
>the world.

Not sure why this would be necessary. Doesn't IKE (either
with Certs or shared secrets) give you the necessary
authentication/integrity protection?

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 9 Feb 2001 07:38:23 -0800

Bernard,
> 
> >TLS affords the capability of securely communicating through
> >proxys.  
> 
> I think you mean NATs, no? Not sure how you'd proxy SSL
> without terminating a TCP connection. 

You would proxy SSL by having the proxy terminate the TCP connection and map
the TCP stream from the old connection to the new one.  The proxy doesn't
have to look inside the TCP stream, which of course is encrypted.

> 
> >On the other hand, IPSec is a real pain to get through
> >firewalls.
> 
> If you're talking strictly about a firewall, not a NAT, I'm
> not sure why there'd be a difference. For IPSEC you need to
> open up protocols 50/51, and UDP 500. For SSL/TLS you need
> to open up a single TCP port for the application. Either way,
> you probably need to restrict communication to iSCSI targets
> with appropriate negotiation policies installed.

The difference between IPSec and TLS/SSL is that IPSec protects at the
datagram level, while TLS/SSL protects at the TCP stream level.  Passing
through a firewall boundary will most likely involve changing the IP
datagram itself (at least in the inbound direction), such as to perform NAT.
Because IPSec protects the datagram, NAT and NAPT involves changing a
portion of the IPSec protected data.  Because TLS only encrypts the TCP
stream and has no knowledge of the IP datagram, it can be safely repackaged
into different datagrams without modifying the TCP stream and affecting TLS.

There are two choices to getting IPSec data through a firewall boundary:  1)
terminate the IPSec SA at the firewall and re-start a new SA on the other
side.  2)  Cut a hole through the firewall.

The first alternative is prohibitive since the firewall is doing a lot of
processing already, and it would be an administrative nightmare to set up
since its a bottleneck supporting many users.  The second choice is also an
administrative nightmare because after
a while, your firewall will look like swiss cheese.  Its also a security
issue because an observant attacker doing a port scan will notice that
protocol 50/51 and UDP 500 can get through for various IP addresses.

Josh

> 
> >If we decide that iSCSI doesn't need to go through
> >firewalls, then we could let go of TLS.  
> 
> BTW, I'd note that the IPSEC WG is currently taking up the
> issue of IPSEC address dependencies and that several proposals
> have been put forward. So I wouldn't rule out being able to
> traverse NATs with IPSEC at some point in the future. 
> Unfortunately however, all of those proposals
> interfere with the ability to do HW acceleration :(
>

---

From: [email-masked]
Date: Fri, 9 Feb 2001 17:24:23 +0200

Bernard,

1- I stand by the numbers($) I quoted - not today however -:)
2-We wanted TLS to get iSCSI "thinner" and move  out of it
session-authentication.  IKE is not as flexible today.   If we are forced
to mandate something on the channel - we would prefer it to be IPsec.
3-TLS during the session is also less attractive as it gets into the way of
other mechanisms (1.8 in the current draft).

David (Black),

You said -

to say, that's not a particularly intelligent way to do key distribution,

Current iSCSI has  a single mechanism that could be used for key
distribution - Kerberos.
What I am trying to do is completely remove any need to deal with this
subject within iSCSI
and to defer to specialized standards.

There many obvious reasons to do that.

Even if we go for IPSec only I still think we should remove from this
draft all session authentication mechanisms beyond Kerberos and perhaps
SRP.

Regards,
Julo

"Bernard Aboba" <[email-masked]> on 09/02/2001 08:10:45

---

From: Joshua Tseng <[email-masked]>
Date: Fri, 9 Feb 2001 11:11:54 -0800

> 
> >I think there is a much easier way than the two methods you 
> describe below.
> >If the iSCSI authentication is taking place using the SA 
> negotiated by IKE,
> >then you have an implicit relationship between IKE and iSCSI
> authentication,
> >right?
> 
> That would be fine if there is only one iSCSI authentication 
> per IKE QM
> SA. Is that realistic?
>

Yes, you have a point in that multiple iSCSI devices MAY exist behind the
same IP address, and each device would be sharing the same IKE SA if they
were talking to the same peer IP address.  This would be the case for a
storage device that had multiple WWUI's.  It could also happen if the IP
address/IKE endpoint was a security gateway, and there was a network behind
it supporting multiple iSCSI devices.

As I mentioned before, physical security is needed to handle each of these
cases, to ensure a hostile entity can't use the same IP address that was
authenticated by IKE.  In the former case, physical security is pretty much
assured, since both IKE/IPSec and the 
multiple iSCSI WWUI's share not only the same physical box, but also the
same TCP stack. In the latter, yes of course additional measures MUST be
taken to ensure there are no hostile entities living behind a security
gateway.

Sure, an implementation geared to the paranoid user could do what you
prescribed in your previous message (but your suggestions only make sense
for a native iSCSI device).  But I don't think these measures should be a
MUST.  Physical security is a non-negotiable requirement in both cases, and
especially in the standalone security gateway scenario, this is a quite well
understood requirement in the security architecture document RFC 2401 when
it describes tunnel mode.

Josh

---

From: [email-masked]
Date: Sat, 10 Feb 2001 09:22:50 +0200

Josh,

The connections are disjoint allways and the IPSec context is per
connection.
There is no issue here.  iSCSI does not allow 1 session to several targets.
The target sellector is used only at connection setup and the connections
to different targets are disjoint (even if they use the same target port -
the initiator address+port has to be distinct in this case).

Regards,
Julo

Joshua Tseng <[email-masked]> on 09/02/2001 21:11:54

Please respond to Joshua Tseng <[email-masked]>

To:   Bernard Aboba <[email-masked]>
cc:   [email-masked]
Subject:  RE: Security Use Requirements

especially in the standalone security gateway scenario, this is a quite
well

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Sat, 10 Feb 2001 10:09:55 -0800

Hmmmm,

Yes, you are right Julian.  I was thinking about IPSec implementations that
use only the IP address and not the TCP port as a selector.  But yes, IPSec
can use source & destination TCP port as a selector, in addition to IP
address.  If that is the case, then there can only be one iSCSI Login per
IKE negotiation.  Thanks!

I believe that wraps up the case that IKE/IPSec and iSCSI can be completely
independent of each other.  If we layer iSCSI sessions on top of IKE/IPSec,
there should be no loss of security.

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Sat, 10 Feb 2001 09:56:39 -0800

Hmmmm,

Josh

---

From: Joshua Tseng <[email-masked]>
Date: Sun, 11 Feb 2001 22:55:59 -0800

Bernard,

> >I think there is only one per connection.
> >But by carefull handling at both ends the connection should 
> be able to
> >share the same context.
> 
> If each iSCSI authentication corresponds to a different initiator port
> number, then there is indeed only one per connection (IKE QM SA). The
> IP header and IPSEC SPI then link back to the IKE QM SA which in turn
> has a link to the IKE MM SA. Thus it is possible to link a given
> packet back to the identity used in the IKE MM negotiation.
> 
> This implies that a given WWUI is authorized for use on only one
> 5-tuple, and iSCSI needs to enforce this restriction. If a packet
> for the wrong WWUI arrives on a 5-tuple then iSCSI needs to discard
> it. In effect, this results in a hard mapping of WWUI to 5-tuple.

I think the WWUI only exists on the iSCSI login PDU, right?.  As far as I
know, that is the only place it shows up.  If this is correct, then it is
neither a practical nor efficient use of resources to for iSCSI to
cross-check the WWUI with the IKE SA.

I think it is fine enough for IKE to initiate a new IKE SA (let the
implementor decide if it's MM or QM) every time it detects a new TCP
connection (which implicitly means a new iSCSI login).  But I question that
even this should be MANDATORY, because most IPSec/IKE implementations are
triggered and keyed only by destination IP address.  If an implementor
wants to put all their iSCSI sessions on the same IPSec SA, I think they
should have that liberty.

Josh

> IPSEC can then be relied upon to make sure that traffic on a 5-tuple
> is integrity protected (and confidential if requested) and was sent
> by the entity that negotiated the IKE MM and QM SAs under which it
> was sent.
> 
> Does this meet your needs?
> 
>

---

From: [email-masked]
Date: Mon, 12 Feb 2001 01:43:05 -0500

> Does this meet your needs?

No, but it's close.  The 5-tuple actually has to link to an <initiator,
target> pair of WWUIs because iSCSI has to support
 one initiator accessing multiple targets, and likewise for
multiple initiators accessing the same target.  There's the
additional complication of multiple TCP connections between
the same initiator and target, although there should be no harm
in those using either the same SA or different SAs, depending
on which is more convenient to deal with the fact that the initiator
port numbers will be different.  It would certainly be reasonable
to require different initiators at the same IP address to use different
SAs, and likewise for different targets at the same IP address.

The reason offered for support of multiple iSCSI entities at the same
IP address and TCP port has been easier passage through
firewalls (only one port need be opened up, rather than one per
target).  FWIW, my inclination is similar to David Robinson's -
one target per <IP address, TCP port> seems to simplify things,
but there have been strong opinions expressed about the need
for multiple targets at a single <IP address, TCP port> for firewall
reasons.

Also, Julian wrote:

> Current iSCSI has  a single mechanism that could be used for
> key distribution - Kerberos.  What I am trying to do is completely
> remove any need to deal with this subject within iSCSI

I think that's the right direction and consistent with the direction
that we agreed to in Orlando.

--David