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

RE: SOI QUESTIONS: 2.3 Authentication styles




> 2.3.A.)  Does SOI need to natively support "legacy authentication
> systems"?
Absolutely.  I don't believe PIC will be acceptable after customers have
become used to XAUTH with IKEv1.  NOTE: I'm not suggesting XAUTHv2 be
written, rather IKEv2 must provide the functionality (maybe CRACK?) so
XAUTHv2 is not written.

>
> 2.3.B.)  Does SOI need to natively support some kind of "shared
> secret" scheme?  (Or just certificates-only?)
Short answer: No but MUST support native legacy authentication if shared
secrets don't exist.

Long answer: The goal should be to provide a mechanism with the simplicity
of shared secrets.  Self-signed certificates do not provide all the
simplicity of a shared secret but I can't think of anything that comes
closer.  For LAN-LAN VPN self-signed certs would likely suffice since the
peers are relatively static so cert distribution could be minimal and simple
(if well specified and implemented).  For Remote Access VPN the clients
could use a legacy authentication mechanism to supply a simple UN/PW that
would provide a similar deployment experiance to shared secrets.

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