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

Re: xauth requirements: vulnerabilities

Hi Sara,

Sara Bitan wrote:
> 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
> protocols
> that you are referring to, namely IKE, XAUTH, hybrid and I am sure I could
> specify
> many others.

I've been thinking about this, and believe that perhaps the thread is
improperly named. 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.

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

Yes, I agree.

> 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.

> 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.
> 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.