Subject: continuing the discussion on complexity (long post)

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 12 Jul 2001 10:07:46 -0700

This is to continue the discussion of complexity as it relates to the
legacy authentication problem and security. Think of it as me thinking
out loud. I'd say "feel free to disagree, criticize, etc.", but I don't
think anyone will be shy about that...

Clearly, anything we do is going to add complexity to the overall system
of remote user and whatever systems he must interact with (IRAS, AS, CA,
or whatever). As Hugo pointed out in an earlier post to the ipsec list,
nothing is free, and added security typically means added complexity
(as does added functionality).

I don't think anyone would disagree that as code becomes more complex,
it becomes more difficult to assert that it does exactly (and only) what
it is intended to do. On the other hand, we want our systems to deliver
more and more functionality, so we typically choose to accept some risk
in exchange. Normally, the additional incurred risk is mitigated through
conscientious and well-thought-out testing, but no matter how careful we
are, we cannot typically be certain that we've thought of everything. 

Obviously, the level of effort we devote to careful design and testing
is proportional to the value the subject system (or program) provides,
and to the risk we face in case of malfunction. If an error is likely to
carry a high price tag, we tend to be much more careful in our approach,
and rightly so. In such cases, we have to balance the desire for added
functionality against the cost of system failure. In cases where the
cost of failure is relatively low, we may choose not to concern
ourselves with this. In cases where the cost might be very high, we
often look for ways to improve the likelihood that failure will not
occur. 

Perhaps the most obvious way to reduce risk is to simplify the system in
every way possible. The simpler the system, the more likely it is that
we may accurately characterize and understand it. However, in some cases
this may lead to unacceptable functional loss, and in such cases we must
either give up entirely, or add the functionality anyway, and attempt to
derive a test plan which gives us a relatively high level of confidence
in the stability and resilience of the subject system. Numerous
considerations must be weighed against the desire to reduce complexity.

An IPsec security gateway is a very complex system. To some extent, this
is unavoidable, as the underlying functionality requirements demand it.
For many security gateways, the cost of some types of failure could be
extremely high. In order to limit exposure, the designer of such a
system has two options: simplify wherever possible, and test as
thoroughly as practicable. Unfortunately, IETF standards do not
prescribe test procedures, nor should they. This might lead one to ask
whether it might not be most appropriate to be conservative with respect
to complexity when producing an IETF standard for a security system.

It should also be noted that security requirements vary by circumstance.
In some cases, it is imperative that communications integrity be as
nearly absolute as may be obtained. In other cases, where the cost of
integrity loss is lower, it is not as important. In between, there is
something of a continuum along which other deployments may be placed
according to circumstance. When there is a desire to create a product
anywhere along this continuum, there is a tendency to select the least
costly mechanism which suffices. When creating networking products,
there is a simultaneous desire to standardize the solution.

Clearly, we cannot standardize individual solutions to meet the needs of
every discrete situation along the security spectrum. The more
reasonable solution is to select a manageable subset, and let folks
choose the closest fit. In terms of both of getting the work done and of
making the number of choices reasonable from a security perspective,
less choices are better, as the alternative is to place additional
deployment complexity squarely in front of the user, and hope that they
make the right choice.

It should be noted that a solution which satisfies the most stringent
security requirements will meet the security requirements of all, and
that such a solution is required if we are to meet the needs of the high
end of the spectrum. On the other hand, this solution may prove too
costly for those with lesser security requirements. For some of these
cases, we already have at least one standards track alternative: L2TP 
in IPsec. So, we need a very strong mechanism, and we have a 
middle-of-the-road mechanism. Do we need more than this? Maybe not - but
this question must be definitively answered.

----------------------------

As regards our problem, IKE provides no support for username/passphrase
authentication, but the market clearly requires this support if IPsec is
to be used for remote access. It has been argued that IKE is too complex
already, and that if possible, a solution which requires no changes to
IKE should be found. What is the basis of this argument?

IKE, due in part to the general design of ISAKMP, supports a large
number of options in various combinations. The preceding complexity
discussion illustrates why this entails more risk from a security
perspective than a simpler more limited key exchange protocol
implementation might. It is very difficult to guage the effect of
interactions between the code implementing various options in varying
combinations, and put simply, it requires lots more code, implying the
likelihood of more undetected bugs. Bugs in security gateway code could
result in system compromise. Adding functionality to this code base
simply serves to increase this risk. This has prompted the call for
proposals for independent solutions which do not modify IKE.

The point has been made that PIC/GetCert + enrollment is more complex
than hybrid (or whatever). In a global system sense this is certainly 
true. However, it is not true with respect to the security gateway if
the AS is a standalone system. That is, this particular approach may be
implemented without changing the underlying IPsec implementation. This
means that the code running on the security gateway is less complex than
it would be otherwise, and that from this we gain some relative
assurance that we have not introduced new problems into the gateway
code. This may or may not be an important consideration, depending upon
the exposure in case of gateway failure.

Now, is the gateway actually more secure with an outboard AS
implementation than it would be with simpler changes to IKE? Well...
we don't know for sure. What we may believe is that it *probably* 
is, or that it might be. On the other hand, if we implement the same
solution on the gateway rather than on a standalone AS, we have
certainly increased the code complexity on the gateway. Hence, by
the same reasoning we must conclude that the security of the gateway
may be reduced due to this added complexity, especially when
compared with a similar system implementing a simpler mechanism.

Additionally, with the choice of PIC or GetCert, the remote access
client code will be more complex than it could be with some other
approach. In order to isolate the legacy user authentication operation
from IKE, it is necessary for this operation to produce a credential of
some sort which may be used in subsequent IKE communications. This
credential may be either a public key certificate, or a shared secret.
The client must interact with the AS in order to obtain this, and then
make it available to the IPsec subsystem.

If we choose a shared secret, this must be distributed to both the
remote client and the gateway upon successful user authentication. Even
if a standalone AS is employed, this still increases code complexity on
the gateway. If failover and/or load balancing support is provided, the
secret must be provided to all participating gateways prior to providing
it to the client, and this significantly increases gateway code
complexity regardless of where the AS is implemented. 

If we choose the certificate, no interaction is needed with
participating gateways, though the gateway(s) must have a mechanism for
verifying the certificate. If the client certificates are sufficiently
short-lived, gateway possession of a valid verification certificate may
be sufficient in this regard. Otherwise, CRL or online status checking
is required. However, these functionalities are required for
site-to-site gateways as well. If the AS is implemented in the gateway,
either an outboard CA function is required, or all associated
failover/load-balancing gateways must share the signing key.

It seems clear that if we allow the AS to co-reside on the gateway, the
code complexity is significantly higher than with other IKE-based
techniques which do not provide a reusable credential (due to the
certificate generation functionality). Hence, from a security
perspective, there is some likelihood that we are better off to use an
outboard AS for this particular solution type. On the other hand, this
adds overall solution complexity for system as a whole, and for the
user. It may increase gateway security, but it costs more. There may
also be a question as to whether this added complexity serves to 
decrease the overall remote access system security.

If we choose one of the other proposed IKE-based solutions, what do we
gain (or lose)? Eliminating the need for a CA component reduces cost and
system complexity, but also eliminates the single sign-on capability a
short-lived certificate would provide. Additionally, it may provide less
market incentive to move to stronger user authentication mechanisms. On
the other hand, when compared to a gateway AS implementation, the
alternative mechanisms likely result in significantly less complex
gateway code than the AS, but there would still be a net complexity
increase.

It seems that no matter which solution we choose, we must accept some
increased complexity in exchange for the added functionality. Also, the
two proposed solution classes offer different features, and the need for
these features must be weighed against the security requirements and the
desire to reduce complexity. If single sign-on and PKI migration are
important goals, these will drive the solution in one direction. If not,
there is far less justification for the AS approach. 

-------------------

Scott

---

From: "Kavsan, Bronislav" <[email-masked]>
Date: Fri, 13 Jul 2001 09:10:46 -0400

My comments:
- IKE/IPSec doesn't have a monopoly on the need for authentication - legacy
or otherwise.
- Therefore complexity of this problem is better solved by sharing this
burden amongst applications and technologies that are consumers of the
solution and will share its benefits.
- PKI-based authentication is a very good unifying authentication
instrument, but it is complex - effort targeted on reducing PKI complexity
will benefit us more than localized efforts targeted on reducing IKE
authentication complexity
- "Virtual smart cards" carrying PKI credentials can be issued and accessed
using legacy authentication methods, sort of legacy->PKI bootstrapping,
which in turn can be used by IKE/IPSec, SSL, DigSig, Authorization,
Messaging, etc, etc...

Assuming above premise - separate IETF body should address this topic on
behalf of this and other WGs.

Slava

-----Original Message-----
From: Scott G. Kelly [mailto:[email-masked]]
Sent: Thursday, July 12, 2001 1:08 PM
To: ipsra list
Subject: continuing the discussion on complexity (long post)

-------------------

Scott