RE: Security Use Requirements

[julian_satran@il.ibm.com]

David,

In Orlando the agreement was that authentication digests can be left to
specialized protocols (IPsec  and TLS) and iSCSI
is not mandated to have them specified outside such a protocol.  That was
what I asked for and there was agreement on that
waiting for your input from the security area.

That is why I focused on the basic thing we have to specify (rather than
refer to) - basic integrity and session authentication.
As for mandatory to implement or not the question Josh raised is very much
on all our minds - if it is external to our environment (like IPsec) what
should we make mandatory to implement.  IMHO we can make mandatory to
implement the kickoff of a security engine (as we have in the current
draft).  BTW this is also the way security is implemented in all the
widespread protocols today - HTTP has a TLS upgrade command, Telnet and FTP
have security kickoffs etc.. NFS has nothing more either. None of them
specifies anything beyond that as the security component selected is the
one that is dictating what is the minimum and what the module is offering.

We choose to include both TLS and IPsec as they have different capabilities
(as Josh has stated already).

All the above are architectural considerations and I hope we did not make
any major blunder there.

The issue you raised - can now be translated should we make IPsec or TLS
mandatory to implement?

I think we should not.

Regards,
Julo






Black_David@emc.com on 07/02/2001 01:32:10

Please respond to Black_David@emc.com

To:   rja@inet.org, Julian Satran/Haifa/IBM@IBMIL
cc:   aboba@internaut.com, ips@ece.cmu.edu, Ofer Biran/Haifa/IBM@IBMIL
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
---------------------------------------------------