ops-dir reviewer comment
randy
---
Section 3
"Denial of Service
attacks are beyond the scope of this document except to the extent
that they are made more difficult by good security practices."
I hope that this statement does not lead readers to conclude that
it is possible to completely ignore denial of service attacks. Given
the age in which we live in, and the importance of Internet
infrastructure,DoS attacks can have serious impacts. At some point, more granular
guidance needs to be provided characterizing DoS attacks and how to
evaluate the level of threat that they represent. This document might not
be the right place to do this, but it does need to be done -- there is
widespread mis-understanding of DoS threats within the IETF and IEEE communities.
" In general, the default today should be to use the strongest
cryptography available in any protocol. Strong cryptography often
costs no more, and sometimes less, then weaker cryptography. The
actual performance cost of an algorithm is often unrelated to the
security it provides."
It also might be noted that, depending on the hardware, cryptography
can be supported at very high line rates (1+ Gbps), so that
computational costs, which once were a major constraint, are increasingly
less of one.
Section 4.2
" We have evolved in the IETF the notion of "mandatory to implement"
mechanisms. This philosophy evolves from our primary desire to ensure
interoperability between different implementations of a protocol. If
a protocol offers many options for how to perform a particular task,
but fails to provide for at last one that all must implement, it may
be possible that multiple, non-interoperable implementations may
result. This is the consequence of the selection of non-overlapping
mechanisms being deployed in the different implementations."
Even where there is a mandatory-to-implement algorithm we have had
interoperability problems if the algorithm is not sufficiently strong.
I have my doubts as to whether CHAP represents a suitable mandatory
to implement algorithm in most circumstances, for example. The
interest in SRP largely derived from the need for a strong, freely
available algorithm for use in multiple situations. That need
still remains unfilled. So I'd suggest that the mandatory to implement
algorithm needs to be suitably strong to provide adequate security
for the major uses of the protocol.
Section 5.3
"As such, IPsec is currently inappropriate when host-granularity is too
coarse."
In practice we often see IPsec combined with application-layer security in
this case. For example, in L2TP IPsec provides security at host
granularity, whereas PPP authentication mechanisms are provide user
authentication. This does not provide true user separation however; on a
multi-user machine one user can still use the other user's tunnel.
"This makes it a poor choice for individual
applications, at least until IPsec is more widely deployed. "
It's worth noting that some applications don't really have any choice;
while IPsec acceleration enables usage at very high speeds (1+ Gbps), TLS
acceleration is not quite as advanced, and therefore is typically only
capable of rates an order of magnitude slower. It is possible that as time
goes on, TLS will catch up, assuming that there is enough demand, but that
is where we are today.
Also, the problem is not the availability of IPsec, but rather the lack of
APIs to truly customize it for use with a particular application. For
example, there are currently no APIs to retrieve properties of IPsec SAs,
or set credentials for use with IKE; or to set IPsec policies. This makes
it difficult for applications to determine whether they are running
over IPsec, or to set per-application certificate policies. This is
a considerable limitation in practice, since it means that applications
cannot typically solve all their security problems with IPsec. Of course,
authorization also remains unaddressed.
" There is strong potential for conflict between IPsec and NAT
[Hain99]. NAT does not easily co-exist with any protocol containing
embedded IP address; with IPsec, every packet, for every protocol,
contains such addresses, if only in the headers. The conflict can
sometimes be avoided by using tunnel mode, but that is not always an
appropriate choice for other reasons."
You might mention the NAT-T work. While this does allow IKE and IPsec
to traverse NATs, it does not help applications which contain embedded
IP addresses.
[NATIKE] Kivinen, T., et al., "Negotiation of NAT-Traversal in the
IKE", Internet draft (work in progress), draft-ietf-ipsec-
nat-t-ike-03.txt, June 2002
" Most current IPsec usage is for virtual private nets. Assuming that
the other constraints are met, IPsec is the security protocol of
choice for VPN-like situations."
I'm not sure this gives a realistic appraisal of the state of usage of
IPsec in this application. In practice, such usage needs to rely on a
number of non-standard extensions and somewhat questionable practices.
This includes XAUTH and MODECFG so as to allow for user authentication
and configuration; introduction of either group pre-shared keys
(main mode) or identity snooping (aggressive mode) where one of the
endpoints has a dynamically assigned IP address; and introduction of
non-standard extensions for IKE payload fragmentation, since support for
this is not provided within IKEv1, and in practice, certificate
deployments often result in certificate chains large enough to frag.
In my experience, TLS VPNs are growing in popularity, because they get
around some of these issues.
5.4
" Although application modification is generally required to make use
of TLS, there exist toolkits, both free and commercial, that provide
implementations. These are designed to be incorporated into the
application's code."
It's also worth talking about what TLS does that IPsec/IKE does not, and
what it doesn't do. For example, using TLS it is possible to have
application-specific certificate policies, whereas this is typically
not possible with IKE. TLS also supports one-way authentication, which
can be both a blessing and a curse. Also, TLS is more vulnerable to DoS
attack than IKE is.
5.5
" SASL permits the use of more traditional client authentication
technologies, such as passwords (one-time or otherwise). A powerful
combination is TLS for underlying protection and authentication of
the server, and a SASL-based system for authenticating clients."
It might also be worth saying that such a combination also introduces
man-in-the-middle vulnerabilities, because the SASL authentication is
not "bound" to the TLS tunnel within which it runs. Therefore if SASL
is run with TLS, it should not also be allowed without TLS.
5.6
" Note that the security of GSS-API-protected protocols depends on the
underlying security mechanism; this must be evaluated independently.
Similar considerations apply to interoperability, of course."
This is a good point, because if one is looking to provide provable
security properties, it may make more sense to limit usage to a specific
set of algorithms rather than taking on the liability of a "general"
mechanism such as GSS-API.
5.7
"(Note that the concept of storing application keys in the
DNS is still controversial.)"
My understanding is that this has been deprecated, so perhaps a
reference to RFC 3445 would be appropriate.
5.12
" Kerberos may be used by itself in a protocol. However, it is also
available as a mechanism under SASL and GSSAPI."
You might want to cite some of the references relating to Kerberos
vulnerabilities, such as:
[KRBATTACK]
Wu, T., "A Real-World Analysis of Kerberos Password Security",
Stanford University Computer Science Department,
http://theory.stanford.edu/~tjw/krbpass.html
[KRBLIM] Bellovin, S.M., Merritt, M., "Limitations of the kerberos
authentication system", Proceedings of the 1991 Winter USENIX
Conference, pp. 253-267, 1991.
[KERB4WEAK]
Dole, B., Lodin, S., and Spafford, E., "Misplaced trust:
Kerberos 4 session keys", Proceedings of the Internet Society
Network and Distributed System Security Symposium, pp. 60-70,
March 1997.