Subject: Confirm decision on identity handling.

From: "Theodore Ts'o" <[email-masked]>
Date: Wed, 09 Apr 2003 17:18:10 -0400

At the San Jose IETF, the IPSEC working group came to a rough
consensus (confirmed by a straw poll) to solve an interoperability
problem as follows:  (quoting from the minutes)

>Comment: Deal with this in 2401bis. Short term solution is to say that what
>goes in ID v CERT  payload is a local matter for now. It need not match.
>
>Comment: SO we will put in sentence that ID payload is for policy lookup and
>does not need to  match anything in CERT payload. Both fields may be used
>for access control decisions, but need not be correlated. 2-1 in favor.

The consensus was relatively rough, and there was a desire expressed
by some to continue the discussion on the list.  

In order to move the discussion forward, we propose the following
addition to section 3.5 of the ikev2-06 as meeting the spirit of the
consensus which was developed in San Francisco.  Append to the first
paragraph, which begins:

   The Identification Payload, denoted ID in this memo, allows peers to
   assert an identify to one another. The ID Payload names the identity
   to be authenticated with the AUTH payload.

.. the following text:

   ... This identity is used for policy lookup, but does not
   necessarily have to match anything in the CERT payload; both fields
   may be used by an implementation to perform access control
   decisions.

Discussion:

The implication of this change, as was discussed in San Francisco, is
that it gives freedom to implementations to make more sophisticated
access control policies, where the responder might use the identity in
the ID payload to look up an access control list, and match the
subject name in the certificate against that ACL, for example.  This
can be advantageous in that do not need to dictate the form of the
subject names in the certificate, which could promote the reuse of
certificates across multiple applications.  The downside is that the
initiator must now allow the configuration of two pieces of
information; there is an additional configuration "knob" which must be
set correct in order for two peers to successfully ocmmunicate.

There are other alternatives, which have been discussed in the past.
Two self-consistent and workable alternatives are presented here: 

2) Require that that IPSEC strictly define the types of X.509
certificate subject names that would be accepted, and precisely define
the matching rules of the identity payload.  This in effect would
predefine the access control policies in the system.  One mechanism
for doing so can be found in section 3.2 of
draft-ietf-ipsec-pki-profile-02.txt.   

3) Specify that the ID payload must not be sent and/or is ignored when
using certificates to authenticate.  In this case, the Certificate
subject name is used to lookup the policy information associated with
the SA instead of the contents identity payload.  (This is essentially
very similar to a proposla contained in Paul Hoffman's
revised-identity I-D.)  

These alternatives have tradeoffs: to differing degress, they
essentially limit flexibility in the choice of certificate names and
the name (identity) used to look up policy information.  In the first
case, the choice of the name found in certificate is limited to
something which passes the matching rule defined in the pki-profile
I-D when the subject name or the subject alt name is matched against
the contents of the identity payload.  In the second case, the name
used to look up the SA policy is constrained to be exactly the subject
name in the certificate, or perhaps the certificate itself.

The latter alternative in particular may impact some implementations
significantly, by changing the key used to look up and manage SA
policy information.  

Decision path:

At the San Francisco meeting, there was clear (but rough) consensus to
explicitly specify that the contents of the ID payload do not have to
match the contents of the CERT payload, and which will require that
initiators have sufficient configuration controls to set both the ID and
Cert payloads.  Proposed text which implements this rough conensus has
been included in this messange.

Since the straw poll indicated that of the people in the room at San
Francisco, that people were 2-1 in favor of this choice, and this
chice should be considered the privileged or "default" choice.
However, especially given the roughness of the consensus there, this
decision must be confirmed on the mailing list.  People who believe
that one of the above alternatives, or some other alternative, should
be adopted instead, are encouraged to speak up.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 9 Apr 2003 17:53:10 -0700

>    may be used by an implementation to perform access control

The proposed addition is close, but doesn't match what many people 
were asking for in the San Francisco meeting, namely to let the use 
of the ID payload be a local option for the receiver. If you want to 
follow what those people asked for, the proposed addition must say 
"This identity may be used for ...".

The sentence to which the new material is appended ("The ID Payload 
names the identity to be authenticated with the AUTH payload.") is 
now not correct. You can't authenticate something with a certificate 
that doesn't necessarily contain it.

We are better off with just the first sentence and a revision of the 
one proposed here by Ted:

    The Identification Payload, denoted ID in this memo, allows peers to
    assert an identify to one another. This identity may be used for policy
    lookup, but does not necessarily have to match anything in the CERT
    payload; both fields may be used by an implementation to perform
    access control decisions.

>set correct in order for two peers to successfully ocmmunicate.

No, there isn't. Sensible implementations will ignore the ID payload 
altogether and simply look for identities out of the certificate. 
That means there is one *less* knob to manage for the sender. The 
sending application can simply pick any identifier from the cert and 
send it in the ID payload.

>draft-ietf-ipsec-pki-profile-02.txt.

To say that the document "precisely defines the matching rules" is 
quite a stretch. It ignores commonly-used Subject OIDs, and gives 
conflicting SHOULD NOTs.

>very similar to a proposla contained in Paul Hoffman's

Not true. The draft explicitly did not say what to do with the 
identities in the certificate. The receiving system might take the 
Subject, or one or more of the SubjectAltNames, or might ignore the 
identities altogether and simply say "if the cert is valid and from a 
trusted root, I'll use it as the identifier, or other possible 
options.

>name in the certificate, or perhaps the certificate itself.

That is not true about the revised identity proposal. The name in the 
SA policy could be a certificate ID, a public key ID, a name from the 
SubjectAltName, or a combination.

--Paul Hoffman, Director
--VPN Consortium

---

From: "[email-masked]" <[email-masked]>
Date: Wed, 09 Apr 2003 19:40:06 -0400

I agree with the additional text, however, I would like to point out 
that such text in no
way precludes an implementation (most likely down the road when(??) 
personal certs
are ubiquitous) from insisting that id payload and cert ID match. The 
point is that there
must be a mapping between ID in the payload and a public key to use for 
auth. The spec
explicitly has not and should not put limits on how this mapping is 
performed.

Jeff

Theodore Ts'o wrote:

> ... the following text:

---

From: Brian Korver <[email-masked]>
Date: Thu, 10 Apr 2003 10:58:33 -0700

Ted,

The proposed text to add sounds good to me.

- brian
[email-masked]

---

From: Brian Korver <[email-masked]>
Date: Thu, 10 Apr 2003 10:58:33 -0700

Ted,

- brian
[email-masked]

---

From: Ravi <[email-masked]>
Date: Fri, 11 Apr 2003 09:24:07 +0530

Hi Ted,

This proposal looks OK to me too.
As mentioned, it requires configuration of both
payload ID information and Certicate ID
information to be present in the configuration.

-Ravi 

-- 

The views presented in this mail are completely mine. The company is not 
responsible for whatsoever.
------------------------------------------------------------------------
Ravi Kumar CH
Rendezvous On Chip (i) Pvt Ltd
Hyderabad, India
Ph: +91-40-2335 1214 / 1175 / 1184

ROC home page <http://www.roc.co.in>

---

From: "Theodore Ts'o" <[email-masked]>
Date: Fri, 11 Apr 2003 15:25:49 -0400

>    access control decisions.

Paul's proposed revision seems clearer and reflects the discussion in
San Francisco.  Does anybody have any problems with this text, or
should we just go with it?

							- Ted

---

From: Ravi <[email-masked]>
Date: Sat, 12 Apr 2003 16:09:13 +0530

Hi,

This text is very clear. I support this wording
-Ravi

--

---

From: Niklas Hallqvist <[email-masked]>
Date: Sat, 12 Apr 2003 15:23:50 +0200

Am I the only one spotting the typo?

s/identify/identity/

Otherwise it is ok.

Niklas

> Date: Sat, 12 Apr 2003 16:09:13 +0530
> From: Ravi <[email-masked]>
> 
> 
> --------------000404070104050906070507
> Content-Type: text/plain; charset=us-ascii; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Hi,
> 
> --------------000404070104050906070507
> Content-Type: text/html; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> 
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
> <html>
> <head>
>   <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
>   <title></title>
> </head>
> <body>
> Hi,<br>
> <pre wrap="">This text is very clear. I support this wording
> -Ravi
> </pre>
> <br>
> Theodore Ts'o wrote:<br>
> <blockquote type="cite" cite="mid20030411192548.GC30438@think">
>   <pre wrap="">On Wed, Apr 09, 2003 at 05:53:10PM -0700, Paul Hoffman / VPNC wrote:
>   </pre>
>   <blockquote type="cite">
>     <pre wrap="">We are better off with just the first sentence and a revision of the 
>     </pre>
>   </blockquote>
>   <pre wrap=""><!---->
>   </pre>
> </blockquote>
> <br>
> <div class="moz-signature">-- <br>
> <title>signature</title>
> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
> <meta name="author" content="Ravi">
> <br>
>  <br>
> responsible for whatsoever.<br>
>  
> <hr width="100%" size="2"><font color="#3333ff"><b><font
>  face="Times New Roman, Times, serif">Ravi Kumar CH<br>
>  Rendezvous On Chip (i) Pvt Ltd<br>
>  Hyderabad, India<br>
>  Ph:</font><font size="3" face="Times New Roman, Times, serif">       +91-40-2335
> 1214 / 1175 / 1184</font></b></font><br>
>  <br>
>  <a href="http://www.roc.co.in">ROC home page</a><br>
>  <br>
>  <br>
>  </div>
> <br>
> </body>
> </html>
> 
> --------------000404070104050906070507--
>

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 14 Apr 2003 09:02:23 -0400

Go with it.
- jeff

---

From: Antonio Forzieri <[email-masked]>
Date: Tue, 15 Apr 2003 09:12:23 +0200

> should we just go with it?
Paul's revision seems good to me. Let's go with it.

-- 
------------------------------------------------
Antonio Forzieri
CEFRIEL - Politecnico di Milano
Tesista Area E-Service Tecnologies
Tel: 02-23954.334 - email: [email-masked]
------------------------------------------------

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2003 18:51:02 -0400

>should we just go with it?

I do have a problem with the proposed text. If we leave the 
interpretation of this payload as a local matter, then we have not 
basis for predictable interoperability, other than the trivial case 
that Paul describes as what "sensible" implementations will do, which 
is to ignore the payload value.

If we believe there is a use for the payload, the  we need to nail 
down how to use it. I am sensitive to the arguments that Paul made in 
SF about how hard it is today to decide how to match cert data 
against this field. I trust his characterization of the difficult of 
the problem. But, that just says that we failed to do the job the 
first time around (in IKE v1 and in 2401) and as a result we have a 
mess. If we adopt the language Paul has proposed, we perpetuate the 
problem.

Is it fair to say that the problem here is that we are in a hurry to 
get IKE done, resolution of this issue will take some time and 
effort, and nobody has volunteered to address the problem in a timely 
fashion?

Steve