[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Using Legacy Authentication for IPSRA (was : xauth requirements: vulnerabilities)
"Scott G. Kelly" wrote:
> I've been thinking about this, and believe that perhaps the thread is
> improperly named.
Hence I've allowed myself to change the name of the thread. I think
that this is the problem that we should discuss.
> I began the discussion because I believe that we need
> to understand the remote access problem space before we can
> intelligently discuss solutions, and security vulnerabilities are a part
> of the problem space. At the same time, I've been trying to get someone
> to explicitly state the rationale for xauth in terms of requirements,
> and I think this may be confusing people. I should have separated the
> two discussions.
The problem as I see it : provide IPSec with an authentication of a user
with a non fixed or fixed IP address (i.e. the IP address he uses is irrelevant to
the authentication process). Ofcourse security vulnerabilities are an important
part of this problem, after all these are the issues we discuss in this area, but
in several levels.
I think that the a possible architecture for a solution could be a modular
that consists of an authentication mechanism that provides user authentication and
that conveys this information to either IPSec or IKE. This solution is different
from the current IKE
approach to authentication in which the authentication is an integral part of the
> > Even the stongest PKI and Public key cryptography used will not save you
> > from
> > an unprotected private key.
> Yes, I agree.
In this proposed architecture, the above problem is a security vulnerability of
authentication mechanism, or to be precise, of the implementation of the
> > I think we should separate the authentication mechanism (e.g. certificates,
> > SecureID, RADIUS)
> > from the suggested IKE extends authentication protocols.
> > The vulnerabilities you've stated refer to the strength of authentication
> > mechanism that is used
> > , and to the correctness and the security of its implementation.
> They also refer to the motivation one might have for seeking to somehow
> improve upon the authentication mechanisms built into IKE, which is what
> I had speculated that xauth/hybrid might be meant to do. We all agree
> that PK authentication may be very strong, but as you pointed out, an
> unprotected private key invalidates this supposition. Again, the
> vulnerabilities are but one aspect of the set of factors from which we
> derive requirements.
We are seeking to improve the authentication mechanism built into IKE.
One possibility is to improve security, which is what you refer to.
Another way is to improve the ability to deploy IPSec, and to increase the
number of scenarios in which IPSec can be used. These two goals might be
contradicting, but we as engineers must make the trade-offs and come
up with a reasonable set of solutions.
> > I think that we all agree that the preferred authentication mechanism is
> > user certificates, but
> > we also realize that reality and the market requirements require the work of
> > other authentication
> > mechanism.
> > The purpose of the suggested extend authentication protocols is to convey
> > these authentication mechanisms into the existing IKE protocol.
> This gets to the heart of it, I think. There seems to be a market
> "requirement" which has driven xauth, that being that administrators
> think they want security, but they also have a conflicting desire, i.e.
> to continue using their currently installed weak authentication
> mechanisms. A remote access working group has been proposed, and I would
> hope that the purpose of this group would be to actually examine the
> remote access problem in depth and propose good, solid solutions, as
> opposed to simply rubber-stamping the existing proposed mechanisms
> without further thought.
"rubber-stamping" is one way of looking at the integration of legacy
into IPSec. There are others.
> > Let's separate the requirement from the actual authentication mechanism, and
> > the requirement's from IKE authentication protocols.
> Yes, I agree that we need to derive the remote access requirements
> independently of any existing proposed solutions.
> > I suggest that we will enable this integration into IKE, and that we will
> > have a set
> > of minimal requirements from an authentication mechanism that fits into the
> > (future)
> > IP Secure Remote Access framework. An example requirement might be
> > if you use two factor authentication, then store the
> > two factors (password, smart card) in different places...
> > I think is that we are trying to understand what XAUTH and the other
> > protocol are solving
> > and not solving, instead of stating what are the problems and the
> > requirements.
> > I think this is the wrong way to go.
> I think I agree with you, and I'll feed back what I think so you can
> correct me if I'm missing the point. We need to discuss the requirements
> for secure remote access using ipsec. It is important that we not be
> confused by arguing about whether existing mechanisms meet the
> requirements when we have yet to explicitly state them. We should first
> determine the requirements, and then discuss how individual mechanisms
> meet (or don't meet) subsets of them.
I think we should go to the modular approach, this way we'll separate the
authentication mechanism from the protocol. This way the protocol can be
used to add to the security of an underlying authentication mechanism.
As for the requirements from the authentication mechanisms. Here I suggest
we keep in mind what Jeff has reminded us during the IPSec session in Oslo.
We are an ENGINEERING task force.
We already have a good, scalable and secure authentication mechanism, namely
user certificates. The problem is that it is hard to deploy. I think that in this
we should try to avoid (if possible) inventing a new authentication mechanism.
There is an existing wide variety of authentication mechanism, some of them (with
right protocol protecting them and relaying the authentication information to
might be appropriate for us.
I think we should specify the requirements, and suggest several (preferably
For each mechanism we should specify the trade-off, and declare the security risks
he and his organization are exposed to if he uses this mechanism. We should
remember that security and engineering is all about trade-offs.
Let's look at IKE as an example. We have authentication methods that use user
and pre-shared secret. We all know that pre-shared secrets authentication has it
(in addition to the scalability problems). But if pre-shared secret authentication
in IKE, IPSec would not have been as deployed as it is today ( I even think IPSec
wasn't here today
if pre-shared secret authentication hadn't exist). We had suggested a good
and a worse one. We've pointed out the trade-offs, and let the users make their
I think we should approach the IPSRA problem in a similar way,