DRAFT Orange County Minutes

[Black_David@emc.com]

I also appended my "iSCSI Security Directions and Rationale"
message to these as it seems to be an important part of
these minutes.  Comments/corrections to the list.

Thanks,
--David

IETF IP Storage (ips) Working Group
Orange County Interim Meeting
August 27-28, 2001
Irvine Marriott, Irvine, CA
-----------------------------------

-------> Day 1, Monday, August 27 - Fibre Channel protocol encapsulations
<--------

SCSI MIB effort is still aborning - those who are interested should contact
chairs.
This is needed by iSCSI.  Those who are interested should contact the
chairs.

-- FC Common Encapsulation - Ralph Weber, (Brocade)

No major open issues.  Need more text on CRC definition.  Will need to clean
up IANA text and put in reference for SOF* and EOF*.

Reference to T10/T11 specifications - will need to work out issues of
reference
to T10/T11 <xxxx>r<nn> documents.  FC-BB-2, FC-FS are issues here, SAM-2
will be
crucial for iSCSI.  See chapter 3 of existing T10 and T11 documents for
potentially
useful text.  Given that IETF and ITU have figured out how to do this, T10
and T11
issues should be manageable.

Document won't be last called until FCIP and/or iFCP is ready for WG Last
Call.

-- FCIP - Ralph Weber, (Brocade)

TCP port issue - allow other than the standard ports??  This is about both
NAPT and
	the ability to put more than one FCIP entity at the same IP address,
e.g.,
	for debugging.

Related issue is connection binding into a single ISL - if NAPT is used, the
IP address
	can't be used to do implicit connection binding, instead need a way
to do explicit
	connection binding as FC cares about which connections are part of
which ISLs.
	Can always unscramble this at the FC level, but that may be too
late.
	FC B_Port may not be able to get its hands on FC WWN info, so
inserting it
	earlier may not be possible.  NAT works.  Keith points out that
current approach
	uses IP address (layer 3) to do an FCIP (layer 5) demux. 

Note that this implies that the current text may be necessary.

Consensus call: Does FCIP need to support NAPT?  Sense of room: Yes.

Discussion will need to go to the list.  There are a lot of details here
that need to
be handled on the list.

Transit Time Validation computation - separation of FC Entity from FCIP
Entity requires
	specifying where the transit time is computed.  FC Entity is
documented in
	FC-BB-2.

Sense of room: Move time validation into FC Entity from FCIP Entity, time
stamps
	measure FC Entity to FC Entity times (discard decision is FC Fabric
decision).

Use IP time services to get the job done.  Seems reasonable, FC-BB-2 has
some details
	to work out to make sure that FC vs. IP time services are used
consistently and
	provide similar level of resolution.

Issue about failure detection/notification - goal is fail-fast, may have FC
doing
	connection failure detection above FCIP layer (TCP/IP).  Those would
be FC
	mechanisms.  Must do usual FC notification of loss of connectivity.

IP - FC flow control mapping/management issue - Need a "there be dragons
here"
	warning.

-- FC-BB-2 Assumptions and impact on FCIP draft - Murali Rajagopal,
Lightsand

There are a bunch of places that discuss required interaction between FC and
FCIP
	Entities.  New connection initiation and error recovery create
coupled
	interactions.

Administrative interface - just require one, and see RFC 2401 for a worked
example.
	Discussing this as a database set up by administrative interface is
fine.
	Notifications DO NOT flow through the database, need a description
of functional
	interaction of the FC and FCIP entities.

-- FCIP MIB - Anil Rijhsinghani, McData

Relation to FC Mgmt MIB will cause changes.  Building on existing MIBs is a
good thing,
	but FC Mgmt MIB didn't do that, and hence will change significantly.

TCP DSCP setting entity needs to be bit-bucketed.  Use a PHBID to indicate
this -
	see RFC 3140.

Exiting TCP MIBs have counters that span all connections.  Connections will
be long-
	lived, and hence per-connection counters make sense.

Connection options - how do you specify them given that table entries are
created
	as a result of connection creation, and these are needed to create
the
	connections?  Do you need a profile table to be used in creating
connections?
	If so, need two tables.

Add discussion of related MIBs in initial text of draft.

Align to forthcoming -06 version of FCIP draft (e.g., DLY_LIM has been moved
into
	FC Entity).  May need to pick up some things from SLP and static
discovery.

Should look at FC Entity (switch element) MIB for alignment.  There's
overlap
	between this and FC Mgmt MIB.  Don't see any need to fold FCIP MIB
into
	either FC Mgmt or FC Entity MIBs.

-- FCIP Discovery - Dave Peterson, Cisco

Scope and domain issue.  Domains overlap, scopes don't.  Scope defines outer
limits
	of connectivity - within the scope, domains define connectivity.
Domains
	are an addition to the SLP notion of scope, and a system can belong
to more
	than none domain within a scope.  This is about link establishment -
access
	control would be via FC Zoning at FC level.

FCIP DA usage is highly recommended, but not required.  SLPv2 is REQUIRED
due to
	constraints on SLPv1.  iSCSI also only allows SLPv2.  SLPv2 RFCs are
at
	Proposed Standard, moving to Draft Standard.  

Open issue of how domain relates to "site network" concept in SLP - will be
taken
	to list.

NAT issue is open - will have to look at management IP address and whole
concept
	of SNMP through NATs is peculiar.  Also affects iSCSI.  Using DNS
and default
	ports helps a lot with NAT boxes.

Will coordinate with FCIP MIB.

FCIP entity name (WWN) should always be generated automatically.

Is fabric name/principle switch needed for FCIP discovery?  Take this out.

Nit: Take out "L" on string templates, except that transports remains "M L".

Combine mgmt-entity and mgmt-ipaddr into URL, and require that there be an
	SNMP agent at that address that supports FCIP MIB and related
required MIBs.
	Q: Multiple URLs?  A: just one, protocol is SNMP, and FCIP MIB must
be there.

Security entries in template TBD based on FCIP security approach.

-- iFCP - Charles Monia, Nishan

- Frame Lifetime measurement issue.  R_A_TOV default is 10 sec.

Want large safety margin on max timeout through IP portion of FC fabric -
factor of 2
	suggested.  Want to avoid need for fine-grained SNTP queries.  Want
to set
	this timeout (IP_TOV) via. iSNS or other management interface.  iSNS
will
	have location of SNTP server to use, need .125 sec resolution,
100ppm max
	drift.  .125 sec drift every 10 minutes.  

Add note to spec about implementation techniques that can achieve 100ppm
(probably
	crystal, not LC oscillator).

Gateway parameters - IP_TOV value, reaction to loss of SNTP sync (cease time
calc.
	vs. shut down), and frequency of SNTP queries.  Define loss of sync
(number
	of missed SNTP queries).

Concepts appear to be applicable to FCIP, details will vary (e.g., time
budget).

- IPFC and iFCP

This is mostly about this being possible.

Have to support IPFC broadcast, and ELSs used by ARP and FARP. Added
	optional IPFC to IP gateway (done based on N_Port that passes only
IP
	datagrams to IP network).

Fragmentation MUST respect DF bit.

May have to gather several IPFC frames to build one IP packet because IPFC
"packet"
	may be spread across multiple frames.

It's not clear that this even belongs in the iFCP document, as it's entirely
about an
	implementation technique (it's basically describing the details of
how
	to build an (IP)FC blade for an IP router).

- iFCP Fabric Services Profile

Gateways must support Class 2 and Class 3, and must support Sequential
Delivery - FLOGI.

Fabric Services - F_Port server, fabric controller, directory/name server.
	SCN (State Change Notification) is gone from FC-FS, and can be
removed.

Broadcast service is optional.  No support for Management, time, alias, and
key
	distribution services.

Craig Carlson (T11.3) - may need to support Management Service.  Broadcast
may become
	mandatory in FC-SW-3.  Take this presentation to FC-BB-2.  FC-MI
does not
	require any of these for a fabric, but management server may be
needed in
	practice.

David Black - this sort of issue is "what makes an FC fabric an FC fabric?"
and
	hence are primarily T11.3 issues.

- TPRLO Augmentation

TPRLO instructs receiver to terminate one or more process logins.  Primarily
used
	within cluster context to force clean failover.

Augmentation adds data, may hit max frame size.  Hence may have to add
frames via
	increased SEQ_CNT (no SEQ_ID change).

- TCP/IP options for iFCP

David Black - should be conservative about specifying option usage.

Keep Alive - SHOULD NOT use, FC will handle this.  Should be lower case.
Nagle (tiny segment avoidance) - Should not use, lower case, not
capitalized.
		Can be set per-connection.
Window Scale and Wrapped sequence - should use, lower case, not capitalized
SACK - Pick up recommendation from RFC 2883 (SHOULD do SACK for TCP?)
otherwise
	lower case "should".
Cong control w/fast recovery [RFC 2581] - same as SACK.
ECN - Standards track RFC is about to appear, and echo recommendation from
it, like
	previous two.

Discussion of TCP RST - may be a useful tool to get TCP connections to "fail
fast"
	when FC has decided that there is loss of connectivity.

-- iFCP MIB - Kevin Gibbons, Nishan

First version of MIB has been submitted as draft-tseng- ...

Will look at existing FC MIBs, and see what it makes sense to import.

Sense of room: Adopt iFCP MIB as official IPS WG draft.

Minutes of teleconferences to be forwarded to ips reflector.
Action item: iSCSI MIB folks need to report their work.

- iFCP discovery - Josh Tseng, Nishan

Use SLP to discover location of iSNS server.  Use iSNS with iFCP.  No open
issues.

- FC-BB-2 relationship - Ralph Weber (Brocade) and Murali Rajagopal,
Lightsand

FC Entity is now intended to be common to FC-BB (ATM and SONET) and FC-BB-2
(IP),
hence want to put all IP configuration and related specifics into FCIP spec
rather
than FC-BB-2 spec.  Management details are not shown on the diagram and are
potentially vendor specific.  Diagram is from an FC-BB-2 5.1 draft.

Discussion of ISL connecting two E-ports 1-1.  Instead of creating multiple
virtual
E-ports, might want to modify FSPF to allow 1-many connections from a single
E-port.

- NAT issue - Larry Lamers, SAN Valley

Extensive editing of Larry's diagram and discussion of the various peculiar
things
that forms of NAT and NAPT can do.  See RFC 2663 for more.

-----> Transition to MIB Mechanics Session <--------

-- Tips on MIB Design - Keith McCloghrie, Cisco

Subtitle: Some (not well-enough known) SMIv2 design issues.

MIB should not be intended to be the only MIB that a product implements.
	- MIB-II has now been split into a bunch of individual MIBs.
		- RFC 1907 requires system and snmp groups in all agents
		- all network I/Fs must be represented in ifTable
		- Media-specific extensions to ifTable. [FC Mgmt integration
MIB
			needs to follow this approach, ditto Fabric Element
MIB].
		- Important MIBs in this regard: Interfaces MIB [RFC 2863],
and
			Entity MIB [RFC 2737]
	- Moral: omit information that is more generic than MIB's function.
		- Feel free to propose addition to other MIBs, e.g., Entity
MIB
			(Keith asked Entity MIB WG chair to raise specific
additions
			 from fcmgmt MIB to Entity MIB as a possible WG work
item).

Q: Should media-specific MIBs AUGMENT generic MIBs?
A: No, AUGMENTS implies 1-1 mapping of rows across the 2 MIBs.  Not all
interfaces
	are Ethernet interfaces, but may use same index as ifTable, even
though not
	all rows from the interfaces MIB will be present in Ethernet MIB.
Augment
	is useful for dealing with things at different levels of
standardization
	(including vendor-specific extensions to a standard MIB).

Q: Can additional values for standard enumerations be defined in
vendor-specific
	extensions?
A: Not for enumerations because additional values may conflict with
subsequent
	standard definition of those values.  Use Object Identifier (OID)
instead of
	enumeration in the original MIB to allow this sort of thing, as any
vendor
	can get an object identifier and put it in without fear of conflict.
	Example: Encryption and Authentication algorithms are defined using
OIDs.
Q: How are privately defined OIDs kept from conflicting?
A: Enterprise object identifier, allocated by IANA.  OIDs are
tree-structured, hence
	this OID allows others to be created.  Need to think about OID
structure,
	as narrow deep trees create long OIDs.  Vendor-specific MIBs should
be
	published, along with list of OIDs used as entry values in the MIB.
Careful
	structure of OID space (e.g., all encryption algorithms are rooted
at one
	OID) helps decipher meaning of newly seen OID.

iSCSI MIB had a narrow/deep OID structure because it used OID tree to
contain
	connection objects in session objects.  Containment and inheritance
should
	not be captured via OID nesting - these are better done as separate
tables
	using INDEX or AUGMENTS to handle relationships between rows in
tables.

Each extra level adds about 20% overhead to representation - this can have
	nasty consequences for GET BULK.  Examples in which extra depth adds
value:
	- Ease of administration (avoid duplicated subtrees)
	- configuring View-based Access Control (RFC 2575): this has a
subtree-based
		structure.

Objects, Notification, and Conformance are the three usual nodes underneath
the
	root object/OID for the MIB.  Structure beyond there (e.g., within
Objects
	subtree) varies.  SMI requires that notification prefix be object 0.
This
	avoids confusion when converting SNMPv1 traps to SNMPv2 by prefixing
a zero
	that can't otherwise appear in the OID (guarantees that when mapping
v1 trap
	to v2, one can't generate an otherwise existing OID) - hence have to
use
	that zero in order to make the corresponding conversion work in the
reverse
	direction.

Writable MIB objects.  Lack of security in SNMPv1 is not an excuse for no
writable
	objects.  Can always not implement write, but MAX-ACCESS clauses
cannot be
	upgraded - to change from MAX-ACCESS that forbids write to one that
allows
	it, one has to deprecate the old objects and define new ones.  If
write makes
	sense, allow it in MAX-ACCESS (maximum that makes "protocol sense").
Even
	with SNMPv1, it may make sense to allow write on isolated network.
MIN-ACCESS
	is minimum required for compliance (e.g., can have read/write MAX,
but
	read-only MIN).

Q: Are objects mandatory by groups?
A: By and large, yes.  This is to simplify management station construction,
so
	that a management station can assume that all objects in a group are
present
	if the group is implemented rather than having to check each one
individually.

Integer-valued object rules
- Enumerations MUST use INTEGER, not Integer32 or Unsigned32
- Range based rules for numbers to use Integer32 or Unsigned32 (see Keith's
slides)
- When using an integer as an Index, use Unsigned32, but exclude 0 as
reserved value
	for "does not exist".  If 0 allowed in range, MUST specify a good
reason.

Counters are only meaningful when taking differences between samples, time
period
between samples must be less than minimum wrap time.  A Snapshot of a
Counter is
called a Gauge, and does not change.  Counters can have discontinuities
(e.g., if
module is replaced).  MIB needs to record timestamp of discontinuity - mgmt.
app
can look at this to determine that a discontinuity has occurred and hence
old
counter values have to be discarded as differences across discontinuity are
invalid.
sysUpTime is an obvious example, ifCounterDiscontinuityTime [RFC 2863] and
	etherSTatsCreateTime [RFC 2021] are two others.

Q: Can ifTable indexes be reassigned?
A: Only if it's known to be the same interface or after reboot.  If in
doubt, don't
	reuse the old index values.  ifIndex values need not be in some
hardware
	scan order.  This gets much worse when interfaces can be dynamically
	created.  Avoid temptation to overload index with some sort of
hardware
	slot number or the like - define a separate MIB element that is the
slot number.

RMON2 defines ZeroBasedCounter32 for use in rows that exist for a short
time.
	Row has a create time at which the counter can be assumed to have
been
	zero provided that the minimum wrap time has not passed since then.

64-bit numbers: SMIv2 defines Counter64, but not Gauge64 or Unsigned64.
- This is a problem, RFC 2856 defines a couple of TC's with Counter64
syntax:
	- CounterBasedGauge64 (snapshot of counter64)
	- ZeroBasedCounter64 (64 bit equivalent of ZeroBasedCounter32)

Miscellaneous:
	- Descriptors of 32 characters or less, no hyphens there or in
labels.
	- MIB lines less than 80 characters
	- Specify ranges for all INTEGERs, sizes for all OCTET STRINGs
	- enumerated values should be arbitrary, not explicitly selected
		to correspond to something else (e.g., if 6 is TCP, this
		is an IP protocol number, so call it that).
Include "Relationship to Other MIBs" section
Extend ifTable for network interfaces (not augment).

iSCSI MIB gets the protocol number issue correct and has port number support
	for dealing with IPv6.

Q: MIB relationship structure?
A: ifStackTable helps with structure of stacked protocol MIBs, esp. below
IP.

Q: Name clashes?
A: Standard MIBs tend to have unique prefixes.  Enterprise MIBs should start
with
	name of enterprise.  This isn't perfect, but tends to work
reasonably well.

Q: How does IESG check MIBs?
A: Dave Perkin's smicng tends to be the most comprehensive in making checks?

Q: SNMP security direction?
A: Need is increasing, but some large operators use brute force solutions
(e.g.,
	block all SNMP traffic at ingress points).  Internal threats
becoming more
	of concern and entail use of SNMP security as a countermeasure.
Note that
	jump from SNPMv1 to SNMPv3 w/DES is much larger than DES to 3DES or
AES.

Q: SNMP key exchange/distribution?
A: Small number of management stations need to talk to all agents.  Key per
	management station w/localization to make it unique per agent scales
nicely.
	Kerberos integration w/SNMP has been proposed.

-------> Day 2, Tuesday, August 28th - Security <----------

- IETF security requirements discussion - David Black, EMC
	- MUST implement, OPTIONAL to use.  Best we can do is require
security tools to
		be available for use of protocol in environments where
they're needed.
		Vendors may choose to do poor security implementations -
can't control that.
	- Confidentiality is now required
	- If an "external" gateway is used, only the "public" interface of
the gateway
		is compliant, there's a risk if there's a significant
network between the
		"private" interface of the gateway and the iSCSI/iFCP/FCIP
system.

- iFCP security requirements - Franco Travostino, Nortel

	Current proposal - ESP tunnel mode, 3DES, HMAC-SHA1.  Assuming that
lots of
		sessions between the two gateways so 3DES keys don't expire
quickly.
		No free lunch for rekeying - for XX MB/sec traffic, have to
do a
		rekeying event every Y hours.  That Y is a constant
independent of
		number of SAs (one rekeying event every Y hours).  This does
help
		with ESP sequence space exhaustion.
	No interest in software implementations, hence 3DES software
overhead is
		NOT an issue.
	Want to use off-the-shelf IKE, and require PFS.  iSNS can store
security
		policies.  May not want to do PFS every time - one
possibility is
		to rekey the phase 1 SA (which always does a D-H) at the
points where
		PFS becomes required.
	Tunnel mode works better w/VPNs and existing external gateways.
	IKE + DHCP combination can be messy - unclear whether this is
necessary.

- FCIP security requirements - Venkat Rangan, Rhapsody

	Very little native FC security, long-lived TCP connections.
	Want to enable external gateways, but provide end-to-end security
(FC Entity
		to FC Entity).
	Don't want to do inband security negotiation - FCIP has no explicit
login.
	Note: Word "Manual" was not intended for keying mechanism,
pre-shared keys.
	Prefer AES with some suitable operating mode.  OFB?

Issue: ips wg vs. ipsec wg selection of required operating modes.
Suggestion
	to defer selection of MUST implement algorithms/modes 100% to ipsec
WG.
	Unfortunately, DES is currently a MUST there, which doesn't make
much sense.

	Keying: IKE is fine, SRP would have to be used on an out-of-band
connection.

	Authentication modes: RSA signature key, always mutual
authentication in IKE.
		For non-mutual authentication, fake a self-signed
certificate.
		Pre-shared authentication key is defined.  Informational RFC
coming
		on how to do GSS authentication in IKE with Kerberos.
	Pre-shared key would work for connecting peer gateways, but has
admin
		scaling issues as scenarios scale up.  Pre-shared key is
very
		commonly used for IPsec VPN implementations - seems to match
with
		FCIP and iFCP.

	T11.3 is working on authentication for FC-SW-3 - this could
authenticate
		and generate keys, but relying on that is probably not a
good idea.

- iSCSI security requirements - Mark Bakke, Cisco

	Who/what to authenticate - machine vs. some concept of "user".
Currently,
		machine, but some sort of "user" may be in future.
Sequential tape
		sharing solutions are already headed in this direction.

	SCSI is working on LUN level access control.  Most shared disk
vendors have
		individual solutions to this problem.

	There's an important distinction between system (e.g., IPsec) and
initiator/
		target authentication.  Latter is more general, as one could
create
		different initiators and targets for the apps/users (e.g.,
dedicated
		to backup application) - this is multiple logical
initiators/targets
		per system.

	Web analogy - client authenticates server machine, server
authenticates client
		user.  Initiator would authenticate device server, target
would authenticate
		initiator access to LUs.

NOTE: An extensive description of iSCSI security decisions made at this
meeting
	along with their rationale has been posted to the mailing list.
These
	minutes are a bit on the brief/sketchy side.  The message from the
list
	is appended to these minutes - see below.

- iSCSI Inband Keying of ESP - David Black, EMC
	[Section 6 of draft-black-ips-iscsi-security-01.txt]
	
	See slides.  Basic idea is to use the keys that iSCSI inband
authentication
	will generate anyway (CHAP doesn't) to key ESP.  Negotiation and
Startup are
	problem areas, Rekeying is manageable.

- IKE and iSCSI - William Dixon, Microsoft
	[Part of draft-aboba-ips-iscsi-security-00.txt]

	Description of IKE and IPsec functionality.

	Distributed filesystem scenario - only machine authentication
(fileserver doesn't
		know the user when it establishes iSCSI access to storage).
	Multiuser server scenario - may have user credentials in some cases.
Filesystem
		in OS has to manage which users can access what.
	If iSCSI users are distinguished, that will be done via separate
initiators.
		Note that user authentication decisions will often be
remoted by targets
		to take advantage of centralized authentication
infrastructure.
	IPsec target running in "secure mode" would require all traffic to
be IPsec-secured.

	Need to subset IKE to get a meaningful set of options for
interoperability.
		Will have to pick the right ones and make them "MUSTs".
	Can't protect against malicious software on same machine as iSCSI -
everything
		has access to the top of IPsec (especially of concern if
there's malicious
		kernel driver).  Requires inband iSCSI authentication and
trust in OS
		to defend against.
	
	Ignore material in draft that ties phase 2 SAs to individual TCP
connections,
		but still likely to have phase 2 SA per TCP connection.

	Proposed IKE profile - Identity protect mode Main + Quick (not
aggressive).
		- Use transport encapsulation
		- 1024 bit DH group
		- 3DES/SHA-1 or AES/SHA-1 [SHA-1 HMAC]
		- iSCSI responsible for deleting phase 2 SAs when TCP
connection goes away.

	IKE naturally matches a machine trust model.  User authentication
requires
		additions to current state of IKE implementation/deployment.
Separate
		authentication for key generation (machine - IKE) from
authentication
		for access (machine or user - iSCSI).

	PKI for certificate management is not widely available.  E.g. Free
S/WAN for
		Linux does not handle certificate authentication.  When cert
mode is
		used, all certs are self-signed, hence no machine trust
infrastructure.
	In contrast, Kerberos is widely available.  So, use pre-shared key,
and
		IKE-GSS-AUTH for Kerberos v5.  Pre-shared key could be the
mandatory
		to implement method, but will have scalability issues over
time.

	Need tunnel mode to work with external gateways.  MS will not ship
AES support
		for Windows for at least 12 months.

Consensus calls on keying direction:
	iSCSI - use IKE keying
	iFCP - use IKE keying
	FCIP - about evenly split between IKE and "not sure".  Proposal to
be
		posted to list by FCIP authors.

Need to talk about IKE authentication methods and transport vs. tunnel mode
on list.

-- NIST AES Modes of Operation Workshop Report - Howard Herbert, Intel

- CBC MAC and extension modes:
	CBC MAC is not secure unless all "messages" are same length.
Problem for
	IP Packets.  XCBC (2 add'l keys) and RMAC (1 key + random number)
both change
	computation of last block.  Workshop recommended XCBC be added to
CBC MAC.
- Next generation MACs: PMAC, XECB MAC, and UMAC
	Both PMAC and XECB MAC have patents filed, and each patent
cross-claims the
	other algorithm, so nasty patent issues.  UMAC is not suitable for
dedicated
	hardware due to size of key schedule and crypto state.  NIST will
continue
	to look at PMAC and XECB MAC, but neither will be standardized now.
- Next generation combined (authentication and encryption) modes: OCB, XCBC,
IAPM
	IPsec issue - "associated data" problem, IPsec has to authenticate
data that
	is not encrypted.  ESP must send SPI and sequence number in clear
and must
	authenticate them.  OCB may be extensible to deal with this.  All
three
	algorithms have patents filed and cross-claims, again a mess.  Note
that
	some countries make import regulation distinctions between
authentication
	and confidentiality (e.g., China), so combined mode could run afoul
of
	resulting regulatory restrictions.  NIST will continue to look at
OCB.
- Draft NIST modes spec:
	ECB, CBC, CFB, OFB, CTR, CBC MAC : counter mode is new, others
already exist.
	Draft will provide "guidance", but leave details (e.g., construction
of
	counter) to others (e.g., IETF).

NIST is prepared to standardize modes covered by patents, but doesn't seem
to be
	prepared to take out general use licenses for required patents.

Howard's recommendations for ESP:
	- Now: AES CBC MAC + XCBC.  AES CTR mode for confidentiality.
	- Next generation: PMAC or XECB MAC.  AES CTR mode for
confidentiality.
	- Continue to look at OCB combined mode.

Discussion of various things.

-- Hardware considerations - Joe Tardo, Broadcom

MAC: HMAC-SHA-1 recommended, not AES CBC MAC.
Crypto: AES/Counter mode, not 3DES CBC.  Rekeying time issues are a problem.
	Issue is what the counter looks like to enable packet by packet
processing.

-- iSCSI Wire Protection w/IPsec - William Dixon, Microsoft
	[Part of draft-aboba-ips-iscsi-security-00.txt]

Reminder that IPsec SA management (phase 2) is decoupled from iSCSI, iSCSI
tells
	IPsec when to tear them down (change to aboba draft).

Idling out - iSCSI links will need to idle out, iFCP will be able to do so
based
	on traffic not going across a particular N_Port pair.

Discussion - when IPsec hits resource exhaustion and can't set up or rekey
SAs,
	one loses connectivity, and the results can be ugly.  This has to be
tested
	for and should be the rough equivalent in effect and likelihood of
hardware
	failure.

Sequence number rollover - 10Gbps w/64-byte packets need to rekey about
every 3
	minutes.  That's doable, but there's a bigger problem - @ 10Gig due
to 64
	bit block size of 3DES, need to rekey every 30 sec or less, and
that's hard
	if IKE is not in kernel mode.

MAC Recommendation: HMAC-SHA1
Crypto Recommendation: AES at some mode.
	- 3DES ok up to 1Gbit, not good at faster speeds.  Can be
recommended, but
		shouldn't be the MUST implement.

Consensus calls for iSCSI:
	- HMAC-SHA1 is MUST implement
		SHA2 may be useful for increased speed.
	- Enhanced AES CBC MAC is a promising candidate for SHOULD
		Howard Herbert will look into this further - issue is
stability
		of changes NIST intends to adopt and time period for ipsec
WG
		standardization of result.
	- Crypto: 3DES/CBC is a MUST, AES/Counter is a SHOULD (no
availability
		of hardware is a good reason for ignoring a SHOULD).
	- Transport vs. Tunnel encapsulation: Defer decision to the list

-- iSCSI Authentication

SRP - Stanford and other IPR issues to the list.
Josh Tseng will take a look at PKI implications for iSCSI authentication
methods
	(SPKM-1 and SPKM-2) and figure out what's the right thing to do.

-- FCIP Security Discussion

Security design needs to be public/on the list.
Discussion of tunnel vs. transport mode.  Can get the cert processing rules
too
	general and not get end-to-end security, pre-shared key tends to
result in
	end-to-end.  Tighter specification of cert processing rules can also
yield
	end-to-end bias.

--------------- iSCSI Security Directions and Rationale Summary
---------------

This message was sent to the mailing list as a detailed explanation of the
iSCSI security directions adopted in the interim meeting and the rationale
for them.

From: Black_David@emc.com
Sent: Thursday, August 30, 2001 8:15 PM
To: ips@ece.cmu.edu
Subject: iSCSI Security directions and rationale

The purpose of this message is to state the recommended
security directions for iSCSI from the interim meeting and
describe the rationale for them.  Objections to these
decisions may be made on the list, but they need to have
*good* technical reasons.  I apologize for the length of
this message, but we spent a while on this in the meeting,
and I wanted to get all the considerations into this message.

First, an important piece of procedural context.  In order to
specify a security algorithm (cipher and mode, or integrity MAC),
we need a separate RFC to cite.  For algorithms without RFCs,
the work to create such an RFC occurs in the ipsec WG, not here.
Given the anticipated timetable for iSCSI, any new RFC for such
an algorithm needs to be in ipsec WG Last Call and ideally
submitted to the IESG by early next year, otherwise approval
of the iSCSI RFC gets held up until that algorithm RFC is ready.
The proposed charter revision for the ipsec WG (posted for
comments on August 9) anticipates the following work on
algorithms between now and the end of the year:

3)  New cipher documents to support AES-CBC, AES-MAC, SHA-2, and 
	a fast AES mode suitable for use in hardware encryptors

The "fast AES mode suitable for use in hardware encryptors" is
likely to be counter mode.  In practice, NIST is functioning
as a gateway to the ipsec WG in this area, in that if NIST is not
prepared to recommend a cipher/mode or MAC algorithm, the ipsec
WG is unlikely to work on it seriously in the next few months.
Hence as a practical matter "NIST is not prepared to recommend"
is fatal to the inclusion of an algorithm in the current iSCSI
specification.

There were four major security issues considered at the interim
meeting.  Here's a summary of the issues and recommendations:
(1) Keying - inband (SRP/ESP) or IKE subset
	Recommendation: IKE subset.  No further work to be done
		on inband keying and it will not be specified.
(2) Integrity MAC - many possibilities
	Recommendation: HMAC-SHA1 as "MUST implement", AES CBC MAC
		with XCBC extensions as "SHOULD implement", subject
		to verification that this is consistent with the
		ipsec WG's standardization plans.
(3) Encryption algorithm and operating mode - many possibilities
	Recommendation: 3DES in CBC mode as "MUST implement", AES
		in counter mode or whatever "fast AES mode suitable
		for use in hardware encryptors" is standardized by the
		ipsec WG as "SHOULD implement".  As previously noted
		on the list, NULL encryption is "MUST implement".
(4) Encapsulation mode - transport vs. tunnel
	Recommendation: Unable to reach reasonable consensus.  This
		is wrapped up in external gateway and end-to-end
		security issues as will be explained below.
These recommendations are subject to further comment on the list,
but I would ask that anyone who comments make sure that they
understand the rationale described below.  In the absence of 
serious objections, I intend to call consensus on the first
three items above in the near future.

Let me also note that nothing in this message excludes any
algorithm from implementation  - this is entirely about what
algorithms to REQUIRE (MUST implement) or RECOMMEND (SHOULD
implement).  The one exception is DES, which is sufficiently
weak to justify "SHOULD NOT implement" wording (IMHO).  Usage
is negotiable in all cases.  We may want or need to revisit
these recommendations in the future when the iSCSI specification
is closer to being issued as an RFC in light of developments
between now and then.

- Keying Rationale

Inband keying has negotiation and startup weaknesses.  The best
that can be done with negotiation for the inband keying approach
detects tampering with security negotiation after the fact (at
which point one has to abandon the connection and start over),
whereas IKE can prevent tampering.  There is no good solution for
starting ESP underneath an existing TCP connection.  IKE can be
implemented within memory requirements that are reasonable for
embedded devices (see draft-aboba-ips-iscsi-security-00.txt),
and IKE implementations are readily available in contrast to new
work that would be required for inband keying.  IKE can also be
judiciously subsetted to cut down on the complexity objections
to it (more on this in a separate thread).  In addition, there is
some desire for FCIP and iFCP to follow iSCSI's security direction,
and inband keying is a poor fit to these protocols, especially
FCIP.

- Integrity MAC Rationale

There are three classes of candidate MAC algorithms:
(1) New MACs (e.g., UMAC, PMAC) and new encryption operating
	modes that incorporate MAC functionality.  NIST is not
	prepared to recommend any of these at this time, and hence
	they have to be ruled out for iSCSI.  Unfortunately, all
	of the MAC algorithms likely to have high performance in
	hardware fall into this category.  In addition, with the
	exception of UMAC, all of these sorts of algorithms considered
	at the Modes workshop have serious intellectual property (i.e.,
	patent) issues.  Since UMAC has been of particular interest
	in the past, I should note that the developer of UMAC asked
	NIST not to consider it (and to consider PMAC instead) because
	UMAC is a poor fit to hardware implementations.  NIST will
	be considering algorithms of both sorts (including PMAC)
	for possible future recommendation.  
(2) AES CBC MAC.  NIST was initially prepared to recommend this,
	but it was modified at the Modes workshop to include the XCBC
	extension to improve security for variable size messages.
	NIST is prepared to recommend the result, but we need to check
	that the ipsec WG will proceed to standardize AES CBC MAC as
	modified in this fashion.  Between this and the newness of
	the modification, AES CBC MAC is most appropriate as a
	backup (in case a serious security flaw is discovered in our
	primary algorithm) and hence is recommended as "SHOULD
	implement" subject to verification with the ipsec WG
	(Howard Herbert is working on that verification).
(3) HMAC-SHA1 and HMAC-MD5.  This is what's left.  They're stable,
	well-known, widely implemented, but not exactly fast.  Of the
	two, HMAC-SHA1 is the better choice, as a security issue has
	been discovered with MD5 (as pointed out in the meeting, the
	issue doesn't compromise HMAC-MD5, but the "where there's smoke"
	principle suggests that HMAC-SHA1 is the better choice).  SHA2
	was felt to be more of a performance improvement for SHA1 and
	not sufficiently different from SHA1 to provide meaningful
	protection if a security flaw is found in SHA1, motivating
	the choice of AES CBC MAC as modified by XCBC as the second
	MAC algorithm.
 
- Encryption Algorithm and Mode Rationale

After the WG chair exercised his prerogative to exclude DES from
consideration, four algorithm/mode possibilities were considered:
	- AES in Counter and CBC Modes
	- 3DES in Counter and CBC Modes
3DES Counter Mode is a new mode for 3DES; the ipsec WG does
not appear to have any current plans to standardize it, and
that eliminates 3DES in Counter Mode from consideration.
The point of choosing AES would be to get an algorithm/mode
combination with high performance in hardware and software.
There's unlikely to be a significant difference between CBC
Mode and Counter Mode in software, but Counter Mode can be 
much faster than CBC in hardware, hence Counter Mode makes
a lot more sense for AES than CBC Mode.

Between 3DES in CBC Mode and AES in Counter Mode (or possibly
some other fast mode for hardware encryptors selected by the
ipsec WG), 3DES/CBC is specified, stable, and deployed (and
implementations are available).  Counter Mode for AES is not
completely specified yet, and AES implementations are not
currently widely available.  Hence 3DES in CBC Mode was
recommended as "MUST implement" and AES in Counter Mode or
whatever fast mode for hardware encryptors the ipsec WG
selects as "SHOULD implement" (e.g., inability to get
high performance hardware can be part of a valid reason
to ignore a "SHOULD").  NULL encryption needs to be "MUST
implement" in order to allow ESP to be used for keyed
cryptographic integrity without encryptions.  
 
- Encapsulation Mode

Given the decision to use IKE, a decision to use tunnel mode
encapsulation would result in iSCSI security *exactly matching*
the functionality of an IPsec security gateway (Bump In The
Wire).  Security gateways can be deployed anywhere, and as a
result, it's quite easy for the security obtained from gateways
to be other than end-to-end.  Based on discussions with ADs and
other knowledgeable folks in London, I believe that the IETF
Security Area and the IESG have a preference for end-to-end
security solutions.

Since most security gateways do not support transport mode
(there are a few that do, but they are the exception, not
the rule), REQUIRING transport mode would bias the iSCSI
specification towards end-to-end security in a fashion that
should make it easier to gain IESG approval.  OTOH,
REQUIRING transport mode would make it considerably more
difficult to use external security gateways to provide the
mandatory to implement iSCSI security, which seems to be of
interest to a significant portion of the WG.  On the third
hand, as was made clear at the IESG Open Plenary in London,
the IESG has little sympathy for a desire to use external
security gateways when the result leads to standardization
of other than the "best security available" (see Section 6 of
draft-ietf-saag-whyenc-00.txt).  On the fourth hand, there
may be ways to specify/recommend/require usage of IKE
authentication in a fashion that creates a bias towards
end-to-end security of similar strength to requiring transport
mode.

And that's about where things stand.  I apologize for being
unable to provide clearer guidance, but the situation is what
it is.  From a purely specification and process viewpoint,
REQUIRING transport mode will hasten completion of the iSCSI
spec and its approval by the IESG, but process should not
take precedence over making the proverbial "right" or "best"
technical and engineering decisions.

Please do not quote this entire message when responding.

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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------