Subject: 2401bis Issue # 93 -- Clarification re: the selector "name"

From: Karen Seo <[email-masked]>
Date: Wed, 25 Feb 2004 14:28:00 -0500

Folks,

Here's a description and proposed approach for:

IPsec Issue #: 93

Title:		Clarification re: the selector "name"

Description:
============
The current 2401bis contains updates (from 2401) to the text on the 
selector "name", but additional clarification is still needed, e.g., 
how to use the field, correspondence to IKEv2 fields, etc.

Proposed approach:
==================
Replace the current 2401bis text with the text below.  Note: We will 
also need to add some text to the earlier discussion of the SPD-S, to 
match the back pointer below.

Name: A name may be used as a symbolic identifier for an IPsec source 
or destination address.  It is not a selector in the same sense as a 
literal address, protocol, port, etc. As noted earlier, the SPS-S can 
be divided into named entries and unnamed entries. The latter entries 
are matched to traffic based on the selector types and values, 
whereas the named entries are selected based on names. Named SPD 
entries are used in two ways:

1. A named SPD entry is used by a responder (vs. initiator) in 
support of access control when IP address selectors would not be 
appropriate, e.g., for "road warriors." The name used to match this 
field is communicated during the IKE negotiation in the ID payload. 
In this context, the remote system's IP address (inner IP header in 
tunnel mode) is bound to the SAD entry created by the IKE 
negotiation. All IPsec implementations MUST support this use of names.

2. A named SPD entry may be used by an initiator to identify a user 
for whom an IPsec SA will be created (or for whom traffic may be 
bypassed). Support for this use is optional for multi-user, native 
host implementations. 

A named SPD entry MUST set either the source or destination IP 
address selector to NULL, consistent with its use in support of the 
first or second scenario. The identifiers employed in named SPD 
entries are one of the following four types:

	a. a fully qualified user name string (email), e.g.,
	   [email-masked]
	   (this corresponds to ID_RFC822_ADDR in IKEv2)                       

	b. a fully qualified DNS name, e.g.,
	   foo.example.com
	   (this corresponds to ID_FQDN in IKEv2)

	c. X.500 distinguished name, e.g.,
	   C = US, SP = MA,
	   O = BBN Technologies, CN = Stephen T. Kent
	   (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding)

	d. a user's name in a local system context
	   (this corresponds to ID_KEY_ID in IKEv2)

Thank you,
Karen

---

From: "Mohan Parthasarathy" <[email-masked]>
Date: Wed, 25 Feb 2004 15:45:03 -0800

Karen,

Just one question below..
 
> Title: Clarification re: the selector "name"
Should (d) be constrained to be a user name ? This is just whatever the two systems understand.
It could be an employee ID or different thing in other contexts. ID_KEY_ID carries opaque
octet stream as per the definition. So, can we not leave it flexible ?

thanks
mohan