[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposed Charter
Hello Scott!
"Scott G. Kelly" wrote:
> > Proposed Charter:
> >
> > The rapid growth of remote access and the subsequent transition from older
> > direct-dial remote access to Internet-based remote access is making an
> > impact on secure communications.
> >
> > IP Security (IPSec), as it is defined today, is missing key functionality
> > needed to effectively support Internet-based secure remote access as well as
> > being difficult to deploy to remote users such as road-warriors and
> > telecommuters wishing to connect back to their corporate networks.
>
> I believe the first part of this sentence is incorrect, and the second
> part is implementation dependent - I'll restrict my comments to the
> first part. I believe that all the "needed" mechanisms are present
> within IPsec as currently defined. PKI provides strong authentication,
> preshared keys provide weaker password-based authentication, and DHCP
> may be carried over the existing IPsec framework for other
> configuration. It seems that the real problem you wish to address is
> that some people are reluctant to deploy PKI and/or to abandon their
> previously installed "legacy" mechanism, and as a result, you are
> calling for us to integrate so-called legacy authentication mechanisms
> into IPsec.
I agree with you that we need to change the wording in the above sentence.
IPSec does have the required functionality (i.e. certificates), but in the current
status of PKI technology this functionality cannot yet be deployed in a scalable
fashion.
It doesn't matter if the reason is a financial one, an organizational one or just
as you define it "people are reluctant to deploy PKI and/or to abandon their
legacy
mechanism". It is a legitimate requirement that we as IPSec vendors must provide
an answer to.
I don't think we have the power to force customers to abandon their legacy
mechanism,
and I prefer to see them use these mechanism within a framework that we sa working
group will standardize, then to see allot of proprietary methods to use legacy
authentication
system with IPSec, some of them might turn out to be secure, but some probably
will
be insecure.
>
>
> It should be the goal of this working group to determine how to provide
> secure remote access using IPsec. If, in the course of researching this
> problem, it is determined that the existing framework does not support
> some required functionality, then these would be valid work items for
> consideration. However, I believe that beginning with the premise that
> IPsec does not provide the necessary and sufficient mechanisms is
> incorrect.
I agree that we should first define the problem, and then state the requirements,
but I also argue that the current IPSec provide the required answers, not from the
technology point of view but from other points of view.
We are not going change the current framework, and I believe that providing
support for
legacy authentication systems will create a migration path that will lead us to
deployment
of IPSec with PKI.
>
>
> > All these groups of users share the property that their IP address is
> > temporary and doesn't give any information about the identity of the user.
> > Although their temporary IP address is meaningless for IPSec, they still
> > require to become a part of a virtual private network, and to have access to
> > resources that are part of the private network.
>
> The statement "All these groups of users share..." is also incorrect.
> Some telecommuters have ISP-assigned stationary IP addresses.
Agreed, we'll change the wording.
> And again,
> PKI and preshared secrets makes this point moot - IP addresses are not
> the only identifier types supported by IPsec.
Preshared secrets with main mode with non IP address identifiers do not
work. Certificate authentication with non IP address identifiers
is exposed to denial of service attacks.