RE: FCIP: Short Frame Security Solution Proposal

[Robert Snively <rsnively@Brocade.COM>]

David,

In poking through the relevant text of our latest author's
draft (to be published early next week as an IETF draft),
I found the following text, which I would have imagined would
have addressed your concerns without any requirement
to document the particular example you have hypothesized.

  This one is part of the description of the authentication
  procedure for creating additional connections.

	Warning: The authentication mechanism described here 
	and in FC-BB-2 [4] 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.

One of the reasons I would be reluctant to document the
special case you have described is that, given the same
kind of security threat you have described, there are probably
a number of other cases with equal exposure if you were to choose
to operate without turning on the appropriate IPSec
security features.

Bob

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, January 08, 2002 2:58 PM
> To: roweber@acm.org; ips@ece.cmu.edu
> Subject: RE: FCIP: Short Frame Security Solution Proposal
> 
> 
> The timeout helps, but doesn't completely stop the race.
> Rather than alluding to its existence, I would explain the
> attack (see nonce on one connection, send it on another)
> and say that use of ESP confidentiality is the countermeasure
> when this is deemed to be an important risk.
> 
> Thanks,
> --David
> 
> > -----Original Message-----
> > From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> > Sent: Monday, January 07, 2002 12:25 PM
> > To: IPS Reflector
> > Subject: Re: FCIP: Short Frame Security Solution Proposal
> > 
> > 
> > David,
> > 
> > 2 out of your 3 comments pertain to the content of FC-BB-2
> > and as such incorporating them in something must wait for
> > the proposal to introduce the other half of this in FC-BB-2.
> > My intention is that said proposal will be finished in
> > time to meet the two-week rule for the T11 meeting in
> > Huntington Beach. I will announce the availability of
> > the proposal on this reflector.
> > 
> > The one comment that suggests adding text to the FCIP
> > draft is as follows:
> > 
> > > > > - 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.
> > 
> > Interestingly enough, this is need not be as wide open a race
> > as one might first think because the recipient of the TCP
> > connect request may timeout and close the connection if the
> > SF is not received in 90 seconds or longer.
> > 
> > None the less, words about the race condition have been added
> > to the FCIP revision in development. The specific new text
> > (and the paragraph preceding it) are as follows:
> > 
> > * The FCIP Entity MAY apply a timeout of not less than 90 seconds 
> > * to the waiting for the FCIP Special Frame bytes and if the timeout
> > * expires the FCIP Entity SHALL close the TCP Connection and notify
> > * the FC Entity with the reason for the closure.
> > *
> > * Note: One method for attacking the security of the FCIP Link
> > * formation process depends on keeping a TCP connect request open
> > * without sending an FCIP Special Frame. Implementations should bear
> > * this in mind in the handling of TCP connect requests 
> where the FCIP
> > * Special Frame is not sent in a timely manner.
> > 
> > Thanks.
> > 
> > Ralph...
> > 
> > Black_David@emc.com wrote:
> > 
> > > 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
> > > ---------------------------------------------------
> > 
>