- From: Jason S. Smith <jason@mitre.org>
- Date: Tue, 16 Jul 1996 15:41:45 -0400
- To: Transport Layer Security Mail List <ietf-tls@w3.org>
I'm new to this list, so I apologize if thess issues have already been raised. I believe we agreed to begin with SSL v3 and incorporate features of other protocols such as SSH, PCT, etc. There are two issues I'd like to address, SSH and ISAKMP. I will begin with SSH. SSH Since Montreal, I have had time to review the SSH spec. I'm no expert in SSH, so if I've made any mistakes or misassumptions, please correct me. There are three features of SSH that I would like to see added to the TLS spec: 1) Reduced round trips by assuming that the server will prefer the same cryptographic attributes as the client. The benefit of cutting the round trips in half seem to out-weigh the cost of possibly sending extra unusable data. This is especially true for INTRAnets where client and server will very likely (almost always) prefer the same algorithm suite. 2) Negotiating cryptographic algorithms separate of each other. I am aware of the risk of combining cryptographic algorithms which were not inteded for use with each other. The spec could address this with guidance as to what works with what. I have had trouble with the opposite problem. I have worked with the government's FORTEZZA project. SSL defined two tags for FORTEZZA. The first supported FORTEZZA I&A with FORTEZZA encryption, the second supported FORTEZZA I&A with no encryption. The problem is that FORTEZZA encryption is currently too slow. I have customers who would like to use FORTEZZA I&A, but would prefer RC4 encryption for performance. The problem is that there is no FORTEZZA/RC4 tag. The time it takes to create a new tag and convince vendors to provide software to use the new tag is unacceptable. FORTEZZA encryption will be fixed before such a tag exists. 3) Service request message. I used to run multiple web servers on one machine. I can't do that anymore, since each SSL web server want to use port 443. If I change the port number, my firewalls don't recognize the port as HTTP and reject requests. I like the approach of using one port for the secure channel and negotiating a service. What I don't like about the way SSH implements this is that the service request message is encapsulated. This means that my proxy does not know what protocol is riding on top of SSH. Is there any objection to providing a service request message which is sent in the initial client hello? This would be unencapsulated, so my proxy could verify that I am using a valid protocol. If the server does not support the service, I find out before going through the remainder of the steps needed to establish a channel. ISAKMP I am even less knowledgable in ISAKMP. I have not completely read the spec, so take this with a grain of salt. Most of what I know of ISAKMP comes from talking with Mark Schertler after the TLS meeting (but please don't hold him responsible for my misunderstandings). Given that the TLS-WG needs to produce a spec quickly, there seems to be two paths to follow: 1) Start from existing de facto standards and "correct and improve" upon this base work. 2) Leverage existing IETF work which has been through the ringer and previously debated. The group chose to follow path 1, but I think path 2 may be the better approach. From an initial reading of ISAKMP, it sounds like it has most of the negotiation features needed by a TLS protocol. If we could make use of ISAKMP for negotiations, a great deal of the TLS work is eliminated, and we can produce a well defined standard quickly. If I recall Mark's briefing correctly, ISAKMP provides these benefits: 1) Leverage existing IETF work. Why spend additional effort debating negotiation issues that have already been flushed out in defining ISAKMP? 2) Several protocols (e.g., TLS, SOCKS, IPv6) could share the same key management code. This simplifies migration from one protocol to another. 3) Separate negotiations for security attributes (e.g., signing, hash, encryption algorithms). 4) Support for attribute certificate passing. 5) 2 round trips to establish a security association I am unsure of the difficulty in implementing ISAKMP. I know Cisco has a reference implementation from the following announcement: >Cisco Systems is pleased to announce the release of a reference >implementation of the IETF's Internet Security Association and Key >Management (ISAKMP) Protocol. This software distribution is being >made available free of charge for any commercial or non-commercial >use to advance ISAKMP as a solution to the problem of Internet Key >Management. Are there any other implementations of ISAKMP? What level of effort is involved in supporting ISAKMP as compared to SSL? I think ISAKMP should be seriously considered as the TLS negotiation mechanism. If anyone has any strong feelings for or against ISAKMP, I think now is the time to flush them out, before we get too far down the "correct and improve" path. As I said earlier, I don't have a strong enough ISAKMP foundation to vote either way at this time. I do feel that it has enough potential to warrent my taking a deeper look at the spec. I would urge those on this list who, like me, are not familiar with ISAKMP to give it a closer look. I would also urge those who are familiar with the spec to point out its strengths and weaknesses. Good judgment comes from experience, experience comes from bad judgment. Jason Smith The MITRE Corporation (703) 883 - 6219 jason@mitre.org
Received on Tuesday, 16 July 1996 15:44:58 UTC