[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identity Type



OK, here we go again. Others have seen this before, 
but the email is not that long, really.

It should be noted that these are
my personal opinions, not a standard.

typedef enum {
   /* IPSEC_ID_RESERVED			= 0, */
   IPSEC_ID_IPV4_ADDR			= 1,
   IPSEC_ID_FQDN			= 2,
   IPSEC_ID_USER_FQDN			= 3,
   IPSEC_ID_IPV4_ADDR_SUBNET		= 4,
   IPSEC_ID_IPV6_ADDR			= 5,
   IPSEC_ID_IPV6_ADDR_SUBNET		= 6,
   IPSEC_ID_IPV4_ADDR_RANGE		= 7,
   IPSEC_ID_IPV6_ADDR_RANGE		= 8,
   IPSEC_ID_DER_ASN1_DN		= 9,
   IPSEC_ID_DER_ASN1_GN		= 10,
   IPSEC_ID_KEY_ID			= 11
} IkeIpsecIdentificationType;

PHASE 1 using preshared keys
============================

The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and KEY_ID are 
recommended in a phase 1 exchange using preshared keys. 
In agressive mode, the values can be used for an immediate 
policy lookup. In main mode, the responder
must retrieve the secret from the spd before it receives the ID, thus
only IPV4_ADDR is useful in main mode.

Is the responder has a "group" policy to allow several hosts 
with volatile IP addresses to connect, the use of aggressive mode
and ID types USER_FQDN and KEY_ID is recommended. 

DER_ASN1_DN and DER_ASN1_GN are meaningful IDs as well, if an
implementation chooses to store policy data indexed by these IDs.

Address ranges and subnets are not allowed in Phase 1.

An IKE implementation MUST at least implement IPV4_ADDR.
However, USER_FQDN is a very useful ID because end users
are able to understand and remember them.

PHASE 1 using pk signatures
===========================

The ID types IPV4_ADDR, IPV6_ADDR, FQDN, USER_FQDN and DER_ASN1_DN are 
recommended in a phase 1 exchange using signatures. 
In agressive mode, the values can be used for an immediate policy lookup.
In main mode, only the initiator's IP address is available for the 
initial policy lookup of the responder. Therefore, the policy must 
contain (IP address, ID) or (IP address range, ID range) pairs.
After receiving the 5th packet of MM, the responder has to do
a second policy check. 
The responder must reject a MM where the IDV4_ADDR ID and the
IP address does not match.

Is the responder has a "group" policy to allow several hosts 
with volatile IP addresses to connect, the use of aggressive mode
and ID types USER_FQDN and DER_ASN1_DN is recommended.
It should be noted that these IDs, especially DER_ASN1_DN may 
contain valuable information which is not suitable to be transmitted 
in cleartext. In this case, I recommend public key encrytion. The 
alternative is having one policy entry (0.0.0.0/0, (list of all IDs)).

The ID must show up in the certificate! E.g., if the ID is USER_FQDN,
the subjectAltName must contain an email address.

DER_ASN1_GN is may be used as an alternative to IPV4_ADDR, IPV6_ADDR, FQDN
and USER_FQDN.
The subjectAltNames in certificates are encoded as general names, so
DER_ASN1_GN is a generic pointer to a subjectAltName.
One could even argue that USER_FQDN is not a valid ID and that email addresses
must be encoded using DER_ASN1_GN. I don't think so.

Address ranges and subnets are not allowed in Phase 1.
IPSEC_ID_KEY_ID is not useful.

An IKE implementation MUST at least implement IPV4_ADDR and DER_ASN1_DN.

PHASE 1 using pk encryption
===========================

Same as signatures, but the ID is safe in agressive mode.

Quick Mode
==========

QM IDs act as selectors for packets. src and dst addresses of IP packets
transmitted through the SA must match the negotiated IDs.
While it is possible to not send IDs in QM, it is not recommended.

IPV4_ADDR, IPV4_ADDR_SUBNET, IPV4_ADDR_RANGE, IPV6_ADDR, IPV6_ADDR_SUBNET,
IPV6_ADDR_RANGE
may be used in QM. IPv4 and IPv6 may not be mixed. ADDR, RANGE and SUBNET
may be mixed.

Jörn Sierwald




Follow-Ups: