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.
smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
