RE: SOI QUESTIONS: 2.3 Authentication styles

[rcharlet@SonicWALL.com]

Howdy,

	I do not see the (real) "simplification" effect of our proposed successors to be a strong enough justification to replace the widely deployed IKE. If the successors would work toward inclusion of legacy auth capabilities for roaming remote access then perhaps we might be able to convince customers to adopt a new KM. But even then it may not fly. Perhaps there are other problems yet out there to solve which would justify an IKE replacement.

	Legacy Auth has been solved in the market place by XAUTH and by L2TP+IPsec. My crystal ball does not show PIC showing up out there anytime soon. (But then again, my crystal ball is notoriously bad).


--
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." Benjamin Franklin

 Ricky Charlet     : rcharlet@sonciwall.com   : usa (408) 962-8711 





> -----Original Message-----
> From: Theodore Ts'o [mailto:tytso@mit.edu]
> Sent: Tuesday, June 18, 2002 5:15 PM
> To: ipsec@lists.tislabs.com
> Subject: SOI QUESTIONS: 2.3 Authentication styles
> 
> 
> 
> [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]]]
>