TLS negotiation mechanism

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