SOI QUESTIONS: 2.3 Perfect forward secrecy (PFS)

["Theodore Ts'o" <tytso@mit.edu>]

Notes from the chair:

As we had noted earlier, the "implications from the scenarios" only
loosely seem to correlate with the questions implicit the soi-features
document.

Fundamentally, this is about a philosophical question of whether
policy-related functionality (especially those which are related to the
Secure Remote Access scenario) should be part of "Son of Ike", or
whether it should be separated into another protocol.

The fact that there is an IPSRA working group is a fairly strong
argument that remote-access specific functionality should be handled by
another protocol.  This would also have the advantage of keeping the
core key management protocol small, such that applications which were
not specifically about remote access (i.e., iSCSI, secure telephony,
pure VPN applications, end-to-end authentication using IPSEC, etc.)
would not have to their implementations bloated by functionality that
they don't need.

On the other hand, there seems to be a very strong remote access
contingent in this working group who seems to be very concerned about
the protocol overhead inherent in separating remote access functionality
from the core key management protocol.   

Again, IPSEC working group --- please discuss:

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

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

Implications from the Scenarios:

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

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

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

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