Re: Confirm decision on identity handling.

["Scott G. Kelly" <scott@airespace.com>]

Ravi wrote:

<trimmed...> 

> Some implementations already do this for supporting remote access.
> In remote access, road warriors are initiators and Corporate SG is
> typically configured in 'Responder' only mode. One IKE policy is
> created with
>            - Wild card domain name as peer ID.
>              For example, *.abc.com can be give as Peer ID.
>              Then all remote access users whose IDs are ending with
> 
>              abc.com will be authenticating using this IKE policy.
> 
>           -  Accept any whose signing CA is 'DN of CA'.
>              This is typically useful when corporate office has their own
>              CA and anybody got certificate from this CA is authenticated
>              using this policy.
> 
> In above examples, really there is no check between ID payload and
> Certificate in verbatim. It is local decision.

No, in this case which policy is used is the sender's decision. If
you'll accept any cert from your CA, and you have one policy for abc.com
and another for def.com, what assurance do you have that the presenter
is who he claims to be?

The point is that for remote access, the IP address is not known a
priori, so the only way to configure a policy for a remote access user
at the recipient (i.e. SGW) end is in terms of a "name" of some sort. If
this is to be meaningful from a security perspective, there must be a
cryptographically sound way to bind this name to the user presenting it.
If you are using certs, it makes sense to use an identifier which is
contained within (or otherwise verifiable using) the cert, to ensure
cryptographic binding.

What is being suggested by some is that we decouple the name used to
select the policy from the authenticator which, in my view, makes little
sense from a security perspective. It opens the door to
misconfigurations in which the same cert may be acceptable for more than
one policy rule, where the selected rule is controlled by the sender of
the ID payload - not exactly secure from the perspective of the SGW. It
is also argued (correctly, I think) that the lack of standard cert
profile for ipsec makes it practically impossible to specify universally
which cert field(s) will be presented by the sender, and
configured/accepted by the receiver, in an interoperable way.

This leads to my suggestion that the would-be-interoperable sender not
bother trying to guess what should be in the ID payload, since he cannot
be sure of doing so correctly, and for the receiver to have the option
of ignoring any ID sent along with a cert, and to have the ability to
select the correct policy with or without the ID payload, gleaning
whatever is needed from the cert. Clearly, this applies to certs only,
and not to raw rsa/dsa keys. This allows folks who are using the ID
payload as a convenient policy key for cert-based policies to continue
to do so, while ensuring that they will interoperate with someone who
doesn't send a particular ID, and vice versa. 

Of course, we assume that those using the unbound ID for convenience
actually do some additional policy verification from a security
perspective, although I suspect that in some cases this is not the case
- and such behavior should not be standardized by a security area
working group.

Scott