[strongSwan] choice of ID selectors in ipsec.secrets IKEv2

[Kumar, Shekhar 1. (NSN - IN/Bangalore)]

Hi 

Any clues why IKEv2 uses PSK secrets entry  from ipsec.secrets even if only one of the selectors match for an entry ?

Thanks 
Shekhar

-----Original Message-----
From: Kumar, Shekhar 1. (NSN - IN/Bangalore) 
Sent: Monday, September 22, 2014 3:56 PM
To: 'users at lists.strongswan.org'
Subject: choice of ID selectors in ipsec.secrets IKEv2

Hi ,

I am facing a confusion with regards to selection of PSK secret from ipsec.secrets file , while sending or receiving AUTH messages. 

The text from strongswan wiki (last parageaph) suggest that in case of PSK -- " an entry with multiple selectors will match a host and peer if the host ID and peer ID each match one of the selectors."  
But in IKEv2 , if either of host_id or my_id match the list of selectors provided in ipsec.secrets entry , the key is tried for authentication of the message. 

For Example 

Ipsec.secrets  -- peer1   30.30.30.30/30.30.30.35

#POLICY_ID_IkeSAConfig-2000
30.30.30.30 30.30.30.31 : PSK "xyz"

#POLICY_ID_IkeSAConfig-1000
30.30.30.35 30.30.30.31 : PSK "dsfdsfd234 at dfdf9*2)(?-;"



Ipsec.secrets --peer2   30.30.30.31
#POLICY_ID_IkeSAConfig-1000
30.30.30.31 30.30.30.35 : PSK "dsfdsfd234 at dfdf9*2)(?-;"



Now , if peer 2 initiates an ESP tunnel between  30.30.30.31 and 30.30.30.30.

i> Peer 2 picks up the secret  entry      30.30.30.31 30.30.30.35 : PSK "dsfdsfd234 at dfdf9*2)(?-;"   (local id 30.30.30.31 and other id 30.30.30.30 , only one selector matches the entry)
ii> Peer1 is able to verify this using the entry 30.30.30.35 30.30.30.31 : PSK "dsfdsfd234 at dfdf9*2)(?-;"   ((local id 30.30.30.30 and other id 30.30.30.31 , only one selector matches the entry)

According to the text below for ipsec.secret entry to qualify to be used for authentication both selectors must match. 

I will really appreciate some insight into it.

Strongswan verison 4.5.3

Thanks and Regards 
Shekhar


https://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets


ID selectors
Each secret can be preceded by a list of optional ID selectors. The two parts are separated by a colon (:) that is surrounded by whitespace. If no ID selectors are specified the line must start with a colon.
A selector is an IP address, a Fully Qualified Domain Name, user at FQDN, %any or %any6 (other kinds may come). An IP address may be written in the familiar dotted quad form or as a domain name to be looked up when the file is loaded. In many cases it is a bad idea to use domain names because the name server may not be running or may be insecure. To denote a Fully Qualified Domain Name (as opposed to an IP address denoted by its domain name), precede the name with an at sign (@).
Matching IDs with selectors is fairly straightforward: they have to be equal. In the case of a Road Warrior connection, if an equal match is not found for the Peer's ID, and it is in the form of an IP address, a selector of %any will match the peer's IP address if IPV4 and %any6 will match a the peer's IP address if IPV6. Currently, the obsolete notation 0.0.0.0 may be used in place of %any.
When using IKEv1 an additional complexity arises in the case of authentication by preshared secret: the responder will need to look up the secret before the Peer's ID payload has been decoded, so the ID used will be the IP address.
To authenticate a connection between two hosts, the entry that most specifically matches the host and peer IDs is used. An entry with no selectors will match any host and peer. More specifically, an entry with one selector will match a host and peer if the selector matches the host's ID (the peer isn't considered). Still more specifically, an entry with multiple selectors will match a host and peer if the host ID and peer ID each match one of the selectors. If the key is for an asymmetric authentication technique (i.e. a public key system such as RSA), an entry with multiple selectors will match a host and peer even if only the host ID matches a selector (it is presumed that the selectors are all identities of the host). It is acceptable for two entries to be the best match as long as they agree about the secret or private key.