Re: FCIP: Short Frame Security Solution Proposal

[Ralph Weber <ralphoweber@compuserve.com>]

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

T11 does not have a concept of "mandatory to implement".
In IETF terminology, a T11 "mandatory" is "mandatory to
implement and mandatory to use".

On the other hand, if you ask any storage product vendor
about the 'mandatory to implement' aspects of a T11 or 
T10 standard, you will find that the practical reality 
is that "anything that is in a standard is 'mandatory to
implement' for everybody except hosts."

The reason for this is that some customer somewhere wants 
just about any option listed in the standard, thus making 
all options listed in a standard, for all intents and purposes, 
"mandatory to implement". The only "options" that come to
mind as exceptions to this are the SCSI CHANGE DEFINITION 
and COPY commands (SCSI-2 COPY, not SCSI-3 EXTENDED COPY).

The problem of mandatory to implement options problem is so 
fundamental T10 and T11 have seen heated debates over letting 
an "option" in to a standard because of the burdens it will
place on products.

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

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

If this is a recommendation to FC-BB-2, we can carry it forward
as such. Otherwise, I need a more detailed description of what
is desired in FCIP.

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

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

If there is some subtitly that I am missing, try a 4x4 next
time as the 2x4 must have missed its mark.

Thanks.

Ralph...

-----Original Proposal Text Follows for Reference-----
> > 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.
> >
> >