SOI QUESTIONS: 2.3 Authentication styles

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

[Sorry, I screwed up the subject line on my last e-mail message; So I've
re-issued the question in the hopes of reducing confusion....] 

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, the implications are really 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?  (Or just certificates-only?)

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