RE: SOI QUESTIONS: 2.3 Authentication styles

["Stephane Beaulieu" <stephane@cisco.com>]

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

Yes.

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

Undecided.  Realistic IKEv2 deployments are years away (iron out
requirements, x draft revisions, commitment from major vendors, bakeoffs,
product hardening, etc...).  To make matters worse, most major vendors have
worked around most of IKEv1's shortcomings (remote access solutions, NAT
transparency, DPD, etc...).  Some of these solutions are (somewhat)
interoperable, some are 100% proprietary.  It may be a hard sell... and
IKEv2's  properties will have to be much better to sell them on it.  The
biggest thing that IKEv2 will buy us is interoperability and
(hopefully)better security properties (DoS resistance comes to mind).

Point is, by the time customers are willing to deploy IKEv2, the PKI
landscape may have evolved (crossed fingers).  Those customers who have not
yet deployed IKEv2, may be satisfied with running IKEv1 to get the shared
secret feature.

At the same time, I think that an IKEv2 that supports the Hybrid (from
Checkpoint) or CRACK (from Dan et al.) style legacy-auth in conjuction with
a very simple PKI (self-signed certs perhaps) would gladly do away with
pre-shared key.  I think most customers that use pre-shared key today fall
in 2 categories: either they have a small number of lan boxes (pre-shared
keys are manageable, self signed certs would also be manageable), or they're
doing remote access and are using pre-shared key with XAUTH or some other
proprietary IPsec+legacy auth method (replace this with Hybrid/CRACK).  So,
I believe that if we had Hybrid or CRACK, we could probably get away with
getting rid of pre-shared key.


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