Valery Smyslov writes:
> 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.
> 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.
> 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.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
