Subject: [IPsec] Issue #58: Access control: add ref to IPsec architecture

From: Yaron Sheffer <[email-masked]>
Date: Sun, 3 May 2009 23:35:47 +0300

Yaron:

3.5: this section is extremely liberal on what access control policies
people can implement, but that's too late to change now. However, we CAN at
least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945,
pki4ipsec).

Paul: Not done, take to the list.

Yaron: I propose to add after this noncommittal paragraph:

   The Identification Payloads, denoted IDi and IDr in this memo, allow
   peers to assert an identity 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. {{ Clarif-7.1 }}
   When using the ID_IPV4_ADDR/ID_IPV6_ADDR identity types in IDi/IDr
   payloads, IKEv2 does not require this address to match the address in
   the IP header of IKEv2 packets, or anything in the TSi/TSr payloads.
   The contents of IDi/IDr is used purely to fetch the policy and
   authentication data related to the other party.

The following new text, adapted from RFC 4945:

   The Peer Authorization Database (PAD) as described in RFC 4301 [XX]
describes the use of the ID payload in IKEv2 and provides a formal model for
the binding of identity to policy in addition to providing services that
deal more specifically with the details of policy enforcement.  The PAD is
intended to provide a link between the SPD and the IKE security association
management.  See RFC 4301 [14], Section 4.4.3 for more details.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 4 May 2009 14:57:07 +0300

> least add a reference to RFC 4301, Sec. 4.4.3.1 (as was done in RFC 4945,
...
> management.  See RFC 4301 [14], Section 4.4.3 for more details.

This paragraph looks good for me. 
-- 
[email-masked]