RE: FCIP: Short Frame Security Solution Proposal

[Black_David@emc.com]

I think this is a workable approach.  A few comments:

- There are a dependencies among a number of components
	on who supports what, some of which are under
	T11's control.  If it turns out that the T11
	aspects of this are not mandatory to implement,
	I think multiple TCP connections in a single FCIP
	session need to be disallowed if this authentication
	cannot be performed by the implementation (i.e.,
	is not implemented) - putting in a note to this effect
	regardless of what T11 does might be a good idea
	to decouple FCIP from FC-BB-2 in this area.
- Any nonce must be validated ("yes, that's my connection")
	at most once.  If the FC Entity on the other end
	of the first connection is capable of saying "yes"	
	twice to the same nonce, there's an obvious
	replay attack.
- Some words will need to be added about a nasty race
	condition in which the attacker opens up a
	connection up to the point of sending the short
	frame, watches a real connection get set up to
	the point that the attacker sees the short frame
	on the real connection; the attacker extracts and
	uses the nonce, and TCP tricks (e.g., corrupt
	the TCP packet containing the nonce to cause
	a checksum failure, or send a well-timed RST).
	The short answer to dealing with this is "use
	IKE and also ESP encryption if warranted" when
	this sort of attack is a concern.
- I think it's necessary to authentication the first
	TCP connection (up to FCAP or whatever) before
	sending the ILS that would authenticate a
	subsequent one, but details beyond that (e.g.,
	can one send the SYN for the second TCP connection
	before the first connection authenticates) are
	probably up to implementations.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
black_david@emc.com         Cell: +1 (978) 394-7754
---------------------------------------------------


> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Thursday, December 20, 2001 8:55 AM
> To: IPS Reflector
> Subject: FCIP: Short Frame Security Solution Proposal
> 
> 
> This message proposes a solution to the security
> issues surrounding the FCIP Short Frame proposed as
> a solution to the NAPTs problem.  The security
> issues and directions toward a solution were
> discussed in Salt Lake and this message is an
> attempt to follow the path charted in those
> discussions.
> 
> Solution Assumptions
> 
> A) This matters a lot less if IPsec authentication 
> is in use and rigorously managed because IPsec solves
> this authenticates TCP connections, substantially
> reducing the opportunity for rogue end-points to
> make TCP connections to FC/FCIP devices.
> 
> B) Securing the first TCP connection in an FCIP Link
> is handled outside the scope of this solution. In Fibre
> Channel, securing the first TCP connection may be 
> accomplished using FCAP. At this time, it is not clear 
> whether FCAP authentication of the TCP connection 
> needs to be mandatory or recommended for configurations
> exposed to security risks.
> 
> C) Once authenticated, the first TCP connection is
> allowed to carry F Class frames.
> 
> D) The objective of this solution is to authenticate
> the second to n-th TCP connections using a protocol
> that has lower overhead than FCAP or IPsec.
> 
> Solution Changes in FCIP
> 
> The principle change in FCIP is to REQUIRE the FCIP
> Entity to interact with the FC Entity to authenticate
> the second through n-th TCP connections for a given
> Link End Point (LEP).
> 
> Upon receipt of an n-th TCP connect request and Short
> Frame (SF), the FCIP Entity MUST request (from the FC
> Entity) confirmation that the TCP connect request is 
> from the same FC/FCIP Entity as the first TCP connection.
> The FCIP Entity MUST delay return of the SF until the FC 
> Entity provides the confirmation.
> 
> In addition, a new 64-bit nonce field is needed in
> the SF. Theoretically, the nonce field could overlay
> the Destination FC Fabric Entity WWN field. However,
> the current leaning is to add a new field, lengthening 
> the FCIP Short Frame to the point where it will have 
> to be called the FCIP Special Frame.
> 
> The FCIP Entity shall communicate the newly defined
> SF nonce plus other SF information to the FC Entity
> in the interaction required to confirm the second
> through n-th TCP connect requests.
> 
> Solution Changes in FC-BB-2
> 
> The principle changes in FC-BB-2 are:
> 
>   a) Discussion of how the FC Entity may respond
>      to an FCIP Entity request for authentication
>      of a second through n-th TCP connect request;
>   b) Definition of a new SW_ILS to be used in
>      confirming the second through n-th TCP
>      connect requests; and
>   c) Description of how the new SW_ILS is exchanged
>      between the FC Entity where the TCP connect 
>      request is received an authenticated FC Entity 
>      over an existing F Class enabled TCP Connection.
> 
> N.B. It is important that this negotiation be placed
> in the FC Entity because the Fibre Channel elements
> at each end of a link have in place protocol mechanisms
> for negotiations and exchanges of this type.
> 
> Solution Mechanics
> 
> When an FC/FCIP Entity makes a TCP connect request
> for what it knows to be the second to n-th TCP
> connection in an FCIP Link, it places a randomly
> generated 64-bit nonce in the SF. (Note: There needs
> to be requirements on the nonce generation method to
> ensure that predicting nonce values is sufficiently
> difficult. The ULP Framing draft has been recommended
> as a source for these requirements.)
> 
> When an FCIP Entity receives a second to n-th
> TCP connect request, it will delay returning the
> SF until the SF nonce and other SF information is
> authenticated by the FC Entity. If the FC Entity
> reports that authentication failed, the FCIP
> Entity SHALL close the TCP connection.
> 
> Details of the mechanism by which the FC Entity
> authenticates a second to n-th TCP Connect request
> are to be specified by T11 in FC-BB-2 (along with
> numerous other Fibre Channel protocol issues
> related to FCIP).
> 
> A proposal containing at least the following
> will be made.
> 
> The FC Entity may authenticate the TCP Connect request 
> based on configuration information that is outside the 
> scope of the standards. In situations where security
> risks are possible, the FC Entity shall transmit
> the information provided by the FCIP Entity via a new 
> SW_ILS on a previously authenticated TCP connection
> (FCIP Data Engine) enabled for Class F frames.
> 
> It can be assumed that an authenticated TCP connection
> enabled for F Class frames exists because the absence
> on such a connection prohibits basic Fibre Channel
> link operation (i.e., the problem must be dealt with
> as a general concern for FC-BB-2 operation over FCIP.)
> 
> The response to the new SW_ILS will be one of:
> 
>    SW_ACC - indicating that the new TCP Connect
>             request is authenticated
>    SW_RJT - indicating that the new TCP Connect
>             request is not authenticated
> 
> The response shall be communicated to the FCIP Entity
> who shall act accordingly, as described above.
> 
> An FC Entity that receives one of the new SW_ILSs shall 
> perform the requested authentication by verifying that it 
> initiated a TCP connect request and sent the SF nonce. 
> The results of the authentication shall be communicated
> in the response to the SW_ILS as described above.
> 
> To further increase the difficulty of snooping
> TCP connections, an FCIP Entity that receives
> a duplicate nonce shall close the connection
> on which that nonce was received immediately
> without causing the SW_ILS to be sent.
> 
> Solution Pragmatics
> 
> This solution binds the authentication of the
> second through n-th TCP connections to the
> authentication of the first TCP connection,
> thus fitting the solution within the bounds
> of the assumptions (but no more).
> 
> Once the first TCP connection is properly
> authenticated, it is reasonable to ask the
> FC/FCIP Entity at the other end, "Did you
> make this additional TCP connect request?"
> The nonce (properly guaranteed for randomness)
> represents the "this" aspect of the question
> and renders nearly impossible nonce replay
> attacks wherein the FC/FCIP Entity asked the
> SW_ILS question is fooled into believing
> that SW_ACC should be sent because a correct
> nonce is presented.
> 
> This solution slows down the process of
> establishing TCP connections, but that seems
> unavoidable.
> 
> It may be desirable to require that there
> be no attempts to establish the second through
> n-th TCP connections until the first is
> authenticated. This is another slow down in
> the process, but one that will be imposed
> anyway at a later step.
> 
> It may be desirable to further slow down
> the process by requiring FC/FCIP Entities
> to process only one TCP connect request
> at a time, rejecting all TCP connect
> requests that arrive while another is
> in process. This will further add to the
> difficulty of mounting a replay attack.
> 
>