Hi Valery / Tero Sorry for the late reply.
GB> Comments inline. cheers On 21/03/2016 12:57, "Valery Smyslov" <[email protected]> wrote: >I don't think we are in a position to impose such a requirement in the >draft. GB>I feel we should explain WHY it’s a security benefit to link the ID and certificate. Not to mandate anything. As you said, currently the RFC states that ID does not have to match certifciate, but I feel this increases the attack surface for authenticated DoS attacks. >RFC 7296 doesn't have a requirement that an ID must be present in the >certificate. Moreover, Section 3.5. explicitely allows ID be different >from any field in certfificate: > > The Identification payloads, denoted IDi and IDr in this document, > allow peers to assert an identity to one another. This identity may > be used for policy lookup, but does not necessarily have to match > anything in the CERT payload; both fields may be used by an > implementation to perform access control decisions. When using the > ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr payloads, IKEv2 > does not require this address to match the address in the IP header > of IKEv2 packets, or anything in the TSi/TSr payloads. The contents > of IDi/IDr are used purely to fetch the policy and authentication > data related to the other party. > >There are many good reasons not to to impose such a requirement - >there are many use cases when ID payload just cannot be directly >mapped to credentials (preshared keys, some EAP methods, raw public >keys etc.), so the mapping is performed via Local Policy. >It allows more flexibility in real life, but at the same time it requires >Local Policy to be written with care. GB>I’m only proposing this for digital signatures where there is a cryptographically signed identity in this instance. I’m not suggesting it should be advised for other ID types (I couldn’t see the benefits). > >In your example there is a clear configuration error, and I don't think >we could do anything about this on RFC level. >Next time IT engineer issues two certificates with equal FQDNs >to two different people and the situation you described happens again, >even if SGW will check the match betweed ID and certificate... > >>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). > >No, I don't think so. To exploit this mis-configuration a malicious user >must be >authenticated by SGW. So, he/she is not an unknown attacker, he/she does >have >proper credentials. In this case he/she can be traced down >and the out-of-band measures can be taken. GB>Sure - they can be tracked down, but if we could prevent the opportunity to perform malicious behaviour surely that would be beneficial, rather than tracking down someone after the event. I’ll provide another scenario of malicious intent, where not having a ID to Cert check increases the attack surface; A mobile device configured to use certificates is lost and compromised (private key extracted). If the attacker knows the IKE ID used by all other members of the Gateway prior to the certificate being revoked the attacker could authenticate to the Gateway as all other IKE ID's (as the compromised certificate will pass authentication). In this instance when INITIAL_CONTACT is used the attacker will be able to delete the legitimate users active sessions. For VPN Gateways that serve both Remote Access and Site-to-site VPNs this would have maximum impact, taking out a site-site connection. For the case for IoT device it could be weeks before someone realised a device is compromised, which increases the attack surface even further. > >>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. > >The draft has a reference to RFC7619. In general, NULL auth is not >relevant to DoS protection >unless your product supports it. And in this case you have to read RFC >7619 anyway >while adding support, right? > >>>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. > >Could you please describe how you exhaust the pool of IP addresses? >If you are authenticated user you'll receive the same IP address no matter >how many times you ask for it (in general it depends on SGW >implementation, >I assume SGW links client ID with IP from poll). GB>After a bit more digging, the exploit I thought I had found would require the implementation to be broken. > >If you use NULL auth, then it is a different story, but I think >RFC 7619 describes the risks of using NULL auth. > >Regards, >Valery.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
