Subject: [IPsec] Review of draft-ietf-ipsecme-ikev2-null-auth-03

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Feb 2015 12:30:43 +0200

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 [email-masked] can use share-secret authentication and
then SPD rule of [email-masked] is used, and that SPD rule says that
ID [email-masked] 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 [email-masked], we must not select the SPD rule meant for
authenticated user of [email-masked].

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
[email-masked] 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 [email-masked]
(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 [email-masked] (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.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Feb 2015 17:21:39 +0300

Hi Tero,

thanks for your detailed review.

>   notifications MUST NOT be used to delete any other IKE SAs without

OK.

> IKE SA created did already tell that this is not the only IKE SA...

Isn't it already presumed? Do you think we should mention this explicitely?
How about:

    Additionally, the event of creating a new unauthenticated IKE SA
    containing INITIAL_CONTACT notification can be used to trigger
    an out-of-order check on existing unauthenticated IKE SAs,
    possibly limited to identical or close-by IP addresses or to identical 
identities
    of the just created IKE SA.

(added wods "containing INITIAL_CONTACT notification ").

> multiple PAD entries allowing NULL authentication and the SPD will be

Unfortunately with the current matching rules
you cannot specify in PAD that the remote ID can be anything.
For example, if ID Type is Key ID, then only exact
match is allowed by RFC4301, so you cannot express that
for this unauthenticated connection client's ID of type
Key ID is irrelevant.

>   authenticated and cannot be trusted.

OK.

>  unauthenticated connections.

Is the following text for the entire section 2.4 OK for you?
(I've borrowed some of your text):

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.  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
   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.

Regards,
Valery.

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

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 5 Feb 2015 16:54:04 +0200

> Isn't it already presumed? Do you think we should mention this

No, when you did say that the INITIAL_CONTACT is always ignored :-) If
you ignore it you cannot use that information whether it was there
not... Thats why I complained about MUST be ignored. 

> (added wods "containing INITIAL_CONTACT notification ").

Looks good.

> you cannot specify in PAD that the remote ID can be anything.

Why not? The RFC4301 talks about IKE ID, it does not anywhere specify
that you must only use the remote ID when matching PAD. If you support
IKEv2 You Tarzan, me Jane feature, you need to do that anyways.

Again this is implementation dependant, and you can implement this in
multiple ways. One way to implement is to have completely separate
SPDs for each local identities, and that would be useful if you want
to support virtual routers or similars. In some cases you might simply
have some rules giving both local and remote identities, and match
both, or some rules having only one. 

> for this unauthenticated connection client's ID of type

Sure you can. The RFC4301 sets the minimum bar for the matching rules.
If your implementation wants it can take the Key ID, divide it to
factors, and select the SPD entry based on the largist factor the
number has :-)

And it would still be according to the RFC4301 if you ALSO support
exact match. In the RFC4301 it does say:

   The Key ID field is defined as an OCTET string in IKE.  For this name
   type, only exact-match syntax MUST be supported (since there is no
   explicit structure for this ID type).  Additional matching functions
   MAY be supported for this ID type.

I.e. additional matching functions MAY be supported... 

Bah, running late again, I will come back to final version 2.4 section
tomorrow...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Thu, 5 Feb 2015 11:12:37 -0500 (EST)

> cases, but in minimal case it would mean the dead peer check.

I'm okay with that.

> This is not good when we use PAD to select the service where you want

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.

> to consider NULL authentication as one type of authentication in PAD.

Exactly!

> entry if they do not allow it.

Yup.

>   authenticated and cannot be trusted.

Sounds good to me.

> can be used in PAD to match the rules.

Yes.

>  rule for it is just whether ID_NULL type was used, i.e. no actual ID

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

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 6 Feb 2015 11:27:43 +0200

> (I've borrowed some of your text):

Looks mostly ok. 

>    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
     	   	    	       	       		     ^

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. 
						     
>    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-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 6 Feb 2015 14:25:01 +0300

OK.

> talking about something that is modified in the RFC4301, not something

Done.

> authenticated and unauthenticated peers in same host is dangerous, so

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.