Subject: draft-ietf-ipsp-ipsec-apireq-00 comments

From: "Joel N. Weber II" <[email-masked]>
Date: Fri, 20 Jun 2003 15:18:58 -0400

It would be useful if the introduction, after saying ``Many protocols
under development are considering the use of IPsec for security.''
there were examples given of a few such protocols; without such
examples, it is difficult to understand what problem this document is
really trying to solve.

For example, is the goal to provide an integrity protection and
confidentiality layer underneath SASL user authentication methods?  To
address an issue with protocols such as TLS and Secure Shell discussed
in draft-iab-sec-cons-03.txt: ``Second, TLS is susceptible to IP layer
attacks that IPsec is not. Typically, these attacks take some form of
denial of service or connection assassination.''?  To provide security
for some protocol whose properties are something else entirely?  All
of the above?  (Are there any protocols that are explicitly excluded
from this for any reason?)

For making Secure Shell less vulnerable to denial of service attacks,
it seems that it might be useful to define a new
diffie-hellman-group1-sha1-ah method that would be identical to
diffie-hellman-group1-sha1, except that it also would generate a
shared secret to feed to IPsec AH by doing HASH(K || H || "G" ||
session_id); this implies that there may be value to having an IPsec
API provide a mechanism by which an application can supply key
material.  Under ``Non-Goals and Bad Ideas'', it's unclear whether the
``Exposure of Keys'' section is trying to prohibit applications
contributing key material in this fashion, or not.

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 20 Jun 2003 20:00:15 -0400

I've made the following changes, which I hope will clarify my intent.

					- Bill

*** draft-ietf-ipsp-ipsec-apireq-00.xml	2003/06/20 22:52:06	1.4
--- draft-ietf-ipsp-ipsec-apireq-00.xml	2003/06/20 23:59:29	1.5
***************
*** 66,71 ****
--- 66,92 ----
  </t>
  </section>
  
+ <section title='Motivations for this work'>
+ <t>Most protocols for application security, such as <xref
+ target="RFC2246">TLS</xref> and <xref target="I-D.ietf-secsh-architecture">SSH</xref> operate
+ at or above the transport layer.  This renders the underlying
+ transport connections vulnerable to denial of service attacks,
+ including <xref target="I-D.iab-sec-cons">connection
+ assassination</xref>.  
+ IPsec offers the promise of protecting against many of these denial of
+ service attacks.
+ </t>
+ 
+ <t>There are other potential benefits.  Conventional software-based
+ IPsec implementations isolate applications from the cryptographic
+ keys, improving security by making inadvertant or malicious key
+ exposure more difficult.  In addition, specialized hardware may allow
+ encryption keys protected from disclosure within trusted cryptographic
+ units.   Also, custom hardware units may well allow for higher performance.
+ </t>
+ 
+ </section>
+ 
  <section title='Goals'>
  
  <t> Separate policy and mechanism </t>
***************
*** 309,315 ****
  <section title="Exposure of keys">
  <t>
  There is absolutely no reason for applications to see the underlying
! encryption keys.
  </t>
  </section>
  
--- 330,338 ----
  <section title="Exposure of keys">
  <t>
  There is absolutely no reason for applications to see the underlying
! encryption keys, or influence the choice of keys.  This is to allow an
! IPsec implementation to have a clear boundary around its cryptographic
! components.
  </t>
  </section>
  
***************
*** 399,405 ****
  <?rfc include="reference.RFC.2409" ?>
  </references>
  <references title='Informative References'>
! <t>None</t>
  </references>
  </back>
  </rfc>
--- 422,430 ----
  <?rfc include="reference.RFC.2409" ?>
  </references>
  <references title='Informative References'>
! <?rfc include="reference.I-D.iab-sec-cons" ?>
! <?rfc include="reference.I-D.ietf-secsh-architecture" ?>
! <?rfc include="reference.RFC.2246" ?>
  </references>
  </back>
  </rfc>

---

From: Bill Sommerfeld <[email-masked]>
Date: Fri, 20 Jun 2003 20:09:03 -0400

one more edit, to add references to related documents:

*** draft-ietf-ipsp-ipsec-apireq-00.xml	2003/06/20 23:59:29	1.5
--- draft-ietf-ipsp-ipsec-apireq-00.xml	2003/06/21 00:08:09	1.6
***************
*** 85,90 ****
--- 85,96 ----
  units.   Also, custom hardware units may well allow for higher performance.
  </t>
  
+ <t>
+ Areas where this is currently under active discussion include the
+ <xref target="I-D.ietf-ips-security">set of block storage protocols being
+ developed by the IP Storage working group</xref> and <xref
+ target="I-D.ietf-nfsv4-ccm">NFS version 4</xref>.
+ </t>
  </section>
  
  <section title='Goals'>
***************
*** 424,429 ****
--- 430,437 ----
  <references title='Informative References'>
  <?rfc include="reference.I-D.iab-sec-cons" ?>
  <?rfc include="reference.I-D.ietf-secsh-architecture" ?>
+ <?rfc include="reference.I-D.ietf-ips-security" ?>
+ <?rfc include="reference.I-D.ietf-nfsv4-ccm" ?>
  <?rfc include="reference.RFC.2246" ?>
  </references>
  </back>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 21 Jun 2003 11:10:12 -0400

>>>>> "Joel" == Joel N Weber <[email-masked]> writes:
    Joel> session_id); this implies that there may be value to having an IPsec
    Joel> API provide a mechanism by which an application can supply key
    Joel> material.  Under ``Non-Goals and Bad Ideas'', it's unclear whether
    Joel> the 
    Joel> ``Exposure of Keys'' section is trying to prohibit applications
    Joel> contributing key material in this fashion, or not.

  PF_KEY already permits an application to do that.
  That's why it is a non-goal. The problem is already solved.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [