Nico Williams writes:
> Reading into what you write above you seem to think that it's not
> possible to abstract authentication sufficiently well (for IKEv2's
> purposes, in this case). I disagree. I'll grant only that there's
We do have abstract authentication method already in the IKEv2, i.e.
EAP. The problem with that is that it do require infrastructure, which
is bit too difficult to put up when only thing you want to do is to do
shared key authentication between two VPN gateways.
> framework (this is true of EAP and SASL). And here Tero is proposing
> yet another pluggable framework.
Nope. I am not proposing to create pluggable framework. I am proposing
of getting common parts of the 4 different methods and make them so
they can be used together.
> Tero's proposal: create a new pluggable authentication framework.
> My proposal: pick an off-the-shelf framework.
That one is not really an option. The options are:
Tero's proposal: make different symmetric secure password
authentication methods so they all can be implemented
in the same code base.
Other proposal: do nothing, and publish those four different methods
so that you need to manually configure which one of
them to use and implement new exchanges, payload
formats etc for each of them.
In both cases the methods are still going to be very tightly combined
to the IKEv2, and cannot be separated from there and used elsewhere.
The actual algorithms can be used, but the calculations like:
found = 0
counter = 1
do {
ske-seed = prf(Ni | Nr, psk | counter)
ske-value = prf+(swd-seed, "IKE SKE Hunting And Pecking")
if (ske-value < p)
then
SKE = ske-value ^ ((p-1)/r) mod p
if (SKE > 1)
then
found = 1
fi
fi
counter = counter + 1
} while (found == 0)
or
skey = F(scalar-op(private,
element-op(peer-element,
scalar-op(peer-scalar, SKE))))
ss = prf(Ni | Nr, skey | "Secure PSK Authentication in IKE")
AUTH = prf(ss, <msg octets>)
or
PACESharedSecret = KA(SKEi, PKEr, GE) = KA(SKEr, PKEi, GE),
AUTHi = prf(prf+(Ni | Nr, PACESharedSecret),
<InitiatorSignedOctets> | PKEr)
are not really generic, they are specific to the IKEv2. This is not
generic authentication framework, this is generic payload format for
the IKEv2 secure password authentication methods.
The reason WG wanted this is that people want to have secure way to
use secure password authentication between boxes. Usually there will
NOT be any kind of backend in either end, and the connection will be
symmetric, i.e. either end can start it. Normal use case will be the
VPN connection between two offices. They do not want any
infrastructure, thus they do not want certificates, they do not want
EAP or AAA etc. Currently they are using normal shared-secret
authentication but in most cases their shared-secrets are not really
random, but some kind of human writtable words so they can be
transmitted over phone, thus they are vulnerable to the off-line
dictionary attacks now.
There are other use cases, but for example remote access scenarios
there are already EAP methods providing same features.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
