Hi Valery / Paul Paul - does your implementation send the INFORMATIONAL + other messages (Private Use Error) to a single SA_INIT? Just to clarify the issue observed seemed to be SA_INIT is sent by Initiator, Responder sends an SA_INIT reply plus numerous INFORMATIONAL messages separately to this single SA_INIT message containing Private Use Errors.
GB> I’ve made some comments inline for clarity. cheers On 20/03/2016 06:43, "Valery Smyslov" <sva...@gmail.com> wrote: >Hi Graham, > >thank you for the updated text. > >> I¹ve made some amendments to the proposed text based on Valerys >>comments. >> >> I¹ve also added text around the correct sending of INFORMATIONAL >>messages >> due to a Responder receiving an SA_INIT, this is a known problem today >> with a number of implementations. (seen by Tero and myself). > >Sorry, your text is wrong (or at least is not accurate). The responder >must never reply to an IKE_SA_INIT with INFORMATIONAL message. >See section 1.5 of RFC 7296: > > In the second and third cases, the message is always sent without > cryptographic protection (outside of an IKE SA), and includes either > an INVALID_IKE_SPI or an INVALID_MAJOR_VERSION notification (with no > notification data). The message is a response message, and thus it > is sent to the IP address and port from whence it came with the same > IKE SPIs and the Message ID and Exchange Type are copied from the > request. The Response flag is set to 1, and the version flags are > set in the normal fashion. > >Note, thet Exchange Type is copied from the request, so if some >IKE_SA_INIT >request has unsupported major version the responder will send >INVALID_MAJOR_VERSION in the IKE_SA_INIT (not INFORMATIONAL) response. GB> Thanks Valery - this is now clear. However not only was I confused, as Paul confirms there’s other implementations that are also confused. Seeing as there’s confusion with regards to this wording and it can lead to an amplification attack I personally feel we should include the following text for clarification? "RFC7296 Section 1.5 describes the generating of informational messages a Responder will send. Only a single instance of the generated message should ever be sent for a received request and under no circumstances should a received request cause the generation of more than a single message in reply." > >The only case unprotected INFORMATIONAL message is sent is when >the host receives AH/ESP packet with unknown SPI. And all these cases >are covered in Section 1.5 of RFC 7296 in sufficient detail, including >DoS attacks prevention measures (rate limiting). >I don't think we should repeat all this in the draft. > >> I have also moved text to section 11. Security Consideration. >> >> I¹ve added some words around the checking of the IDi/IDr. I¹ve >>personally >> seen some issues when misconfigured clients have presented an identical >> IDi, resulting in INITIAL_CONTACT deleting the Œother¹ clients SA. > >Since INITIAL_CONTACT is processed after peer authentication, >malicious user cannot use it to perform DoS attack >(unless he/she is able to impersonate legitimate user, but in this case >he/she can do much worse things). And what about misconfiguration - >Section 2.4 of RFC 7296 already has all due warnings: > > This notification MUST NOT be sent by an entity that may be > replicated (e.g., a roaming user's credentials where the user is > allowed to connect to the corporate firewall from two remote systems > at the same time). > >Again, I don't think we should copy all the requirements concerning >INITIAL_CONTACT from RFC7296. GB> For this example I’ve personally seen misconfigured clients, this isn’t exactly the 'entity being replicated' (or not intentionally). As an example VPN architecture, the authentication use Digital Signatures, but send the ID as FQDN. Your laptop is provisioned with ID of FQDN=valery.example.com, mine should be FQDN=graham.example.com, however due to an IT engineer provision error I have the same ID as you in my VPN profile. When I connect, if the VPN gateway does not check the presented FQDN is in the certificate (where a mismatch would occur), I pass authentication and INITIAL_CONTACT deletes your session. The strict check of ensuring that the ID is contained within the certificate will mitigate the mis-configuration and also malicious intent. For the malicious example, it’s easy to spoof an ID, but it’s computationally impossible to spoof a certificate, hence the ID-Certificate check will mitigate any mis-conftguation or malicious intention. The behaviour of INITIAL_CONTACT is really being exploited in this case (IMO). GB> Hi Paul - this (IMO) is an issue with any authentication mechanism, not just RFC7619, so if someone is looking to protect RFC7296 against DDOS, would they read RFC7619? I know it's more apparent in RFC7619, but there’s still cases (and seem to be common) where it can happen. > >> I did think about exhaustion of IP addresses when using configuration >> payload to allocate clients IPs, if a malicious or misconfigured client >> could exhaust the pool. But I feel the wording in section 8 covers this. >> Unless others think otherwise? > >Again, allocation of IP addresses takes place after user authentication, >so it cannot be used as DoS attack by malicious user. GB> Think of mischievous users or misconfigured, as anyone who CAN pass authentication. Let me give you this example. I’m granted access to a VPN gateway for 24 hours, where a security policy is applied so that I only access read access to a single file. I’m an ‘untrusted’ user, this gateway also serves ’trusted’ users. I am granted very limited access. I exhaust the pool of IP addresses so that no other (legitimate) users can connect. This is similar to DHCP exhaustion on a LAN. We can mitigate against that (DHCP snooping etc), I feel that we should protect IKE from a similar attack. GB> I’m seeing a lot of cases (IoT), where IKE is used, however the devices aren’t secured and are not really trusted. Examples are; Sensor on a pole in the middle of no-where, or unsecured in a lift shaft. For the IoT case although the authentication exchange passes, the client still isn’t fully trusted, so we should protect the control-plane (IKE) as best we can. GB> FWIW - I feel that the text in section 8 does sort of cover this, but wanted to describe the issue and if others feel the text doesn’t adequately mitigate the issue of IP address exhaustion I can add some words. >> cheers > >Regards, >Valery. >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
