Subject: [IPsec] IKEv2: Possibility of "storing" configuration (Cryptographic Suite) for a certain Peer

From: Matthew Cini Sarreo <[email-masked]>
Date: Wed, 8 Apr 2009 10:14:44 +0200

Hi everyone,

As to my understanding, in IKEv2 it is not possible to know "who" the peer
is until IKE_AUTH, by using the ID payload for that peer. Let us say that an
implementation chooses not to use any automatic configuration but decide (by
manual configuration) to accept only a certain Cryptographic Suite.

As an example, let us say that after a peer (initiator) sends a message to
another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the
responder would reply with INVALID_KE_PAYLOAD. The configuration as above
would not send a new IKE_SA_INIT message with a corrected D-H group but halt
the negotiation.

In such a scenario, it might be required to have different D-H groups for
different peers. Due to the ID payload being inexistant at this time, is
there a way (that is allowed) to identify a peer during IKE_SA_INIT (for
example, based on an IP address that has been stored in a configuration file
that is known to always be for a certain peer), or are such identification
methods (IP-based during IKE_SA_INIT just by checking the IP address source
in the IP header of an IKE_SA_INIT message) prohibited?

P.S this point comes from the IKEv2 RFC, section 2.6 (IKE SA SPIs and
Cookies), par. 2 which states:
"Incoming IKE packets are mapped to an IKE SA only using the packet's SPI,
not using (for example) the source IP address of the packet."
But the "identification" for fixed configuration purposes would be before
this, as the packet would not be mapped to an SA, but a configuration for
the SA resulting my that message would be loaded from configuration.

Regards,
Matt

---

From: Scott C Moonen <[email-masked]>
Date: Wed, 8 Apr 2009 07:28:43 -0400

Hi Matt.  Because identities are not known until the IKE_AUTH exchange, it 
is always necessary to do a preliminary PAD lookup (see RFC 4301 for the 
Peer Authorization Database) based on IP address (and possibly local 
identity, depending on whether you configure that outside the PAD or 
discover that from the PAD) and to either verify the PAD entry once the 
identities are known or else do a subsequent PAD lookup using the final 
identities.  You might have even noticed in the IKE_AUTH exchange, that if 
the initiator sends the optional IDr payload, the responder is not 
obligated to use that IDr as its own identity.  So even if the initiator 
has hinted it prefers a certain IDr, it should do a second PAD lookup once 
it receives the IKE_AUTH response to verify that the negotiated SA 
conforms to its policy based on the actual IDr.

So a compliant implementation will do an initial lookup by IP address just 
as you describe, followed by a later lookup or verification using the 
identities.

Scott Moonen ([email-masked])
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen

From:
Matthew Cini Sarreo <[email-masked]>
To:
[email-masked]
Date:
04/08/2009 04:16 AM
Subject:
[IPsec] IKEv2: Possibility of "storing" configuration   (Cryptographic 
Suite) for a certain Peer

Hi everyone,

As to my understanding, in IKEv2 it is not possible to know "who" the peer 
is until IKE_AUTH, by using the ID payload for that peer. Let us say that 
an implementation chooses not to use any automatic configuration but 
decide (by manual configuration) to accept only a certain Cryptographic 
Suite. 

As an example, let us say that after a peer (initiator) sends a message to 
another peer (responder) requesting a new IKE2 SA (IKE_SA_INIT), the 
responder would reply with INVALID_KE_PAYLOAD. The configuration as above 
would not send a new IKE_SA_INIT message with a corrected D-H group but 
halt the negotiation.

In such a scenario, it might be required to have different D-H groups for 
different peers. Due to the ID payload being inexistant at this time, is 
there a way (that is allowed) to identify a peer during IKE_SA_INIT (for 
example, based on an IP address that has been stored in a configuration 
file that is known to always be for a certain peer), or are such 
identification methods (IP-based during IKE_SA_INIT just by checking the 
IP address source in the IP header of an IKE_SA_INIT message) prohibited?

Regards,
Matt_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 8 Apr 2009 16:03:04 +0300

> in the IP header of an IKE_SA_INIT message) prohibited?

Does not really sound like reasonable real world use case, and I would
firstly try to convince people that hosts should never ever allow
anybody to use too weak cryptographic suites, and if you only allow
strong enough ones, then it does not matter which one of those strong
enough ones is used.

But to your question.

Yes, you can select the IKE SA cryptographic algorithms based on the
IP address of the request. Actually you can use whatever means you
can, including the phase of the moon, but usually only useful thing
you have is the IP address of the other end.

This of course has the problem that if the other does not have fixed
IP-address, then you might have problems (or you end up problems if
you have multiple hosts having dynamic IP-addresses and their required
policies do not match).

If there really is strong requirement that specific host MUST use some
cryptographic suite that is not allowed for another host and both of
them use dynamic IP-addresses, you can always do so that you do
IKE_SA_INIT exchange and then when you see IKE_AUTH message, you know
the identity, and then you can verify that your IKE_SA_INIT parameters
were correct, and if so continue. If your IKE_SA_INIT parameters were
wrong, then you simply store information to your local cache saying
that host from this IP address, should use these IKE_SA_INIT
parameters next time, and return some fatal error message to IKE_AUTH.
When the initiator then retries and sends next IKE_SA_INIT, you can
then check your cache, and see that for this IP-address you should use
these parameters, and use those and then continue. Then in the
IKE_AUTH you again verify that your parameters were correct and
continue.

> the SA resulting my that message would be loaded from configuration.

That text means that the source address of the UDP IKE packet does not
matter when finding the IKE SA state. When doing lookup to PAD you can
use the remote IP address of the peer (RFC 4301, PAD). If PAD contains
restrictions that these PAD entries must have remote peer location of
IP address XXX, then it is best to first concentrate your searching of
the suitable PAD entry for new connection to those PAD entries having
matching IP-address. If you only find one PAD entry then you can
assume that this will be the one that will be used, and then later in
the IKE_AUTH verify that your guess was correct by doing PAD/SPD
lookup again using the full information available and check that you
get same PAD/SPD entry back.

For example in our implementation the configuration can specify that
this IPsec connection must have local and/or remote IP as specified in
the configuration, and then when new connection comes in we first
search entry matching both to the remote and local IP, and if such is
found, we guess that is the correct one. If that is not found, we
search one having correct remote IP, and if that is not found then we
search for having correct local IP, and otherwise use defaults.

Later we then verify that the final selected IPsec connection is same
than what we guessed earlier (or at least has same parameters for IKE
SA).
-- 
[email-masked]