On Thu, 5 Feb 2015, Tero Kivinen wrote:

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.

I'm okay with that.

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.

Yes, I had the exact same issue with that part on my TODO list. There
can be different "security groups" that all allow AUTH_NULL/ID_NULL.

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.

Exactly!

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.

Yup.

I would change the first sentence to say:

  When using NULL Authentication, the peer identity is not
  authenticated and cannot be trusted.

Sounds good to me.

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.

Yes.

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.

Okay with some minor changes (like not using the word "just" :)
I saw Valery had some feedback too, so will coordinate with him.

Paul

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to