Hi Graham,
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."
Well, I don't think we should describe such obvious things.
And there is already text in RFC 7296 with similar meaning
in section 2.21 (however, without using imperative words):
There are many kinds of errors that can occur during IKE processing.
The general rule is that if a request is received that is badly
formatted, or unacceptable for reasons of policy (such as no matching
cryptographic algorithms), the response contains a Notify payload
indicating the error.
(Note singular "the response", not "the responses").
>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.
I don't think we are in a position to impose such a requirement in the draft.
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.
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> 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).
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.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
