# RootPrompt.org   Nothing but Unix.[Home] [Features] [Programming] [Mac OS X] [Search]


 Feature: A Response to the feature on IPv6 vs. SSL

Jeremey Barrett has written a response to the Feature: Can IPv6 replace SSL?.

SSL and other transport-layer protocols provide _additional_ and _different_ security functionality that IPsec (and hence IPv6) will never provide. For example, SSL provides authentication _of a particular user or person_ over an encrypted connection to a service. IPsec only provides security between the machines. Many SSL applications, such as Netscape's web browser, provide the user with the ability to control what level of security he uses. IPsec will never offer this sort of control to (most) end users; that isn't its purpose."

 (Submitted by Noel Mon Jun 5, 2000 )

  

A Response to the feature on IPv6 vs. SSL

by Jeremey Barrett <jeremey@terisa.com>

Reto Haeni's paper on IPv6 and SSL explains a number of fundamental differences between the two protocols but fails to communicate why they are different. It is also quite out of date (it appears to have been written in 1996) and as a result some of its facts are no longer true. The paper is misleading (though clearly not intentionally) due to its age and its failure to address the differences between SSL and IPv6 adequately.

IPv6, or more to the point, IPsec is designed to provide host-to-host, subnet-to-subnet, and host-to-subnet encryption and authentication, as stated in Haeni's paper. Most often it is likely to be used in either a subnet-to-subnet model, where the goal is to encrypt the traffic between two networks, or host-to-subnet model, where the goal is to encrypt traffic from one machine to a network. The first model is typical of "virtual private networks," or VPNs, where two geographically separated networks in the same organization are connected to each other over the Internet by means of an encrypted IPsec tunnel. The second model is typical of "road warriors," workers on the road, who wish to securely connect to their organization's home network to access some service.

IPsec is also critical for securing the Internet infrastructure by encrypting all traffic on the Net. If every gateway to a subnet is IPsec-enabled, then traffic between it and every other subnet can be encrypted and authenticated. This is important for data security, privacy, and prevention of many kinds of cracker attacks that happen now.

However, IPsec secures traffic between _machines_, not people. There are many applications of encryption and authentication that IPsec does not and should not address.

SSL and other transport-layer protocols provide _additional_ and _different_ security functionality that IPsec (and hence IPv6) will never provide. For example, SSL provides authentication _of a particular user or person_ over an encrypted connection to a service. IPsec only provides security between the machines. Many SSL applications, such as Netscape's web browser, provide the user with the ability to control what level of security he uses. IPsec will never offer this sort of control to (most) end users; that isn't its purpose.

Because SSL can authenticate users as well as machines, it can be used to provide all kinds of secure, per-user access control which IPsec cannot provide. Different services running on the same machine may allow very different access privileges to the same user, a scenario which is impossible for IPsec to handle since it authenticates machines, not people.

Further, SSL provides end-to-end security, whereas IPsec may only provide security from one subnet to the other. IPsec is unlikely to provide much data privacy to users behind a subnet-to-subnet IPsec model. SSL provides encryption _from the end user's application_ through to the other end, the recipient application.

One can draw an analogy from package shipping. IPsec is akin to taking a document that you want delivered securely and handing it to the shipping person in your company, who hands it to someone else, etc, until it eventually gets put into a locked safe on the loading dock and then is handed to the package shipping company. The process is reversed on the other end.

SSL, on the other hand, is akin to taking your document and sealing it in a locked, unbreakable envelope which is completely inaccessible without the right key. The envelope is _then_ handed to the shipping people and off it goes. Only the end recipient has the key. It may go through the above process as well, or it may not, but you are certain of its security regardless.

It is clear that both of these models are important and useful, but in no way are they mutually exclusive; rather, they complement each other. SSL (or other transport-layer security mechanisms) will always be necessary and important, regardless of the security offered at the IP layer. The best of all worlds is SSL on top of IPsec, where the traffic between machines or networks is encrypted and authenticated, and then further security is layered on top at the transport layer, providing user-level authentication and end-to-end security.

My conclusion in comparing IPv6 (specifically its IPsec component) and SSL is that both are required and neither is sufficient on its own to provide the kind of security, authentication, and privacy that the Internet desperately needs.

I would also like to address some of the inaccuracies in Haeni's paper (many of which draw simply from its age):

  • Haeni states, "While Netscape uses its SSL version 2 in the Netscape Navigator browser, IPv6 is implemented only by multiple organizations in research projects."

    The "current" version of SSL hasn't been 2 for a long time... SSLv3 and TLSv1 are now the SSL standards in use. Both were much more rigorously designed than SSLv2, and TLSv1 is an IETF standard just like IPv6.

    Also, quite a number of SSL implementations exist, some of the best of which are open-source.

  • Haeni states, "One of the most important mechanisms, the key exchange, is still not defined for the IPv6 protocol."

    This is no longer true. It has little bearing on the paper or my response, but it is worth mentioning.

  • Haeni states, "The security specifications are clear enough to conclude that the IPv6 protocol has enough security capabilities to provide better authentication and confidentiality than SSL in general."

    This just isn't true; SSL and IPv6 address different security issues, though some of their respective capabilities are similar. I have attempted to show this clearly above.

  • Haeni states, "SSL has a specific port number assigned that is dependent on the application protocol where SSL is located in the next lower layer. Until now, there are three port numbers assigned by the IANA (The Internet Numbers Authority) and therefore can be used with SSL. These are: HTTP, NNTP, SMTP."

    It may be that the IANA has only assigned ports for these SSL-enabled protocols, but SSL can be used for many, many other things. It is in no way limited by the choice of application protocol. That Haeni makes this point seems to indicate that he is looking at SSL as if it were intended to accomplish the same goals as IPv6; it is definitely not, except in the very broad sense of security and authentication.

  • Haeni states, "While SSL is used for host-to-host or mostly host-to-server services, IPv6 can be used for host-to-host, host-to-subnet and subnet-to-subnet authentication or encryption."

    Haeni fails to differentiate SSL "host-to-host" from IPv6 "host-to-host." They are very different. Perhaps SSL "host-to-host" should really be called "application-to-application." This is a fundamental difference as I pointed out above.

  • Haeni states, "While IPv6 provides stronger authentication and confidentiality in all cases over SSL..."

    This statement isn't true. It might be true that in a particular setup IPv6 encryption is stronger than SSL if, for example, a user is using an export-only web browser for SSL and the IPv6 setup uses 3DES. However, the situation could easily be reversed and the SSL could be stronger.

    In addition, the authentication offered by IPv6 may be as strong, weaker, or stronger, but the comparison makes little sense given that the type of authentication and its intent are very different.

I would appreciate comments on any of this. As always, my views are my own and no one else's and they do not represent my employer in any way.


Our content can be syndicated: Main page Mac Page

Copyright 1999-2005 Noel Davis. Noel also runs web sites about sailing and kayaking.
All trademarks are the property of their owners.
All articles are owned by their author