Is the following text for the entire section 2.4 OK for you?
(I've borrowed some of your text):
Looks mostly ok.
2.4. Interaction with Peer Authorization Database (PAD)
Section 4.4.3 of [RFC4301] defines the Peer Authorization Database
(PAD), which provides the link between Security Policy Database (SPD)
and the IKEv2. The PAD contains an ordered list of records, with
peers' identities along with corresponding authentication data and
Child SA authorization data. When the IKE SA is being established
the PAD is consulted to determine how the peer should be
authenticated and what Child SAs it is authorized to create.
When using NULL Authentication, the peer identity is not
authenticated and cannot be trusted. If ID_NULL is used with NULL
Authentication, there is no ID at all. The processing of PAD
described in Section 4.4.3.4 of [RFC4301] must be updated.
The NULL authentication needs to be added as one of supported
authentication methods. This method MUST contain no authentication
data.
I do not understand why there is MUST NOT for authentication data.
Yes, there is no authentication data, but that is not really something
that needs to be enforced in MUST level. Perhaps just change
This method MUST contain no authentication data.
to
The NULL authenticaiton method does not have any authentication
data.
or similar.
OK.
To add support for ID_NULL, it needs to be included into the
list of ID types, specified in Section 4.4.3.1 of [RFC4301]. The
matching rule for ID_NULL is just whether this type is used, i.e. no
actual ID matching is done, as ID_NULL contains no identity data.
Section 4.4.3.3 of the [RFC4301] describes how the IKE ID is matched
against the SPD entries. When using the NULL authentication method
those matching rules MUST include matching of a flag in the SPD entry
^
change "a flag" to "a new flag", so it clearly indicates we are
talking about something that is modified in the RFC4301, not something
that already is there.
Done.
specifying whether unauthenticated users are allowed to use that
entry. I.e. each SPD entry needs to be augmented to have flag
specifying whether it can be used with NULL authentication or not,
and only those rules explictly having that flag turned on can be used
with unauthenticated connections.
I wonder should we explitly mention something about dangers which can
happen if this flag is not implemented properly, i.e. because the
RFC4301 describes that we lookup SPD based on the ID, and that ID
is not authenticated when using NULL authentication, we cannot mix it
with authenticated IDs. Either here, or in the security considerations
section.
We do already have section 3.3 which covers this, but it does not go
to this kind of lower level details of PAD and SPD. On the other hand
we already describe that you need the flag, and we warn that combining
authenticated and unauthenticated peers in same host is dangerous, so
that might be enough.
But it is said that unauthenticated IDs can only be matched if SPD entry has
a new flag set. I think it must be enough.
Valery.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
