Re: SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS)

[Dan McDonald <danmcd@east.sun.com>]

> 2.3.A.)  Does SOI need to natively support "legacy authentication
> systems"?

Absolutely not!  As pointed out by Ted, there is an IPSRA working group for
such problems.  As such, people interested in remote access should be hanging
out there.

IKE is for much more than remote access.  While a very important application
of IPsec technologies, remote access shouldn't hijack control of what can and
should be a general-purpose security toolset.

> 2.3.B.)  Does SOI need to natively support some kind of "shared
> secret" scheme?
> 
> (Note. If SOI is provides cert-only, then one would need to use
> another protocol to bootstrap certificates from a legacy
> authentication or shared secret scheme.)

If self-signed certificates are supported, how is this different from a
shared-secret?

My answer is if we don't support shared-secret, we MUST support self-signed
certificates.

> VPN:  <<<In the case of dynamic IP addresses and/or NAT boxes, IP
> addresses cannot be used as phase 1 identifiers. This also means that
> the authentication material cannot be chosen based upon the IP address
> in the packet.>>> [[[2.3]]]

Self-signed certificates solve this problem, while not invoking the cost
of a PKI.

> SRA: <<<This means that there must be a way of securely pushing down
> this policy information before the IPsec tunnel is constructed.>>>
> [[[2.3]]]

Two words:  Transport mode!

You can perform an IPsec-protected transport mode exchange to get tunnel
plumbing information, and then feed that into the local tunnel-plumbing
code.

> SRA: <<<The mechanism associated with such authentication should
> accommodate re-authentication based on the RAS or authentication
> server site security policy>>> [[[2.3]]]

Again, this can be done with transport mode.  Have a daemon/agent running
that responds to requests for re-authentication.

> SRA: <<<Out-of-band authentication mechanisms must also consider the
> location of the authentication server relative to the client and the
> RAS. In many scenarios, server tends to be "behind" the RAS device, in
> the domain that is being secured by the RAS, which may be problematic
> for bootstrapping the user authentication for the client-to-RAS
> connection.>>> [[[2.3]]]

IMHO, you should use a certificate or something else for the IPsec part of
RAS.  If you use a legacy authentication for even the bootstrapping phase,
you are weakening the overall security of your IKE exchange, and hence your
IPsec SAs as well.

Dan