[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Non-IP type Client IDs
No. What I was saying is that I'd prefer that the phase 2 IDs be the
IP addresses used in packets within the IPSEC tunnel. Policy lookup
should be done based upon the identity of the peer (her certificate)
and these IP addresses.
Duplicating part of the certificate in the phase 1 ID payload simplifies
policy lookup for some implementations and also allows retrieval of the
peers certificate via some non-IKE method. In the case of doing policy
lookup based upon the ID contents, the ID contents MUST be verified against
the certificate. Since by phase 2 you have already obtained the peers
certificate (within an IKE phase 1 exchange or by some other means),
you know the identity of the peer and there is no benefit that I can
see for duplicating part of the certificate in the phase 2 ID.
I don't see the benefit of your alternative 1.
1) What does it provide that alternative 2 doesn't?
2) How do you verify IDci for alternative 1?
3) Why would IDii not also be USER_FQDN for alternative 1 and what would be
the benefit of having IDii different than IRci for alternative 1?
-dave
-----Original Message-----
From: Mike Williams [mailto:mikewill@ibm.net]
Sent: Friday, August 20, 1999 10:45 AM
To: Mason, David
Cc: Joern Sierwald; ipsec@lists.tislabs.com
Subject: Re: Non-IP type Client IDs
You have mentioned the two alternatives that need to be handled.
The first alternative is that the initiating system sends the USER_FQDN as
IDci in quick mode. This allows the gateway to lookup policy based on
client IDs, however the gateway must then assume that the selectors to use
in IPSec are the initiators IP Address (rather than IDci) and IDcr.
The second alternative is that the initiator send it's dynamically assigned
IP address in IDci. In this case, the assumption is that IDii used in
phase 1 will be something like USER_FQDN or KEYID and IDii together with
IDcr can be used to lookup phase 2 policy. In this case, the selector
values used by IPSec will be IDci and IDcr directly.
We have decided that we need to be able to handle either of these
situations, however we have seen that some implementation will not support
the first. What I am trying to understand is whether or not both are
allowed. From reading the RFCs, I believe they are.
Mike
"Mason, David" wrote:
> [snip]
>
> >Without using something like USER_FQDN or KEYID, how can you have
> >different phase 2 policies for different remote users. I also believe
> >that there are many cases when you will not be able to assign a fixed
> >private IP address to the client. Config Mode does help, but I don't
> >know why we should preclude other options.
>
> The certificate used in phase 1 differentiates between remote users.
> If you're relying on a USER_FQDN in phase 2 to determine policy such
> that user1@xxx.com is allowed access to all machines behind the gateway
> and user2@yyy.com is only allowed access to a subset of machines,
> user2@yyy.com will just stick user1@xxx.com in its phase 2 ID. I'd
> prefer to restrict phase 2 IDs to IP addresses. The certificate is
> the identity of the remote peer, duplicating this identity in various
> parts of the exchange(s) is redundant and unnecessary.
>
> -dave