RE: Security Use Requirements

[Black_David@emc.com]

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