In section 2.3 I think the first MUST for INITIAL_CONTACT should be
rephrased so that it says that it MUST NOT do normal INITIAL_CONTACT
processing for unaithenticated INITIAL_CONTACT. I think using that
INITIAL_CONTACT as a hint to start dead peer detection is ok, but
current text says it MUST be ignored so you cannot even use it as
hint.
I.e. replace:
For that reason the INITIAL_CONTACT
notifications MUST be ignored for IKE SAs using NULL Authentication.
with
For that reason the INITIAL_CONTACT
notifications MUST NOT be used to delete any other IKE SAs without
verification.
And, yes, the term verification is big vague here, and it is on
purpose. I.e. verification can mean different things in different
cases, but in minimal case it would mean the dead peer check.
The rest of the section is ok. On the other hand if someone creates
second IKE SA and because it is not only SA does not send
INITIAL_CONTACT notification, it would be quite useless to start dead
peer detection for the IKE SA sharing same IP-address, because the new
IKE SA created did already tell that this is not the only IKE SA...
--
The section 2.4 is good addition to the draft, and it does clarify
things.
One problem I have is that in the description there is only one entry
for the NULL authentication, and all NULL authentications use the same
entry. This is fine for cases where we want to do firewall type rules
and restrictions for connections.
This is not good when we use PAD to select the service where you want
to connect.
I.e. it would be possible to provide remote ID of server1.example.com
when you want to connect to the server1.example.com and remote ID of
server2.example.com when you want to connect server2.example.com.
Depending which ID you provide different SPD entries are selected. If
both of those are allowed for NULL authentication we still need a way
to select which of the SPD entries are allowed.
Also now the processing rules of RFC4301 is overwritten when NULL
authentication is used. I think this is wrong. I think better would be
to consider NULL authentication as one type of authentication in PAD.
Another issue is that I think we should also add ID_NULL as one
identity type which PAD can match against. I.e. add ID_NULL to the
list in 4.4.3.1 in the RFC4301. So ID_NULL can only be used if PAD
entry specifies it to be allowed, and it cannot be used in any other
entry if they do not allow it.
PAD already specifies which authentication methods are allowed for
which connection, and what IDs can be used for it. I.e. if none of the
PAD entries allows NULL authentication as authentication method and
none of the PAD netries allows ID_NULL as identity type, then NULL
authentication method and ID_NULL cannot be used.
If you add new PAD entry (in suitable place in ordered PAD) which
allows NULL authentication, then NULL authentication is allowed. If
you limit that entry to only allow ID_NULL then only ID_NULL can be
used with NULL authentication. If you say that any ID can be used with
NULL authentication then clients ID is used to select one of the
multiple PAD entries allowing NULL authentication and the SPD will be
selected based on that.
The draft has text:
When using NULL Authentication, the peer identity is not
authenticated and cannot be used. 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 first sentence is incorrect. You can use it, you just cannot trust
it. It can be used to select one of the untrusted PAD/SPD entries to
for example select which service the client wants to connect. All of
the identities will have same trust level, i.e. none, but they can
still be used to select things.
I would change the first sentence to say:
When using NULL Authentication, the peer identity is not
authenticated and cannot be trusted.
The following text explaining the special search to be done with NULL
authentication is dangeours, specially when you say that it is only
SHOULD to check regular PAD first before going to that special rule.
I would rewrite that to say that NULL authentication is just one
authentication method, and ID_NULL is just one more identity type that
can be used in PAD to match the rules. In normal case the NULL
authentication would be configured so that it is one of the last PAD
entries which is checked only after all other PAD entries are checked,
and it would then allow unauthenticated connections too.
But in some situations the PAD might also be configured differently,
and there might be multiple PAD entries for NULL authentication, and
different SPD entries depending on the ID payloads etc. One thing we
need to make sure is that IDs from unauthenticated connections cannot
be mixed with IDs from authenticated connections when matching SPD.
I.e when using SPD Name parameter, those two IDs needs to be
separated. This can be done in multiple ways depending on the
implementation. In some implementations the pointers from PAD to SPD
do not actually use that kind of names, but PAD has direct pointer to
specific SPD entry to be used with that PAD entry. This works fine
with NULL authentication (and ID NULL).
In other cases the PAD entry has some kind of star-entry, and in that
case the SPD is looked for matched entry based on the ID. In this case
we need to separate those two SPD entries, one with authenticated IDs
and another with unauthenticated IDs. In your text with PAD you ignore
this second check completely.
So for PAD checking we do not need to any special rules (execpt than
adding NULL authentication and ID NULL to allowed list of
authentication types and ID types), but for SPD checking we do need
to do special rules.
So this section needs to be expanded to cover the SPD matching, and I
think the last two paragraphs needs to be replaced with just:
The PAD described in the Section 4.4.3 of the IPsec Architecture
document [RFC4301] is ordered database consisting information like:
allowed authentication methods, and constraints for the IDs that can
be asserted. To add support for the NULL authentication, the NULL
authentication just needs to be supported as one authentication
method, and to add support for ID_NULL, it needs to be added to the
list of ID types supported by PAD. When using ID_NULL the matching
rule for it is just whether ID_NULL type was used, i.e. no actual ID
mathing is done.
to cover PAD case, and then add text for SPD separtely.
For the SPD we need to make sure that authenticated and NULL
authentication SPD entries are not mixed. I.e. if I have PAD rule
saying that ID kivi...@iki.fi can use share-secret authentication and
then SPD rule of kivi...@iki.fi is used, and that SPD rule says that
ID kivi...@iki.fi can create SA between ip-assigned by server <->
192.168.0.0/16 tunnel mode. And then I have (lower priority) PAD rule
saying any ID can use NULL authentication, then when we are searching
for the suitable SPD rule for that PAD entry and the remote peer sent
ID kivi...@iki.fi, we must not select the SPD rule meant for
authenticated user of kivi...@iki.fi.
Instead we can have lower priority SPD rule saying any ID (even
unauthenticated ones) can create transport mode SA (or tunnel mode SA
covering only those endpoint addresses) between the IP-address given
by the server to using PFP (populate from packet) rule matching
exactly one IP address.
This matching is done by in the section 4.4.1.1 Selectors of the
RFC4301 when using 1st format of "Name" selector. Instead of matching
named SPD entry directly, we also check that the SPD MUST have flag
enabled allowing unauthenticated uses too before "Name" selector can
be matched for that SPD entry. In our example above the first
kivi...@iki.fi entry would be skipped in unauthenticated case, as it
that SPD entry is not allowed for the unauthenticated cases, and later
wildcard entry would be used instead.
This also allows us to have multiple SPD entries for the
unauthenticated traffic, i.e. we could have one saying ID *@iki.fi
(unauthenticated) can create tunnel mode SA between the IP-address
given to them and 192.168.5.0/8 network, and another one saying that
ID *@acr.fi (unauthenticated) can create tunnel mode SA between the
IP-address given to them and 192.168.8.0/8 network. I.e. this would
allow the client to select whether it wants to talk to the
iki.fi-network or acr.fi-network in the remote end, still doing that
in unauthenticated and anonymous ways.
This matching is described also section 4.4.3.3 Child SA Authorization
Data of the RFC4301, so we need to add text covering this:
In section 4.4.3.3 of the IPsec Architecture document [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 specifying whether
unauthenticated users are allowed to use that SPD 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.
--
kivi...@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
