Subject: RE: FCIP: Short Frame Security Solution Proposal

From: [email-masked]
Date: Tue, 8 Jan 2002 17:58:08 -0500

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:[email-masked]]
> 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...
> 
> [email-masked] wrote:
> 
> > Ralph,
> >
> > > [email-masked] 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
> > [email-masked]         Cell: +1 (978) 394-7754
> > ---------------------------------------------------
>

---

From: Robert Snively <[email-masked]>
Date: Wed, 9 Jan 2002 16:29:59 -0800

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 08, 2002 2:58 PM
> To: [email-masked]; [email-masked]
> Subject: RE: FCIP: Short Frame Security Solution Proposal
> 
>

---

From: Robert Snively <[email-masked]>
Date: Thu, 10 Jan 2002 15:22:32 -0800

My response below.

> Sent: Thursday, January 10, 2002 1:56 PM
> To: [email-masked]; [email-masked]
> Bob, 
> Ralph pointed out that text to me a while ago.  Here's some more
> text to consider, from the "Submitting Documents to the IESG"
> guidelines at http://www.ietf.org/ID-nits.html -
> 
>   Does your document have an adequate security considerations section?
>   Some have said that the "Security Considerations" section 
> of a document
>   essentially helps hackers attack implementations. It may, 
> but the fact
>   is that they will do the analysis themselves anyway - not 
> doing a threat
>   analysis will not stop them from exploiting weaknesses in 
> your design.
>   But by pointing out design choices you have made which have security
>   implications, or by documenting "when you implement this, you should
>   make these choices that have security implications", you 
> may help people
>   build implementations that are more hacker-proof, and you may find
>   something you can improve. Frankly, the IESG has so many 
> documents come
>   its way which have no thought for security in them it must 
> return for
>   the analysis, putting the analysis into the document will be helpful
>   in getting it through.
> 
> The use of the nonce is a design choice that has security 
> implications,
> and I'm asking that those implications be described.  A specific
> discussion of other threats to TCP, IP, and protocols that use them
> (e.g., address spoofing, TCP connection hijacking, RST attacks) is
> not needed beyond something like Ralph's text that notes 
> their existence.
> FCIP did not invent TCP or IP, and hence can rely on other documents
> to describe security considerations inherent to those protocols.
> FCIP did invent the nonce, and hence needs to describe its security
> considerations.

David,  

That is why the nonce got the special treatment of this
text (and related text in another section).  However, I
do not believe the particular scenario is interesting,
since anyone who has the combination of resources and
unauthorized access necessary to do that evil scenario 
can do some dozens of other related scenarios at least 
as evil.  Some of them, especially those involving
denial of service by flooding, can even be done on the first
connection of a link.

By providing the example, we may leave the mistaken 
impression that resolving the security issues of the 
particular scenario will successfully prevent all 
attacks.

I think the straightforward warning that evil scenarios are
possible in this particular environment should be
sufficient to call security attention to that area.
The simple solution (using IPSec) is offered to guarantee
security for environments that can be secured using
internet security functions.

Of course there are lots of security problems outside
the scope of IP, FCIP, and FC, but those are well understood,
even though intractable.

Bob