Subject: 2401bis Issue # 89 -- Remove the selector "name"

From: Karen Seo <[email-masked]>
Date: Wed, 22 Oct 2003 23:31:23 -0400

Folks,

Here's a description and proposed approach for:

IPsec Issue #:	89

Title:		Remove the selector "name"

Description
===========
In the interest of simplifying things, we propose to remove the 
selector "Name".  Is anyone using this selector?

Proposed approach
=================
Remove text such as the following:

   [From Section 4.4.2 "Selectors"]

   "- Name: There are 2 cases (Note that these name forms are
      supported in the IPsec DOI.)
          1. User ID
              a. a fully qualified user name string (DNS),
                 e.g., [email-masked]
              b. X.500 distinguished name, e.g., C = US,
                 SP = MA,  O = GTE Internetworking, CN =
                 Stephen T. Kent.
          2. System name (host, security gateway, etc.)
              a. a fully qualified DNS name, e.g.,
                 foo.bar.com
              b. X.500 distinguished name
              c. X.500 general name

      NOTE: One of the possible values of this selector is
            "OPAQUE".

      [REQUIRED for the following cases.  Note that support
      for name forms other than addresses is not required for
      manually keyed SAs.
          o User ID
              - native host implementations
              - BITW and BITS implementations acting as HOSTS
                with only one user
              - security gateway implementations for INBOUND
                processing.
          o System names -- all implementations]"

Thank you,
Karen

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 23 Oct 2003 08:57:30 -0700

The name selector is often used for remote access, and maybe for other 
applications. I know of several ipsec implementations which use fqdn for 
remote access policy selection, and without DN, how do we apply access 
controls based on certs?

Scott

Karen Seo wrote:
> In the interest of simplifying things, we propose to remove the selector 
> "Name".  Is anyone using this selector?
> 
> Proposed approach
> =================

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Thu, 23 Oct 2003 09:51:58 -0700

At 8:57 AM -0700 10/23/03, Scott G. Kelly wrote:
>The name selector is often used for remote access, and maybe for 
>other applications. I know of several ipsec implementations which 
>use fqdn for remote access policy selection, and without DN, how do 
>we apply access controls based on certs?

This has been debated many times before. Some systems have policies 
that allow any cert that is signed by the trusted CA to have access. 
That is, the granularity is based on the trusted root, not on the 
identity. This means that a sysadmin doesn't have to list a zillion 
users, all of whom have identical access rights; it also means that 
the user has access as soon as they have their cert, without 
interaction from the sysadmin who is just going to duplicate what 
they did for the last user.

Names are useful for systems that differentiate by user, but they 
kill the ability to differentiate by certifier.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 23 Oct 2003 10:03:25 -0700

Hi Paul,

First, let's be clear: some folks use fqdn as a psk selector in remote 
access. This is distinct from the DN/GN question, and the two should not 
(necessarily) be lumped into one bin.

As for DN/GN, the fact that some folks choose not to use this does not 
mean it is not useful, or that it should be eliminated. Why not leave it 
in, so that people who choose to use it have that option? Otherwise, 
those wanting such functionality will be forced to be creative, and this 
results in less rather than more interoperability.

I think the argument you make below actually suggests the need for a new 
name type (i.e. issuerName), rather than making the case for removing 
DN/GN. The bottom line is that we need non-numeric ways to identify 
peers. How will we do that if these ID types are eliminated?

Scott

Paul Hoffman / VPNC wrote:
>> applications. I know of several ipsec implementations which use fqdn 
>> for remote access policy selection, and without DN, how do we apply 
>> access controls based on certs?
> 
> 
> This has been debated many times before. Some systems have policies that 
> allow any cert that is signed by the trusted CA to have access. That is, 
> the granularity is based on the trusted root, not on the identity. This 
> means that a sysadmin doesn't have to list a zillion users, all of whom 
> have identical access rights; it also means that the user has access as 
> soon as they have their cert, without interaction from the sysadmin who 
> is just going to duplicate what they did for the last user.
> 
> Names are useful for systems that differentiate by user, but they kill 
> the ability to differentiate by certifier.
> 
> --Paul Hoffman, Director
> --VPN Consortium

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 23 Oct 2003 23:40:58 +0300

> >we apply access controls based on certs?

Are they really using it as an IPsec SA selector? I.e not as an IKE SA
identity, but as traffic selector field (there is no way to send that
in the IKEv2 anymore).

The selectors defined in the RFC2401 are for the SPD, and I think that
they should be matching something in the packet. The name selector in
SPD case was something, where you tied SPD entry to the username of
the user who opened the socket.
-- 
[email-masked]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

---

From: "Scott G. Kelly" <[email-masked]>
Date: Thu, 23 Oct 2003 14:08:19 -0700

Hi Tero,

 > the user who opened the socket.

I guess this is somewhat open to interpretation, but I would say the SAD 
  selectors must match the packet, but the SPD selectors must be able to 
represent policy absent a connection - i.e. they must be able to 
represent names in cases where numeric identifiers are not known a 
priori. So, I'm saying that SPD selectors may take on values SAD 
selectors cannot. I think this reflects the intent of 2401, but Steve 
Kent can correct me if not.

Note that this assumes that the SPD really is THE Security Policy 
Database - the *definitive* statement of security policy for the ipsec 
implementation - and that there is no other independent policy db in the 
implementation which is used by ike.

It depends upon how you implement your spd, sad, ike policies, etc, as 
to where the name selector gets used. I think it is logical and 
convenient to extract ike policy into a local representation for the ike 
task, rather than having it always query the ipsec engine for policies, 
though this is an implementation choice, and not a requirement.

I look at it like this: when ike receives a negotiation request from an 
unknown IP address, the remote client must present an identifier (keyid 
or name). In a past life, I implemented the SPD such that there were 
numeric or name IDs possible in selector fields.

If the ike ID was a named type, the name was used in the spd lookup, and 
assuming IKE completed successfully, a SAD entry containing the client's 
numeric selectors would be created, and this would point back to the 
associated SPD entry.

It's clear to me that not everyone would implement this way; I've seen 
implementations where separate DBs for IKE are created, but ultimately, 
the ike task is negotiating on behalf of the rfc2401 implementation, so 
it seems the rfc2401 policy should reflect the identities somehow.

Regardless of how you implement this (names in the SPD, names in ike 
code), we need names. If we remove them from 2401, we have to put them 
into ikev2, else we lose the functionality entirely.

Scott

---

From: Stephen Kent <[email-masked]>
Date: Fri, 31 Oct 2003 11:27:36 -0500

Folks,

I apologize for this confusion. Karen and I spoke about what to do re 
symbolic names in the SPD, before I left for a trip. I was confused 
about which selector types we were discussing, and as a result caused 
Karen to send the issue #89 message.

We do NOT plan to remove the ability to associate a symbolic name 
with an SPD entry. However, 2401 did a poor job of explaining how to 
use this facility and we plan to do a better job in 2401bis.  Karen 
is drafting a revised message about what we plan to say in 2401bis on 
this topic.

Sorry for the confusion. Please comment on the new text when it comes 
out next week.

Steve