RE: FCIP: NAPTs Solution Proposal (issue from Irvine, CA Interim meeting)

[Black_David@emc.com]

Ralph,

See my response to Bob's mail.  The situation is 1) with a few
additions - the particular way in which FCIP has designed this
identity mechanism makes group pre-shared keys a bad idea, and
saying they SHOULD NOT or MUST NOT be used is part of the solution.

I would prefer that FCIP use an FC level identifier rather than
an IP address for identifying FC entities, but in the current
design, that identifier is being used as an unsecured means of
authentication, and hence some way of securing that
authentication needs to be found.  The reply to Bob outlines
how to go about getting IKE and IPsec to solve this problem; the
alternative of having FC try to solve this problem doesn't seem
tractable to me because the problem occurs with the TCP connections
after the first one, and FC is not going to want to rerun SLAP
just because a second TCP connection has been set up (and in fact
may not be able to).

Thanks,
--David

> -----Original Message-----
> From: Ralph Weber [mailto:ralphoweber@compuserve.com]
> Sent: Monday, November 12, 2001 7:54 AM
> To: IPS Reflector
> Cc: Black_David@emc.com
> Subject: Re: FCIP: NAPTs Solution Proposal (issue from Irvine, CA
> Interim meeting)
> 
> 
> David,
> 
> You appear to be saying one of two things:
> 
> 1) The NAPTs solution, as proposed, requires that FCIP eschew the
>    use of group pre-shared keys, or
> 2) The problems with the best on offer FCIP NAPTs solution design
>    are sufficient to convince the IESG that FCIP is justified in
>    prohibiting the use of NAPTs.
> 
> Although time may have altered opinions, I will note that option
> 2) conforms to the position of several people on the FCIP development
> team during the Irvine meeting. Certainly, option 2) greatly
> simplifies the changes required in FCIP.
> 
> It is clear that you will object to ANY form of identification
> that an FCIP Entity offers for one of the following reasons:
> 
>   a) Offering IP addresses is unacceptable because of NAPTs, and
>   b) Offering any other value is unacceptable because it is not
>      secure with group pre-shared keys.
> 
> Unless option 1) above is your real concern, it appears that the
> FCIP development team has spent two months on a near fruitless
> exercise, whose only benefit is a strong proof that FCIP should
> not support NAPTs.
> 
> Ralph...
> 
> Black_David@emc.com wrote:
> 
> > > For those cases where a secure environment is required, the
> > > new connection comes up through the normal IPSec authentication
> > > and encryption processes.  As a result, the transmission of
> > > the identifying world wide names is already transmitted in an
> > > encrypted format, creatable only by the authenticated and
> > > certified source and interpretable only by the authenticated
> > > and certified destination.
> >
> > The assumption that there's a big on/off switch for
> > security is not correct (e.g., suppose IPsec is running
> > with integrity on and confidentiality off) and
> > "authenticated and certified" is a peculiar concept for
> > group pre-shared keys, a very likely deployment scenario.
> > Also, IPsec has no clue about the WWN, and hence the IKE
> > authentication is not linked to the WWN that has to be
> > presented (a particular problem with group pre-shared keys,
> > but also a risk even with certificates).  In other words,
> > "authenticated and certified" doesn't place any restrictions
> > on what WWN is presented.  Finally, solving
> > an inband authentication problem by requiring that IPsec be
> > used to encrypt the WWN is wildly excessive, and besides,
> > the WWN has no secret contents- it's a public piece of
> > configuration information.
> >
> > There is a solution in this general area, but it involves
> > linking the WWN to the IKE identity that is authenticated.
> > That's probably going to break any attempt to use existing
> > off-the-shelf external IPsec gateways because gateways
> > don't grok WWNs, and the FCIP implementations won't
> > know what identity was used in the IKE authentication
> > to the gateway.  This is all a bit peculiar because FC
> > currently trust WWNs passed in various FC Login frames
> > without authenticating them, but that's T11's area of
> > responsibility putting this sort of thing into an IETF
> > standard isn't going to be acceptable.
> >
> > > If the Fibre Channel fabric is also operating in a secure mode,
> > > subsequent Fibre Channel authentication and certification
> > > is performed using the standard FC SLAP mechanisms.
> >
> > Only on the first TCP connection, unless you plan to require
> > taking the FCIP link down when the second TCP connection
> > is added (which strikes me as highly counterproductive).
> > The second connection just inherits the results of the SLAP
> > performed on the first one, whether its entitled to or not.
> >
> > > In addition to this, there are a whole bunch of policy
> > > restrictions that are verified as part of the creation
> > > of subsequent connections.  While these are not necessarily
> > > part of the security steps, they prevent the formation of
> > > connections which do not meet the security rules.
> >
> > I'm not sure what you're referring to, but I suspect they
> > don't help much here.
> >
> > > Assuming security mechanisms are properly implemented, where,
> > > then, is the security hole?
> >
> > The fact that the WWN is not authenticated means that anyone
> > who can set up an FCIP connection to an FCIP entity can tap
> > into any existing FC traffic flowing on any connection through
> > that FCIP entity.
> >
> > --David
>