Scott C Moonen writes: > Tero, > > > > Agreed. How about SHOULD, but adding "if the error occurred in the > > > response to an IKE_AUTH exchange, and in payloads related to > > > authentication. A new exchange SHOULD NOT be triggered for reporting > > > errors in child SAs, CFG, or notifications." > > > > If that error occurred during IKE_AUTH because of authentication > > failure or INVALID_SYNTAX or similar then there is no way to start new > > INFORMATIONAL exchange as for the initiators part the IKE SA wasn't > > finished, thus he DOES NOT have IKE SA to start INFORMATIONAL on. > > We've already bent this rule a little bit if the responder detects an > authentication failure. I.e., we've documented that the responder should > encrypt&MAC his N(AUTHENTICATION_FAILED) response even though from his > perspective he doesn't have a valid IKE SA.
True, but that does not mean the IKE SA is valid, it just means they do have shared unauthenticated keys for encryption and MAC. I.e that encrypt & MAC proves that the reply comes back from the same server who did Diffie-Hellman, but it does not mean it came back from the correct intended responder. The reply could be generated also by man in the middle. > It seems reasonable to do something similar in this case. I.e., if the > initiator detects an authentication failure (say, the responder's > certificate has expired), it is reasonable for him to 1) send a protected > INFORMATIONAL request over the unauthenticated SA with the error notify, > and 2) disallow any other possible activity on that invalid SA except for > retransmitting the request and waiting on the response. That adds quite of lot of special code (i.e you need to make sure that IKE SA is not used for anything else while you are waiting for reply), and does not really help that much. This will cause server to clean up the IKE SA faster than it normally would, but as client initiated this there is most likely no data coming from the server to client anyways thus no traffic is really lost. The client will still fail the IKE SA and as client was the one who initiated it, it will most likely try again and the user noticing things does not work tries to fix things. This kind of authentication failures usually do not go away without user intervention anyways. >From the responders point of view the IKE SA is there, so he does not care which way the initiator does, so this is not something that needs to be defined at all (i.e. there is no need to define whether it is allowed, recommended or forbidden). Whether implementation does this can be completely left to as local matter. > In our own case, if this happens as initiator, we will do this, sending a > protected INFORMATIONAL request containing both N(AUTHENTICATION_FAILED) > and also a DELETE for the IKE SA. In my view the DELETE is actually the > more crucial payload here, and the Notify payload is primarily a courtesy > to hint to the responder why the delete is being sent (since there is > really no way to assert that a Notify in an INFORMATIONAL request relates > to some other particular exchange). You are free to do that. It will gain you so that server will delete the IKE SA bit earlier than it would otherwise (i.e. otherwise it would need to wait for the DPD to kick in (which would most likely happen quite soon, as there is completely idle IKE and IPsec SA there) and that would then delete the IKE SA). For the original users point of view (i.e. the initiator / client) this does not matter, as he still cannot get connection... I myself as implementor writing code do not want to add such code to our product as it is just adding code that is very seldomly run and even less seldomly tested, and which can contain security bugs, thus the product is safer and better without such code. But this is just my own opinion, and other implementors might have different opinions, and I am ok with text which says you MAY do it. I would object against SHOULD, and object very strongly against MUST. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
