[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Non-IP type Client IDs
There seems to be some confusion with regards to the use of Non-IP type
client IDs (i.e. USER_FQDN) in a quick mode exchange. We have seen that
some implementations will send non-IP type Client IDs and we have also
seen some implementations that will not properly handle non-IP type
Client IDs.
>From reviewing the relevant RFCs, I am not able to see anything that
indicates that there are restrictions on the IPSec DOI ID types in quick
mode. What I see is that section 4.6.2 of RFC2407 says "The identity of
the initiator SHOULD be used by the responder to determine the correct
host system security policy requirement for the association." This says
that IDs (both phase 1 and phase 2) should be used to help lookup
policy. I also see in section 5.5 of RFC2409 that "The identities of
the SAs negotiated in Quick Mode are implicitly assumed to be the IP
addresses of the ISAKMP peers, without any implied constraints on the
protocol or port numbers allowed, unless client identifiers are
specified in Quick Mode. If ISAKMP is acting as a client negotiator on
behalf of another party, the identities of the parties MUST be passed as
IDci and then IDcr. Local policy will dictate whether the proposals are
acceptable for the identities specified."....."The client identities are
used to identify and direct traffic to the appropriate tunnel in cases
where multiple tunnels exist between two peers and also to allow for
unique and shared SAs with different granularity." I understand this to
say that the client IDs are not only used to lookup policy, but are also
used in determining the selectors used by IPSec which must be IP types
(i.e. IPV4_ADDR, IPV4_ADDR_SUBNET or IPV4_ADDR_RANGE).
In the case of remote access when the initiating system will not have a
fixed IP address, allowing the client (initiating) system to send
something like user@fqdn would allow the responding system (host or
gateway) to define different policies for the different users that will
be allowed to connect. For example, it may be desirable to have a
different policy for some user mikewill@ibm.net than for the user
mdw@us.ibm.com when both of these users will have an arbitrarily
assigned IP address every time they attempt to connect. This is only
addresses half the problem, that being how to lookup phase 2 policy.
The second half of the problem that client IDs solve, is helping to
define the selectors that will be used by IPSec to direct traffic to
different IPSec tunnels. When the client IDs are IP type IDs (i.e.
IPV4_ADDR, IPV4_ADDR_SUBNET or IPV4_ADDR_RANGE) the obvious answer is to
use the client IDs as the selectors. The problem is what are the
selectors when the client IDs are not IP type IDs (i.e. UASER_FQDN).
What we have done is assume that the client ID has been sent to assist
in policy lookup and create the selector based on the IP address of the
IKE peer as if the client IDs had not been sent at all. There is one
exception to this... If the ID is of type FQDN, we first attempt to
resolve this using DNS to determine the value for the selector. If we
are unable to resolve the name, then we will use the IP address of the
IKE peer.
How have others handle this problem? Any information that can be
provided would be greatly appreciated.
Mike Williams
Follow-Ups: