[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: xauth requirements: vulnerabilities

Hello Scott!

I would like to refer to the vulnerabilities you've stated here.

I think that the problems you raise here are out of the scope of specific
that you are referring to, namely IKE, XAUTH, hybrid and I am sure I could
many others.

Even the stongest PKI and Public key cryptography used will not save you
an unprotected private key.

I think we should separate the authentication mechanism (e.g. certificates,
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.

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

The purpose of the suggested extend authentication protocols is to convey
these authentication mechanisms into the existing IKE protocol.

Let's separate the requirement from the actual authentication mechanism, and

the requirement's from IKE authentication protocols.

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
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
I think this is the wrong way to go.

 Thanks, Sara.

"Scott G. Kelly" wrote:

> Sorry to keep hammering on this, but we need to make sure we've fully
> specified the requirements before we can reasonably discuss the efficacy
> of the proposed solution. I invite the various xauth and xauth/hybrid
> authors to contribute to this discussion, since you are the ones
> proposing solutions.
> So far, the following vulnerabilities have been identified in scenarios
> entailing using ipsec for remote access:
> (1) A system containing either a password (preshared key) or private key
> may be stolen, and the thief may now use the system to impersonate the
> owner, and access protected resources.
> (2) A system containing either a password (preshared key) or private key
> may be otherwise compromised in such a way as to give the attacker
> access to the password or private key, without the owners knowledge.
> This means that either a backup containing the information is
> stolen/copied, a copy of the system is somehow made without the owners
> knowledge, or the keys are somehow directly extracted. This information
> could be used to access protected resources directly, or to mount a
> man-in-the-middle attack on subsquent remote access sessions.
> (3) Rogue software may be installed on the system without the owners
> knowledge which monitors the user's typing and/or other aspects of any
> online session.
> Are there other vulnerabilities?
> Scott