NEW DRAFT: Regularizing Port Numbers for SSL.

I believe that this new draft addresses the concerns brought up on the
SSL-Talk and IETF-TLS lists, yet still allows us to move forward for those
who need to interoperate now.

If you have any comments about these specific requests, please cc: both
lists, <SSL-Talk@netscape.com> and <ietf-tls@w3.org>. However, any comments
regarding requirements for single port/port mapping solutions should be
exclusively on <ietf-tls@w3.org> as that will be in our queue for future
standards work.

I will be sending the final version of this request to the IANA on
Wednesday, November 12th.

---------
The SSL 3.0 protocol has the broadest implementation of any security
standard to date, with both Netscape and Microsoft using it in their
popular servers and browsers. SSL 3.0 has been submitted to the TLS working
group of the IETF, and is is proceeding out of internet-draft status under
a new name, TLS.

Tim Dierks and I are editors for that working group, Win Treese
<treese@OpenMarket.com> is the working group chair, and Jeff Schiller
<jis@mit.edu> is the IESG area director over the WG.

Tim are I have two documents undergoing revision:
<draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>, which
were approved during the last working group meeting in San Jose, and are
being merged into one draft as we speak.

One area that I am trying to resolve are the port and port naming issues
with TLS/SSL.

As a transport layer security standard, TLS/SSL can work transparently with
existing application level protocols (such as http, nntp, nttp) without
*any* change to the protocol other than using a different port number. As
an example, the popular http protocol uses port 80, and the SSL enabled
version of http uses 443.

It is possible for a single port to be used for both unsecure and secure
uses, however, this requires two things:

	* Changes in the application level protocols which must
          be separately adopted by each working group over such
          protocols. An example of changes that would allow for
          a single port in the FTP protocol is covered in
          <draft-murray-auth-ftp-ssl-00.txt>

        * Support by firewalls to understand and resolve
          use of a single port for both unsecure and secure uses.

It is also possible that there could be a single port/port mapping solution
to allow any protocol to be used with TLS without port proliferation,
however, after considerable discussion in the TLS working group there is no
easy design that resolves both architecture and security issues. We have
agreed to add to the TLS agenda and charter to resolve this problem in the
future.

Thus, until each protocol is revised to allow for authenication under a
single port, or a single port/port mapping solution is architected, we will
require separate ports for TLS/SSL implementations of the most popular
protocols.

There are a number of ports currently registered with the IANA the for use
by the SSL protocol. They are:

	https       443/tcp	https
	ssmtp       465/tcp	ssmtp
	snews       563/tcp	snews
	ssl-ldap    636/tcp	ssl-ldap
	spop3       995/tcp	SSL based POP3

As the above registrations are inconsistant, and most don't even mention
SSL or TLS, we would like to get these port assignments and names
regularized in the listing as follows:

	https       443/tcp	http protocol over TLS/SSL
	smtps       465/tcp	smtp protocol over TLS/SSL (was ssmtp)
	nntps       563/tcp	nntp protocol over TLS/SSL (was snntp)
	ldaps       636/tcp	ldap protocol over TLS/SSL (was sldap)
	pop3s       995/tcp	pop3 protocol over TLS/SSL (was spop3)

There is also currently a desire among existing SSL implementors to
register a number of additional ports mappings for other protocols such as
ftp. We want to avoid port proliferation as much as possible until we have
a long term solution, so we have limited these requests to those protocols
in which we have recieved commitments from a minimum of 2 independent
implementations by developers.

We have been told that some of these invididual implementors may have
attempted to register ports for these uses of SSL, but as of today they
have not recieved registration for these assignments.

We would like to suggest the following:

	ftps-data   889/tcp	ftp protocol, data, over TLS/SSL
	ftps	    990/tcp	ftp protocol, control, over TLS/SSL
	imaps       991/tcp 	imap4 protocol over TLS/SSL
	telnets     992/tcp  	telnet protocol over TLS/SSL
	ircs        993/tcp  	irc protocol over TLS/SSL

I also have a question -- who requested the following service? We don't
know if it is our SSL or something else with the same acronym.

	naming-iiop-ssl 261/tcp    IIOP Naming Service (SSL)

Under your procedures, you ask for answers to the following questions:

1)  What is the protocol between the user machine and the server
    machine?

It is the TLS 1.0 or SSL 3.0 protocol as defined in
<draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>.

2)  What message formats, types, op codes, sequences are used?

It is the TLS 1.0 or SSL 3.0 protocol as defined in
<draft-ietf-tls-protocol-00.txt> & <draft-ietf-tls-ssl-mods-00.txt>.

3)  What functions are performed by this protocol?

Securing and authenticating the transport independently of the application
protocol.

4)  Is broadcast or multicast used?  If so, how and what for?

No -- TCP only is defined by TLS/SSL at this point, however, we'd like to
at least hold the UDP ports in reserve for the future.

5) Do you want a well-known assigned system port in the range 0-1023,
   or a registered user port in the range 1024-65535 ?

They need to be in a the well known range as they are largely being
implemented initially by unix developers who want to be sure that it is the
well-known range.

6)  What short name (14 character maximum) do you want associated with
    this port number?

	ftps-data   889/tcp	ftp protocol, data, over TLS/SSL
	ftps	    990/tcp	ftp protocol, control, over TLS/SSL
	imaps       991/tcp 	imap4 protocol over TLS/SSL
	telnets     992/tcp  	telnet protocol over TLS/SSL
	ircs        993/tcp  	irc protocol over TLS/SSL

If there are any questions as to our authority to request such changes,
these changes have been run by the WG Chair, Win Treese
<treese@OpenMarket.com>and Jeff Schiller <jis@mit.edu> is the IESG area
director over the TLS WG. In addition, these requests were run by Netscape,
Microsoft, the SSL-Talk mailing list and the IETF-TLS working group mailing
list, and rough consensus was achieved before being sent to you.

If you have any questions, please feel free to give me a call at
510/559-1500 or email me at Christopher Allen <ChristopherA@consensus.com>.


------------------------------------------------------------------------
..Christopher Allen                  Consensus Development Corporation..
..<ChristopherA@consensus.com>                 1563 Solano Avenue #355..
..                                             Berkeley, CA 94707-2116..
..Home of "SSL Plus:                      o510/559-1500  f510/559-1505..
..  SSL 3.0 Integration Suite(tm)" <http://www.consensus.com/SSLPlus/>..

Received on Friday, 7 February 1997 17:28:49 UTC