Re: FCIP: Short Frame Security Solution Proposal

[Ralph Weber <ralphoweber@compuserve.com>]

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