Subject: RE: Storage over Ethernet/IP

From: [email-masked]
Date: Fri, 26 May 2000 11:01:27 -0500

>IPv6 has NO authentication capability not already shipping for IPv4,
>speaking as the person who designed both AH and ESP.  Marketing aside,
>there is nothing in IPv6 that makes it more easily secured than IPv4.
>Both support AH and ESP.  Deployed ISAKMP/IKE support IPv4, but might
>not support IPv6.

I must admit my error in that statement.  I was reciting something that 
I had read a year ago.  You are correct about AH and ESP
in IPv4 as well as v6.  Thanks for the correction.

Brian

---

From: Vernon Schryver <[email-masked]>
Date: Fri, 26 May 2000 10:51:03 -0600 (MDT)

> Yeah, okay.  I will grant that.  But, should a good technology be nixed
> because some idiots might mis-use it?  I personally don't think so.

This thread started with a question about a TCP technology report, and
wandered into firewall and general security technologies.  Which is the
good technology that is likely to be misused?

 .....

It has been at least 10 years since the word "technology" came to mean
"post process male bovine grass and grain."  Whenever someone uses a form
of the T-word, make the appropriate substitution and notice that the user's
intended meaning is far clearer, albeit sometimes more clear than the user
desired.

Vernon Schryver    [email-masked]

---

From: "Robert G. Ferrell" <[email-masked]>
Date: Fri, 26 May 2000 13:15:56 -0500 (CDT)

>If your OS is hardened enough, a firewall may not be appropriate.
>
>"New from Kellogs - Firewalls cereal - part of this *COMPLETE* and *BALANCED*
>security breakfast".

Given the recent revelations about Gauntlet, perhaps firewalls aren't quite 
the invincible bastions of unassailability they appear, as well.

RGF

Robert G. Ferrell, CISSP
Information Systems Security Officer
National Business Center, US DoI
[email-masked]
------------------------------------------------------------
Nothing I have ever said should be construed as even vaguely
representing an official statement by the NBC or DoI.
------------------------------------------------------------

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sat, 27 May 2000 10:11:39 -0400

In message <A427D1278F7CD311B1670008C7FAA62AC89F1F@CORPNT3>, Brian.Rubarts@born
.com writes:
>
>>> Encryption will be offloaded to the network interface.  ASICs on the NICs
>>> will greatly improve encryption and authentication performance.
>
>>all well and good, provided that this encryption and authentication
>>are actually compatible with that specified by higher level protocols
>>and the authentication actually meets the needs of users.  
>>(if your network interface needs to use and verify users' credentials,
>>as opposed to the host's credentials, it might be a stretch.)
>
>A network server will still authenticate user requests.  Only the host
>needs to be authenticated with the disk/disks.
>
Up to a point.  Yes, there are NICs available today with IPsec on-card. 
But given the prevalence of -- how shall I put this? -- single-user 
computers with user physical access, no OS protection and crufty software,
you really need user-granularity protection of the file access 
requests.  NFS-style protection with host authentication works if and only
if the server trusts the remote system to authenticate its users.  
That's demonstrably not true today.  

Yes, IPsec does, in theory, support user-granularity protection.  
That's very hard to do when you're using outboard IPsec implementations,
since you then need some way to pass the user's credentials (generally 
a certificate, not a user-id) back to the host, and tie every received 
packet to that identity.  It can be done, but (speaking as one of the 
primary participants in the IPsec development effort) I'm not impressed 
with its applicability in this case. 
>
>>> It will run over incredibly fast Packet over SONET Wide Area
>>> Networks--behind firewalls.
>
>>...it's 
>>inappropriate to assume that it will always be used behind firewalls...
>
>If the larger network that is employing this technology doesn't hire a
>decent
>consultant, you might be right.  If they do, it will ALWAYS be behind a
>firewall :-)
>
Speaking as someone whose firewall credentials are more or less beyond 
reproach, you're wrong -- period.  *Many* such uses will be behind 
firewalls.  Others won't.  The large corporate firewall is a dinosaur, 
because of extranets, telecommuters, unofficial links through or around 
the firewall, etc.  Comprehensive firewalls generally can't protect a 
network larger than one run by a single systems administrator (or, in 
some cases, a systems administration group); otherwise, they don't know 
where the links are.

And even when one sysadmin runs the net, what does he or she do when 
word comes down from the pointy-haired layer of the stack that there 
*will* be a VPN link to a joint venture partner?

Like it says on the (U.S.) toothpaste tubes -- firewalls can be an 
effective security measure when used as part of a program 
including good network hygiene and decent authentication.  But they're 
not magic security pixie dust, and they're not a substitute for 
authentication in the protocol.

		--Steve Bellovin

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 29 May 2000 13:56:13 -0400

In message <[email-masked]>, 
"Dawson, Peter D" writes:
>
>
>->-----Original Message-----
>->From: Harald Tveit Alvestrand [mailto:[email-masked]]
>->Sent: Friday, May 26, 2000 6:27 PM
>->To: [email-masked]
>->Cc: [email-masked]
>->Subject: RE: Storage over Ethernet/IP 
>
>->The point being made, remade and made again here is:
>->- Any protocol that offers no means of countering such 
>->security threats is 
>->broken, and should not be considered for standardization.
>
>->It is perfectly possible that after conducting a threat and modality 
>->analysis, one ends up with saying that hardware-accelerated 
>->IPsec using 
>->host identities is adequate for the scenarios involving 
>->otherwise-unprotected Internet links, and that a mode with no 
>->protection is 
>->adequate when the media is physically secured.
>->
>->But the analysis MUST BE DONE.
>->
>
>is vulnerability and threat analysis part of the 
>standardization process ??
>
Yes, in order to come up with a reasonable security considerations 
section.  (Clearly, much of it is site-specific.  But the protocol 
developers can't ignore it.)

		--Steve Bellovin

---

From: "Dawson, Peter D" <[email-masked]>
Date: Mon, 29 May 2000 18:07:48 -0000

->-----Original Message-----
->From: Steven M. Bellovin [mailto:[email-masked]]
->Sent: Monday, May 29, 2000 1:56 PM
->To: Dawson, Peter D
->Cc: [email-masked]
->Subject: Re: Storage over Ethernet/IP 
->
->
->In message 
-><[email-masked]>, 
->"Dawson, Peter D" writes:
->>
->>
->>->-----Original Message-----
->>->From: Harald Tveit Alvestrand [mailto:[email-masked]]
->>->Sent: Friday, May 26, 2000 6:27 PM
->>->To: [email-masked]
->>->Cc: [email-masked]
->>->Subject: RE: Storage over Ethernet/IP 
->>
->>->The point being made, remade and made again here is:
->>->- Any protocol that offers no means of countering such 
->>->security threats is 
->>->broken, and should not be considered for standardization.
->>
->>->It is perfectly possible that after conducting a threat 
->and modality 
->>->analysis, one ends up with saying that hardware-accelerated 
->>->IPsec using 
->>->host identities is adequate for the scenarios involving 
->>->otherwise-unprotected Internet links, and that a mode with no 
->>->protection is 
->>->adequate when the media is physically secured.
->>->
->>->But the analysis MUST BE DONE.
->>->
->>
->>is vulnerability and threat analysis part of the 
->>standardization process ??
->>
->Yes, in order to come up with a reasonable security considerations 
->section.  (Clearly, much of it is site-specific.  But the protocol 
->developers can't ignore it.)
->
->
->		--Steve Bellovin
->
OK...but nowhere in rfc2401/2402 do the STD doc's specify 
finding's of the  security /threat analysis, so how does
one state that the std doc, is within the reasonable limits
to counter "such threats and security" ?? 

/pd

---

From: Scott Bradner <[email-masked]>
Date: Mon, 29 May 2000 14:43:25 -0400 (EDT)

Peter - for the last few years the IESG has required IETF working groups
to have meaningful Security Considerations sections in standards 
track RFCs - these must include a threat and security analysis

Scott

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 29 May 2000 22:33:59 +0200

>standardization process ??
Yes.

RFC 2223, "Instructions to RFC authors", section 9.

See also RFC 2316, "Report from the IAB security workshop", section 9, 
which gives further guidance.

               Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 30 May 2000 10:09:48 +0100

>standardization process ??

YES (shouting intentional).

The "Security Considerations" section of every RFC ought to
contain vulnerability, threat analysis, risk mitigation,
and residual risk information.

Ran
[email-masked]