draft-ietf-ipsp-ipsec-apireq-00 comments
"Joel N. Weber II" <[email protected]>
| Newsgroups | gmane.ietf.ipsp |
|---|---|
| Message-ID | <[email protected]> |
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.