Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/95jul/ssl-minutes-95jul.txt

Text File | 1995-10-18 | 9KB | 226 lines

Secure Socket Layer BOF (SSL)

Reported by Antonio Fernandez/Bellcore

The SSL BOF was chaired by Taher Elgamal.

The first six sections of these minutes reflect information that was
presented in a set of viewgraphs.  The last section details group
discussion.


Agenda

   o Agenda and charter discussion
   o Comments
   o Implementations and experiences
   o The current draft ``01'' and how it works (i.e., changes from the
     previous draft)
   o More changes proposed
   o Proposed future plan


Proposed SSL Working Group Charter

     A very specialized working group to be setup to define the
     standard for using SSL as a socket layer security mechanism for
     Internet applications.  The working group will not deal with
     other network layer security, such as efforts in the IPSEC
     Working Group, other security APIs being discussed in the CAT
     Working Group or other WWW security specific discussion in the
     HTTPSEC Working Group.


Open to discussion:  should the working group discuss other ``socket
layer'' mechanisms or proposals?

There is a need to use common structures to be able to interact with the
work of other working groups like IPSP and IKMP. Also to have handy
roots.


SSL Working Group Proposal


         Chair:   Taher Elgamal <[e-mail]>
          Area:   Security
 Area Director:   Jeff Schiller <[e-mail]>
  Mailing list:   [e-mail]
  To subscribe:   [e-mail]


Implementations and Presentations

   o SSLREF
   o Australian implementation
   o MarketNet
   o OpenMarket


The Current Draft

The current version is draft-hickman-netscape-ssl-01.txt.  Changes from
the previous draft:


   o Backward compatibility with previous system.

   o Key exchange modifications:

      -  Added DH key exchange in different flavors.
      -  Maintain requirement for server authentication; client
         authentication happens on-line.


   o Changed the secret in the MAC computations to work with hardware
     tokens.

   o Changed the finish messages to hash all negotiation exchanges and
     prevent cipher-specs attacks.

   o Added certification chain support.

   o Security escape for key re-negotiation for long sessions.

   o Detecting ``last record'' using a security escape.


Future Plan for SSL Working Group


     July 95   Charter agreement
  October 95   Next draft
 November 95   Final notice for the working group
 December 95   Final notice for the IESG


Discussion

The charter that Taher Elgamal is trying to write says specifically that
the group is not going to write what the relationship is; SSL was
implemented originally at Netscape, but SSL should be at the application
layer.

Someone mentioned that the SSL application is built into the top of the
stack so it is transparent to the application.  Taher confirmed that it
is, but all you have to do is provide another port number and then you
have built the secure applications.  It is easier to deploy a socket
layer solution that actually changes IP stack, that is, which SSL works
and will continue to exist for a while until the world agrees on the IP
security method.

An attendee asked for confirmation of the understanding that IPSP will
obsolete SSL. Taher responded that it absolutely will.  From the
beginning it was developed with that in mind.  However, until then, we
have to have the current system going, which is, people do SSL whatever,
we still regulate how it is done.

It was pointed out that, at the same time, SSL is not an standard.
Taher asked what ``standard'' means?  There are a million copies of SSL
deployed.  He is concerned (because he works for Netscape) since it uses
the Internet and he would like to reach a consensus.

An inaudible question(s) was asked by the audience.  Taher asked what
the differences is?  The completely independent SSLREF is a Netscape
implementation that corresponds to what Netscape feels, and the
Australian implementation is completely independent.  They are
inter-operable and they use the same socket.

It was asked if there are other applications written on top of SSL
besides the Netscape product?  Taher confirmed that there is another
application written in England, but that he does not know if it is
deployed yet.  There is also SSL licensing by other companies; there are
a couple of licenses for SSL.

An attendee was wondering if SSL can be used for multicast.  Taher said
that it cannot and that there are not really any plans to do it because
they would like to first finish the current plan.

Taher said that the goal is to take the SSL work and kind of regulate in
the way that we all agree on it.  He is not trying to solve all the
world problems, but would like people in the audience to share their
experiences and discuss the draft that was put out, and in some months,
to come out with some document that all can agree on.

Try to be generic, using SSL as the base for it, and maybe there is a
point in doing security at the socket layer.  There will not be future
licensing needs, there is no licensing for a specification.  The
intention is really to get an agreement.  It could have some communality
with work done in the IPSEC Working Group.  The latest draft has some
inputs of what is being done in IPSEC.

Netscape has to make the router configurable, or the work has to be
marked clearly saying that this is something you can do but implementing
this does not mean you will be able to talk to SSL routers.  Within this
year, a router that does precisely that will be implemented by Netscape.
The router will have different functions, and e-mail, etc., will have
different flavors.

There is the question of trust (e.g., for e-mail) and it is a difficult
task.  OK, but PEM failed, and the reason is that lawyers were invited
in and they drafted a contract that has very wide implications and risk
of liabilities for the companies trying to get into the framework of the
work being done at PEM. It was pointed out that the group is not here to
discuss exports issues, otherwise, the topic would never end.

There was a floor discussion in the aspects of licensing, CAs and roots
for certification.  These roots should be easy to get in order for the
standard to fly.  There is the effort to be common in the root hierarchy
such that SSL and SHHTP will be able to use the common hierarchy.

Why not have a SSL Internet standard?  There was comments from the floor
in favor and against.  Will the engineering coming from the working
group be accepted from the vendor (Netscape) or just ignored?  Is
security a good thing just by itself?  Yes, but that depends on if
Netscape will accept the outputs from the working group.

If there are different groups coming here with different ideas, it is
not a sign for success.  Also, we cannot define something that Netscape
will follow.  It is important to set up clear goals for the working
group to be successful.

One of the problems with IPSP work is that it needs to be able to access
the kernel, but SSL uses the session layer which gives the solution for
the user with no kernel access.  The implementation from Netscape
replaces the Unix Socket and that is the reason for the name SSL. There
is also a need for being used in UDP not just TCP.

The actual specifications of SSL ties with X.509, but the majority feel
the need to be expanded to others like the PGP structure.  The group
cannot be so general that it will lead to a situation where at the end,
even at the application layer, the kernel will need to be modified.

Since the X.509 is not in existence now, it could be a problem.  To
which Taher answered that Netscape does not need X.509 to operate.

Netscape is offering a proposal as a starting point and the working
group will be able to elaborate above it.  This is a possibility to
avoid the problem of the migration that IPSP has because IPSP operates
in a modified kernel.

The only way to operate with Netscape today is by being part of their
customer base.  It is more difficult to have a hierarchy that will use
more than the Netscape customer base.

At this stage, SSL and S-HHTP will be distinct protocols indefinitely,
whatever implication and key manager is something that will come from
the work of each group.  So the transactions with S-HHTP and SSL will be
able to inter-communicate.

One concern is that the more things that are bundled together, the more
vulnerable we are to interruptions and breakings.  One characteristic of
SSL is that it bundled the protocol integration of how to protect the
socket protocol along with the mechanism that implements that.  But it
may be preferable for something that works at the socket and does not
need to go to the kernel.

There was a discussion of the need for a working group.  It was felt
that if a working group is not formed, Netscape can go ahead with
whatever plans it has and there will not be any chance to interact and
somehow influence something that could dominate the market.  There are
people today looking into using SSL for more than just for browsers.
There was agreement to form a working group and discussion will be moved
to the mailing list.