[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