On Tue, Jan 21, 2014 at 10:25 AM, Stephen Kent <[email protected]> wrote: > PHB, > ... > > >> One major design limit in IPSEC and TLS is that both view the key >> exchange as being integral to the security layer rather than a separate >> service. I would like to separate out consideration of how chunks of data >> passing over the net are tagged and bagged for encryption and >> authentication from the question of key setup. >> > IKE is separate from ESP and AH. ESP and AH can be used independently of > IKE, although manual keying > is obviously not attractive in most cases. TLS is a different matter, in > that the handshake that > puts keys in place is integral to the data security protocol. However, > DTLS is used with SRTP > to secure VoIP, showing that the key exchange there can be used to support > other protocols. > > >> There is no logical reason why the key negotiation for TLS, IPSEC and >> tcpcrypt cant be shared. >> > yes, it could be, despite the erroneous assertions above ;-) >
Please do not confuse your misunderstanding of my post with my knowledge of the circumstances. IKE is certainly not currently packaged up for use an independent service. Saying that this could be done is not the same as it having been done. The current IKE document begins as follows: Kaufman, et al. Standards Track [Page 4] <http://tools.ietf.org/html/rfc5996#page-5>RFC 5996 <http://tools.ietf.org/html/rfc5996> IKEv2bis September 2010 1 <http://tools.ietf.org/html/rfc5996#section-1>. Introduction IP Security (IPsec) provides confidentiality, data integrity, access control, and data source authentication to IP datagrams. That is not how I expect a document describing an independent crypto protocol designed for use in other schemes to begin. Suggesting that the IETF adopt a practice of requiring re-use of such schemes in the security area is actually suggesting quite a major change in our approach. i.e. instead of having PGP and S/MIME sit in separate rooms defining two different message formats for secure email, require them to agree on one message format that can be used with both trust infrastructures. The idea that key exchange can be implemented as an independent Web Service is not something I expect to see in the IPSEC docs since the originals were written several years before the term was coined. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
