Subject: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-00.txt

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 24 Dec 2013 17:47:30 +0400

Hi all,

I've just posted a draft, defining NULL Authentication method in IKEv2.
This method may be used for anonymous access or in situations,
when peers don't have any trust relationship, but still want
to get protection at least against passive attacks.

Regards,
Valery.

----- Original Message ----- 
From: <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; "Valery Smyslov" <[email-masked]>
Sent: Tuesday, December 24, 2013 5:40 PM
Subject: New Version Notification for 
draft-smyslov-ipsecme-ikev2-null-auth-00.txt

A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-00.txt
has been successfully submitted by Valery Smyslov and posted to the
IETF repository.

Name: draft-smyslov-ipsecme-ikev2-null-auth
Revision: 00
Title: The NULL Authentication Method in IKEv2 Protocol
Document date: 2013-12-24
Group: Individual Submission
Pages: 8
URL: 
http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-null-auth/
Htmlized: 
http://tools.ietf.org/html/draft-smyslov-ipsecme-ikev2-null-auth-00

Abstract:
   This document defines the NULL Authentication Method for IKEv2
   Protocol.  This method provides a way to omit peer authentication in
   IKEv2 and to explicitely indicate it in the protocol run.  This
   method may be used to preserve anonymity or in situations, where no
   trust relationship exists between the parties.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Dec 2013 00:42:50 +0200

Hi Valery,

Thanks for posting this draft.

One quick comment: the interaction of your proposal with EAP is not 
clear to me, i.e. when one peer uses Null auth and the other uses EAP. 
There are cases where this should be forbidden (e.g. MSCHAP, where the 
unauthenticated peer can mount a dictionary attack) and other cases 
where this is OK. Specifically, for the methods listed as "safe" in Sec. 
4 of RFC 5998, I believe this use would be secure.

Happy holidays!

	Yaron

On 12/24/2013 03:47 PM, Valery Smyslov wrote:
> ----- Original Message ----- From: <[email-masked]>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 25 Dec 2013 09:18:52 +0400

Hi Yaron,

> One quick comment: the interaction of your proposal with EAP is not clear 
> to me, i.e. when one peer uses Null auth and the other uses EAP. There are 
> cases where this should be forbidden (e.g. MSCHAP, where the 
> unauthenticated peer can mount a dictionary attack) and other cases where 
> this is OK. Specifically, for the methods listed as "safe" in Sec. 4 of 
> RFC 5998, I believe this use would be secure.

Actually, I think that NULL Auth should not be used with EAP.
Section 2.16 of RFC5996 states:

   In addition to authentication using public key signatures and shared
   secrets, IKE supports authentication using methods defined in RFC
   3748 [EAP].  Typically, these methods are asymmetric (designed for a
   user authenticating to a server), and they may not be mutual.  For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public-key-signature-based authentication of the responder to the
   initiator.

I agree with you, that in some cases using NULL Auth with EAP
might be secure, but as IKEv2 already requires responder
to use signature auth with EAP, I don't see any reason to change it.

Do you think it's worth to mention that in the draft and provide
a reference to the text from RFC5996?

> Yaron

Happy New Year!

Valery.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Dec 2013 07:41:34 +0200

Hi Valery,

Yes, between EAP+signature (RFC 5996) and EAP+EAP (RFC 5998), there's 
very little justification for EAP+null, and it is very likely to create 
security issues. I think we should mention EAP, and expressly forbid it 
in this context (MUST NOT).

Thanks,
	Yaron

On 12/25/2013 07:18 AM, Valery Smyslov wrote:
>> where this is OK. Specifically, for the methods listed as "safe" in
>> Sec. 4 of RFC 5998, I believe this use would be secure.
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 30 Dec 2013 19:44:41 -0500 (EST)

> to get protection at least against passive attacks.

This is what we (libreswan) have started implementing as well, although we
called it AUTH_NONE instead of AUTH_NULL. We use private range number 201
for this exchange type. We also followed the PSK exchange method. But
we are still looking at some issues and therefor have not yet written
out our implementation as draft yet. For those interested, libreswan
developers are meeting up in San Francisco in the second and third week
of January to work on OE (both anonymous and authenticated). Ping me if
you would like to attend.

Valery's draft is a start, but we need to address a lot more than just
defining a new IKEv2 AUTH method:

1) Use of IDs

I don't think we should allow any IDs, as there could be conflicts with
other non-anonymous connections. Or possibly a way to detect which
non-anonymous IDs are accepted at the remote. I was leaning towards
mandating the ID to be "anonymous" to make it extremely clear that this
is an anonymous connection.

2) Endpoints

Your draft does not state anything about the traffic selectors. I think
it is important to specify it for only a single host-to-host connection
only. Deployments who want to protect a whole subnet can use similar
tricks to load balancers and capture port (4)500 and use the NAT-T
capability of IPsec. Allowing subnet-to-subnet is just too dangerous
because there are no verifiable claims yet about who owns what IP range.

3) Mode

I would like to only support tunnel mode and not transport mode, due to
the interaction with NATs - particularly multiple endpoints behind the
same NAT router. We would hope this happens a lot if everyone enables
OE (anonymous and non-anonymous). Obviously using AH also makes no sense
so we should note that this is only valid for ESP.

4) Mandatory PFS

It should be mandatory to do PFS with an appropriate DH group.

5) Priority

The priority of the SPDs of any anonymous IPsec connection should be
lower than the priority of any non-anonymous SPD. This ensures that
an anonymous IPsec connection can never steal traffic from an
authenticated IPsec connection.

non-anonymous with anonymous IPsec

Now this only covers anonymous IPsec. While better than plaintext,
we do hope servers with stable hostnames will use IPSECKEY records to
provide their public key, and that the clients will mostly use this new
auth-none, while the server responds with its FQDN ID so the client can
verify the connection is not MITMed. In fact, I think it is better for
roaming devices to remain as anonymous as possible by not providing
the server with an identity (and why I also do not like your proposal
of allowing and ignoring the identity).

I have not yet solved the issue of two servers and "return traffic". Say
host A on public IP initiates anonymously to host B on public IP. Let's
say both are mail servers. Host A has authenticated host B. Host A
can now send traffic to host B encrypted. Host B can respond to that
traffic. While the tunnel is up, host B needs to connect to host A
for unrelated traffic. It has an IPsec connection up, but it has not
authenticated this connection. It should not initiate traffic to host A.
BTNS tried to solve this problem with changing the kernel and doing
channel binding, but I don't think that solution has support anywhere.
I can think of some methods on Linux to "hack" detection and support,
but I'm not happy about it yet.

Evil ranges

Another unresolved problem of using tunnel mode is if a client uses
somebody elses IP range. eg my laptop behind NAT using 8.8.8.8 should
not be able to steal the remote's google DNS traffic. Again, I can
see linux hacks to implement this but I'm still not happy with this.
One way out is to use CP and assign IP addresses but since our clients
and servers will have thousands of these of connections there will be
clashes. Using IPv6 is possible but I'm not convinced the v6-in-v4 IPsec
has seen enough deployment and might not be implemented widely.

Other kinds of semi-anonymous connections

We are trying to limit the number of different kinds of OE connections
possible to make it as easy as possible to represent things back to the
user. So we have left things like "ssh style leap of faith" out of this.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 31 Dec 2013 10:33:05 +0200

Hi Paul, Valery,

Regarding IDs, there is value in sending them if you are later able to 
confirm the identity, or at least "bind" it to the connection. For 
example, if the human owners of the peers make a phone call and exchange 
fingerprint values. Or (more far fetched) if both sides use raw public 
keys, instead of a shared secret, and these PKs are later certified by 
someone that both peers trust. Calling everyone "anonymous" means that 
you cannot display *anything* to the user.

Regarding single endpoint addresses vs. subnets, we should discuss 
various ways of proving address "ownership" (whatever that means). For 
example: random reachability tests, BGP with RPKI.

Thanks,
	Yaron