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

Re: SOI QUESTIONS: 2.3 Authentication styles



There was no technical reason given for rejecting L2TP+IPsec as a remote
access security solution in this working group.

I wonder if there is any technical reason for requesting adding remote
access functionality to SOI now.

    thanks,
    chinna

On Tue, 18 Jun 2002, Theodore Ts'o wrote:

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

__
chinna narasimha reddy pellacuru
"Moral Clarity: Def. When you do it, it is moral relativism, when I do it,
it is the repudiation of moral equivalence."