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

Re: Secure remote access with IPsec

 In your previous mail you wrote:

   Because this is a research work (thesis) It would have no sense for me
   implementing IKEv2.
=> research is not 100% paperwork...

   - Endpoint Authentication is solved by EAP even if there is "The
   compound authentication binding problem" using legacy authentication
   mechanism like CHAP, OTP, SecurID... However I think that in the future
   we will authenticate ourselves with a smart card, or something similar
   - What about Kerberos in EAP?

=> EAP is the PPP generic authentication. You can put what you'd like
in EAP.

   - Why can't we make a binding AUTH with CHAP, OTP?

=> CHAP and OTP are included in EAP (CHAP as the MD5-Challenge, OTP
as itself, both are "initial" types).

   - NAT-T capability are enabled in IKEv2, and I think it works well (what
   about let IKE speaks on UDP 4500 directly even when there isn't NAT-T

=> if it seems useful to permit this (IMHO it will be the case) then
NAT-T support will get a MUST.

   function enabled? What's wrog with that?).

=> if the function is disabled this is simply a policy mismatch, i.e.,
a negociation failure (notification with error "INVALID-SYNTAX"?)

   I know the pseudo-NAT
   problem, however I think that an attacker on the path could easily
   delete all the message.
=> it seems you read my drafts!

   - IPsec is well integrated with MIPv6 
   [draft-ietf-mobileip-mipv6-ha-ipsec-03.txt], so we can think of a mobile 
   node connecting back to his Corporate Network, without need rekeying 
   when it changes his address (can we change the selectors of a SA or an 
   entry of the SPD upon the receiving of a BU message?)
=> we cannot change the selectors of a SA without rekeying. And we shan't
change a traffic selector of a tunnel without rekeying. The situation
is a bit more complex for transport mode or peer addresses, today the only
way is rekeying but there is a WG agreement it should be studied in a
post-IKEv2 activity. Note the MN-HA transport mode SA for BU protection
is setup in a proxy mode (transport mode where peer addresses and traffic
selectors don't match). Such SAs cannot be updated but fortunately in
this special case this is not needed...