[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKEV2: Issue #4 Revised Identity
In your previous mail you wrote:
That's why we want to just send the URL (or URN if you want) where the
certificate, whatever chain you need, and maybe the CRL, can be
found.
=> I agree: even if the revised identity proposal seems a bit drastic
it fully solved the issue (this is why I support it).
Sending the whole thing makes total sense for TLS, and it works well for
HTTPS, SMTP(STARTTLS), but not for IKE over UDP. Maybe IKE v3 will run over
SCTP... maybe not.
=> in my IPsec for Mobile IPv6 experiments, the message with the whole
thing *never* reached the other end at the first try!
I agree IKE should run over SCTP (with funny consequences on peer
addresses :-) but perhaps it is too soon to propose this?
IMHO IKE is a signaling protocol so should use SCTP...
Honestly. With something like 80% of VPNs running pre-shared secrets
=> unfortunately with weak implementations of XAUTH for mobile clients...
because there are multiple implementations out there that can't even cope
with importing or exporting even a self-signed certificate (or making it
so hard nobody bothers), I really do not think that we need any more
esoteric situations.
=> I can't parse your conclusion: do you support or not the revised
identity proposal for IKEv2?
Once we have 90% of deployment running with public keys, and the
rest doing legacy auth, maybe with public keys assymetrically, then it
will be time worry about extended chain resolution etc...
=> IMHO a large part of the issue comes from the network access control
(the AAA) done by IKE when IKE has no native interface with an AAA system.
The PKI stuff should be integrated with legacy authentication
in order to provide a native AAA interface in charge of the strong
authentication with authorization and accounting as goodies...
Regards
Francis.Dupont@enst-bretagne.fr