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

Re: SOI QUESTIONS: 2.3 Authentication styles



Theodore Ts'o wrote:
<extensively trimmed...> 
> 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.

I don't agree with this assertion. I believe the ipsra wg was formed
because some members the ipsec wg deemed the work to be outside the
scope of ipsec proper. The existence of ipsra does not provide any basis
for the argument that remote access should be handled by another
protocol; rather, it is evidence that some influential folks believed
this to be the case.

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

I too vote for native support for remote access authentication
mechanisms. In an ideal world, PKI-based mechanisms (such as PIC) should
suffice. But many users rely upon RADIUS and similar passphrase-based
mechanisms, and the market will simply not embrace a solution which does
not support these mechanisms. Requiring PKI add-ons will only work if
vendors nearly-unamimously agree to build such mechanisms, and if RADIUS
vendors agree to add front-ends for such mechanisms. Since virtually all
VPN vendors of consequence have implemented xauth, l2tp, or both, this
likely amounts to nothing more than wishful thinking. I think a native
adaptation of Dan's crack proposal is the way to go.

> 2.3.B.)  Does SOI need to natively support some kind of "shared
> secret" scheme?  (Or just certificates-only?)

I think we either need a shared secret scheme or vendors need to support
public key mechanisms which work without CA certificates (as well as
with them). The second alternative seems simpler from an operational
perspective, as it could likely be piggy-backed onto an existing mode
(e.g. RSA-SIG), perhaps with minimal impact.

Scott