RE: Security Use Requirements

[Joshua Tseng <jtseng@NishanSystems.com>]

David,

Question:  Does your "mandatory-to-implement" mean
"mandatory-to-implement-on-the-same-box", or 
"mandatory-to-implement-on-the-same-or-different-box"?

:-)

IPSec security gateways are widely available now, from
many different vendors.  Are you ruling out their use
to fulfill the security requirement?

Josh

> -----Original Message-----
> From: Black_David@emc.com [mailto:Black_David@emc.com]
> Sent: Tuesday, February 06, 2001 3:32 PM
> To: rja@inet.org; julian_satran@il.ibm.com
> Cc: aboba@internaut.com; ips@ece.cmu.edu; biran@il.ibm.com
> Subject: RE: Security Use Requirements
> 
> 
> Some related clarifications:
> 
> >         I suspect that failing to make security mandatory-to-
> > implement will tend to prevent the specification(s) from 
> > ever becoming IETF standards-track RFC(s).  However, the WG
> > can certainly *try* to slide by.
> 
> My original post was about mandatory-to-use, NOT
> mandatory-to-implement.  As for making security not
> mandatory-to-implement ... NOT on my watch ... and
> remember that Steve Bellovin is one of the ips WG
> co-chairs, making me a "good cop" by comparison on
> this sort of issue ;-).
> 
> >         Another customary IETF position is to work on the basis that
> > all IETF protocols are likely (in practice) to be deployed over
> > The Global Internet.  So the threat model discussions normally
> > MUST include those kind of threats and can't be limited to threats 
> > on a private intranet.
> 
> That is also correct ... and I say that with my WG co-chair
> hat firmly in place.  There is also language to this
> effect in the ips WG charter.
> 
> It's unfortunate that Julian focussed only on integrity
> in his response.  Going back to the Pittsburgh (summer
> 2000) minutes, secure authentication will be mandatory to
> implement ... so sayeth the AD.  I also believe that some
> form of cryptographically authenticated integrity will
> likewise be mandatory to implement (otherwise it's too
> easy to hijack an authenticated connection).  This means
> signed cryptographic checksums, not just CRCs (as Bernard
> explained).  OTOH, it's not clear that confidentiality
> will be mandatory to implement.
> 
> The whole point on mandatory-to-implement vs. mandatory-to-use
> is to adapt available security technologies to the circumstances.
> One simple example is that confidentiality is NOT mandatory-to-use
> in IPsec, otherwise AH wouldn't exist ... and 5 demerits to anyone
> who uses that comment as a jumping off point to open the debate
> about whether AH should exist at all on this list.
> 
> I'm not sure that the statement that both IPsec and TLS
> will be in the spec is the rough consensus of the WG at
> this point.  I also want to caution folks that simply
> requiring these technologies to be implemented is not
> sufficient to address all the security issues - one example
> for iSCSI is that something will need to be said about
> the relationship of target names to the identities used
> for IPsec and/or TLS authentication.  Let me point everyone
> to Jeff Schiller's security tutorial from the San Diego
> IETF meeting at: http://jis.mit.edu/sectutorial/  which
> covers this and a bunch of related material on security
> at a level that should be accessible to almost everyone.
> 
> Thanks,
> --David
> ---------------------------------------------------
> David L. Black, Senior Technologist
> EMC Corporation, 42 South St., Hopkinton, MA  01748
> +1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
> black_david@emc.com       Mobile: +1 (978) 394-7754
> ---------------------------------------------------
>