Subject: iSCSI - three negotiation items

From: [email-masked]
Date: Wed, 1 Aug 2001 21:46:53 -0400

Going through the list of simplification suggestions,
I found a few items that look like they
should be reasonable to deal with on the list.

(1) For any key that can take a numeric value, could
we specify the required base for the number, either
decimal or hex, not both.  The practical issue is that
the sort of large values used for keys and the like
in security are much easier to deal with in hex than
decimal.

(2) The KRB5 and SPKM inband cryptographic integrity
digests on p.136 seem to be relics of a prior inband
approach to security.  Has anyone implemented them?
Does anyone want them to remain?  Can we just delete
them?

(3) Can HeaderDigest and DataDigest be combined?
If (2) is done, this is about making use of CRC-32C
a single on/off switch rather than two separate switches
for header and data?

Comments?  Objections (with rationale)?

Thanks,
--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: "Julian Satran" <[email-masked]>
Date: Thu, 2 Aug 2001 10:13:43 +0300

comments in text. Julo

[email-masked] on 02-08-2001 04:46:53

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  iSCSI - three negotiation items

+++ the current draft allows for both - Is there something wrong with that?
Hex is simpler but if data gets copied from somewhere else and that is a
decimal source then that is error prone +++

+++ Yes - I think we can take them out although UMAC may get-in at some
point :-) +++
(3) Can HeaderDigest and DataDigest be combined?
If (2) is done, this is about making use of CRC-32C
a single on/off switch rather than two separate switches
for header and data?

+++ combining defeats the purpose of the iSCSI CRC - to get you through
iSCSI proxies that may change the header but will not change the data +++

Thanks,
--David

---

From: [email-masked]
Date: Thu, 2 Aug 2001 10:31:14 -0400

Comments below.  --David

> -----Original Message-----
> From: Julian Satran [mailto:[email-masked]]
> Sent: Thursday, August 02, 2001 3:14 AM
> To: [email-masked]
> Subject: Re: iSCSI - three negotiation items
> 
> 
> 
> comments in text. Julo
> 
> 
> 

DLB> Possibly.  The implementation issue is that converting
DLB> large quantities (e.g., 128 bit) from decimal to hex
DLB> is annoying (it's bignum arithmetic).  Does anyone
DLB> ever use decimal to represent this sort of keying
DLB> material?  The major concern is apparently the
DLB> security-related stuff (e.g., I doubt it's
DLB> a big deal if someone wants to use hex instead of
DLB> decimal for MaxConnections).
 
> +++ Yes - I think we can take them out although UMAC may 

DLB> Good.  

> iSCSI proxies that may change the header but will not change 

DLB> My fault for not being clear.  The proposal is to still
DLB> compute separate CRCs on header and data for exactly
DLB> that iSCSI proxy reason that Julian cites, but to
DLB> combine the negotiation keys into one key so that
DLB> the only two possibilities are:
DLB>  - Both CRCs are generated.
DLB>  - Neither CRC is generated.
DLB> Does anyone see a compelling case for one of these
DLB> CRCs without the other?