RE: FCIP: Short Frame Security Solution Proposal

[Black_David@emc.com]

Ralph,

> Black_David@emc.com wrote [responses embedded]:
> 
> > 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, ...
 
[... snip ...]
 
> >                                   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.
> 
> As currently worded, the FCIP Entity ALWAYS asks the FC Entity
> for authentication of a second to n-th connection and the
> FC Entity ALWAYS responds, yes or no. I fail to see how a
> note such as the one suggested would be viewed as anything
> more than advisory to FC-BB-2. The FCIP Entity has (in theory)
> no knowledge of how much or how little work the FC Entity
> does to generate its response to the request for connection
> authentication.

What I had in mind was advice to implementers that if the FC
Entity does not check the nonce over the initial connection with
its peer FC entity, then the answer to the FCIP entity SHOULD
be "no".  This could also be considered as advice to BB-2.

> > - 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.
> 
> I had sought to cut this type of attack off at the SF level
> (long before the FC Entity at the other end gets a nonce
> to validate) with the following words.
> 
> }...} 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.
> 
> To me, this seems superior for a couple of reasons:
> 
>   o It places the requirement in FCIP, closer to the source
>     of the problem.
>   o It eliminates an unnecessary authentication transaction
>     with the FC Entity at the other end.

Ok, but also see the discussion below on the "who presents
the nonce first" race. 

> > - 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.
> 
> Would it not be better to include a broad caution along the
> lines of:
> 
>    Warning: The authentication mechanism described here is not
>    designed to thwart sophisticated security threats. The IP
>    security mechanisms described in section 9 should be enabled
>    in environments where security threats are suspected.

Both.  The race is sufficiently related to the WWN short frame
that it should be specifically mentioned.  There are other
authentication mechanisms that are not subject to this race.
 
> > - 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.
> 
> I had hoped to have covered the case I think is being described
> above by the following language (note the words "previously
> authenticated"):
> 
> }...}                         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.
> 
> "Previously authenticated" may be vague, but it is intended to
> cover both authentication via FCAP and authentication against
> another F Class connection using this process.
> 
> Consider that case where a long lived FCIP Link starts out
> with one F Class connection.  Next, using the authentication 
> process described in this proposal and two or more Class 2/3 
> connections are added to the FCIP Link. As time goes by the F 
> Class connection becomes unreliable and the Entities at both 
> ends decide to close it and switch one of the Class 2/3 
> connections to Class F service.
> 
> The connection switched to F Class service has been duly
> authenticated, but not by FCAP. It seems perfectly reasonable
> that the switched F Class connection can serve to authenticate
> new connect requests.

Yes, "previously authenticated" is a bit vague.  This discussion
is fine, and adding the example from the discussion above would be
helpful.

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
---------------------------------------------------