Subject: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2 Protocol

From: Yaron Sheffer <[email-masked]>
Date: Sun, 07 Sep 2014 21:53:38 +0300

Dear working group,

This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a 
WG document. Please respond to this mail with a Yes or No and a short 
rationale, at latest by Friday Sep. 12.

Thanks,
	Yaron

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 8 Sep 2014 10:27:25 +0400

Yes.

Obviously, as the author of the document I can see its value,
which is describet in the document itself.
And I think it's better to standardize it with
more people involved, than as individual submission.

Regards,
Valery.

----- Original Message ----- 
From: "Yaron Sheffer" <[email-masked]>
To: "ipsec" <[email-masked]>
Sent: Sunday, September 07, 2014 10:53 PM
Subject: [IPsec] Call for adoption: The NULL Authentication Method in 
IKEv2Protocol

> Dear working group,
>
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG 
> document. Please respond to this mail with a Yes or No and a short 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Sep 2014 09:04:26 -0400 (EDT)

On Sun, 7 Sep 2014, Yaron Sheffer wrote:

> Subject: [IPsec] Call for adoption: The NULL Authentication Method in IKEv2
>     Protocol
> 
> Dear working group,
>
> document. Please respond to this mail with a Yes or No and a short rationale, 
> at latest by Friday Sep. 12.

Yes. This feature is very useful for opportunistic scenario's to defend
against pervasive monitoring with no IPsec configuration needed on the
client side. We are implementing this and it is important to
interoperate with other implementations.

Paul

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 14:54:09 +0000

On Sep 7, 2014, at 2:53 PM, Yaron Sheffer <[email-masked]> wrote:

> Dear working group,
> 
> This is a call for adopting draft-smyslov-ipsecme-ikev2-null-auth as a WG document. Please respond to this mail with a Yes or No and a short rationale, at latest by Friday Sep. 12.

Maybe.

I understand and support the rationale for this draft.  

The Security Considerations seems to be inadequate.  Whenever possible, real authentication should be used.  So the Security Considerations should explicitly and strongly emphasize that, and recommend that products that incorporate Null authentication should strive to avoid its use whenever possible, and steer users away from its use when they can.

A related question: does the use of Null authentication open up the Bellovin attack?  It seems that it would.  If so, my answer changes to “NO”.

	paul

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Mon, 8 Sep 2014 17:10:07 +0000

Hi Valery

I have one Q.

If endpoint receives a request to create an unauthenticated IKE SA
from the IP address, which is configured on the endpoint to be
authenticated, the request SHOULD be rejected.

Why is this not MUST be rejected ? Otherwise an attacker could trick the
responder into revealing their identity (maybe some words around this
also?).

Thanks

Graham

On 08/09/2014 07:27, "Valery Smyslov" <[email-masked]> wrote:

>>WG

---

From: Paul Wouters <[email-masked]>
Date: Mon, 8 Sep 2014 14:17:44 -0400 (EDT)

> The Security Considerations seems to be inadequate.  Whenever possible, real authentication should be used.  So the Security Considerations should explicitly and strongly emphasize that, and recomm…

I think that is better formulated as "use null authentication only if the
alternative is to send plaintext".

> A related question: does the use of Null authentication open up the Bellovin attack?  It seems that it would.  If so, my answer changes to “NO”.

I find multiple references to a "Bellovin attack", but all seem to be active
attacks. Unauthenticated connections are not protected from active attacks.
However, with IKE one peer can authenticate the other without letting itself
be authenticated - like TLS clients. That _is_ a protection against
active attacks while still using null auth in one direction.

Paul

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 18:37:35 +0000

On Sep 8, 2014, at 2:17 PM, Paul Wouters <[email-masked]> wrote:

> alternative is to send plaintext”.

That is a very good way to state it.  Thanks.

> active attacks while still using null auth in one direction.

I was referring to https://www.cs.columbia.edu/~smb/papers/badesp.pdf .

The existing security considerations section refers to a man in the middle attack.  Bellovin’s attack is not a man in the middle attack.  It does not require being able to modify the data stream under attack at all.  For that reason, it is likely to be easier to execute and harder to detect.  

In any event, if we’re going to have a new IPSec mode that weakens the normal properties of IPSec, we need to be very explicit and very detailed about what precisely you lose by using this mode.  I would expect a security considerations section that takes up at least half the total page count of the document, as opposed to just a third of a page as it is right now.

For example, right now the security considerations section does NOT say that “Unauthenticated connections are not protected from active attacks”.  It only says that they are not protected from man in the middle attacks. 

	paul

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 08 Sep 2014 21:52:55 +0300

Paul and Paul (and yet another Paul),

Just a process comment: this is a call for adoption, a "first call" not 
a last call. There may still be many issues with the document, which we 
will fix as a group *if* the document is adopted. So is the document 
dealing with an important problem, and is it good enough as a starting 
point of a solution?

Thanks,
	Yaron

---

From: <[email-masked]>
Date: Mon, 8 Sep 2014 19:51:11 +0000

On Sep 8, 2014, at 2:52 PM, Yaron Sheffer <[email-masked]> wrote:

> Just a process comment: this is a call for adoption, a "first call" not a last call. There may still be many issues with the document, which we will fix as a group *if* the document is adopted. So is the document dealing with an important problem, and is it good enough as a starting point of a solution?
> 
> Thanks,
> 	Yaron

Thanks for pointing that out.  Thinking of this as “first call” helps a lot.

Ok, then my answer is “yes” — reason being “this is an important problem to fix and the direction makes sense”.

	paul

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 8 Sep 2014 20:22:50 -0400

The subject line (and the comment on Bellovin attack) caught my eye. I
don't follow the discussions in this list so I don't know how much the need
and dangers of unauthenticated methods were discussed here. I want to point
out that (and probably many did before me) that un-authentication is a very
tricky option especially in a protocol that was created with mutual
authentication as a core requirement and assumption. I can see potential
benefits and uses but I can also see it abused and misused (the internet
draft doesn't do too good a job warning about it but even if it did, people
will misuse it).

But requirements aside, I cannot vow for the security of IKE's key exchange
in a one-way authentication mode. No one (that I know, definitely not me)
designed this protocol to support one-way authentication. So the question
of whether it is secure in this setting has not been investigated.
Moreover, I see that the draft uses shared-key fields for the anonymous
side of the communication and, I imagine, the other can use signature-based
authentication. What security properties do you get from that mix-and-match
authentication methods?

One likely misuse of this technique is that people will use unauthenticated
(or one-way) IKE and will run some other authentication on top of it (say,
password based or whatever). Well, protocols do not necessarily compose
securely. TLS had many failures like that (BEAST, re-negotiation, triple
handshake, ...) and IPsec saw examples of that in the combinations of
unauthenticated ESP and AH. IKE's cryptographic design has endured the test
of time but these variations (or improvisations) endanger it.

Finally, since Bellovin's attack was mentioned, I want to make sure that no
one is thinking of not using the MAC authentication at the IP packet level,
right?

Hugo

On Mon, Sep 8, 2014 at 10:54 AM, <[email-masked]> wrote:

> The Security Considerations seems to be inadequate.  Whenever possible,
> real authentication should be used.  So the Security Considerations should
> explicitly and strongly emphasize that, and recommend that products that
> incorporate Null authentication should strive to avoid its use whenever
> possible, and steer users away from its use when they can.
>
> A related question: does the use of Null authentication open up the
> Bellovin attack?  It seems that it would.  If so, my answer changes to “NO”.
>
>         paul
>

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Sep 2014 11:11:21 +0400

Hi Graham,

> responder into revealing their identity (maybe some words around this

I was thinking of two possible cases here.
First, even if the initiator was able to certify its identity, 
it might want to keep anonymity for this particular
connection (for example to prevent tracking its
activity). And the other case - the responder's configuration
could be out of date and the IP address it was
configured to be authenticated could already
belong to some other, anonymous host.

Anyway, while SHOULD is pretty strong requirement,
it is not ultimate here: I'm not absolutely sure
that the above cases completely justify it over MUST.
We can discuss it.

And you are right - some (I dare to say "many")
words still need to be added into the Security Considerations
section.

Regards,
Valery.

---

From: Daniel Migault <[email-masked]>
Date: Tue, 9 Sep 2014 09:42:00 +0200

Hi,

I am in favor of adopting this draft. In my case I see it as a way to ease
IPsec deployment in IoT with opportunistic encryption.

BR,
Daniel

-- 
Daniel Migault
Orange Labs -- Security
+33 6 70 72 69 58

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 9 Sep 2014 15:58:11 +0400

Hi Hugo,
  The subject line (and the comment on Bellovin attack) caught my eye. I don't follow the discussions in this list so I don't know how much the need and dangers of unauthenticated methods were discussed here. I want to point out that (and probably many did before me) that un-authentication is a very tricky option especially in a protocol that was created with mutual authentication as a core requirement and assumption. I can see potential benefits and uses but I can also see it abused and misused (the internet draft doesn't do too good a job warning about it but even if it did, people will misuse it).
I agree that the draft's Security Consideration section in its current form is incomplete.
And I hope that if the draft is adopted then it will draw an attention of many people,
who will help to improve the Security Considerations to list all the caveats,
to make all possible warning and to give advice how to safely use this mode.
  But requirements aside, I cannot vow for the security of IKE's key exchange in a one-way authentication mode. No one (that I know, definitely not me) designed this protocol to support one-way authentication. So the question of whether it is secure in this setting has not been investigated. Moreover, I see that the draft uses shared-key fields for theanonymous side of the communication and, I imagine, the other can use signature-based authentication. What security properties do you get from that mix-and-match authentication methods? 
IKEv2 currently allows the peers to use different authentication methods. 
So, if one of the peers uses preshared key, while the other uses 
digital signature, then it is considered legal and secure from
protocol's design point of view. If the peer, using preshared key in this scenario,
uses key, known to everyone, then we will get one-way authentication
with the current IKEv2. The next step, that the draft does - get rid of 
well-known preshared key and compute the content of the AUTH Payload
the same way it is computed currently in IKEv2 when it is used
with non key generating EAP methods - using SK_pi (or SK_Pr) as the key
I believe the draft doesn't change the way cryptography is used in IKEv2.
  One likely misuse of this technique is that people will use unauthenticated (or one-way) IKE and will run some other authentication on top of it (say, password based or whatever). Well, protocols do not necessarily compose securely. TLS had many failures like that (BEAST, re-negotiation, triple handshake, ...) and IPsec saw examples of that in the combinations of unauthenticated ESP and AH. IKE's cryptographic design has endured the test of time but these variations (or improvisations) endanger it.
Well, sometimes mutual authentication is impossible or undesirable.
Sometimes privacy is more important and people are ready to
sacrifice some level of security to keep their privacy.
And sometimes the choice is - either use plaintext
or unauthenticated encryption. The latter at least
prevents passive eavesdropping...
  Finally, since Bellovin's attack was mentioned, I want to make sure that no one is thinking of not using the MAC authentication at the IP packet level, right? 
Absolutely.
  Hugo
Regards,
Valery Smyslov.
  On Mon, Sep 8, 2014 at 10:54 AM, <[email-masked]> wrote:

    Maybe.

            paul

------------------------------------------------------------------------------

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Tue, 9 Sep 2014 20:37:15 +0000

Hi

Thanks for the clarifications.

I really like the idea of this - as Daniel has said it's well suited for
IoT, but I'm wondering if this could then lend IKEv2 into a similar
concept as 'https' - secure channel and authentication of the headend and
then initiators credentials are sent by some other means..

As you say I think it needs a lot of thought into the security
considerations.

cheers

---

From: Hugo Krawczyk <[email-masked]>
Date: Thu, 11 Sep 2014 00:01:41 -0400

I didn't know (or remember) that IKEv2 allows for different directional
authentication mechanisms.
In any case, as a general rule, the fact that two methods are secure,
doesn't mean that mix-and-match-ing them (or taking a subset) is still
secure.
Particularly for IKEv2, I do not know of any work that has shown such
security.

Hugo

On Tue, Sep 9, 2014 at 7:58 AM, Valery Smyslov <[email-masked]> wrote:

> But requirements aside, I cannot vow for the security of IKE's key
> exchange in a one-way authentication mode. No one (that I know, definitely
> not me) designed this protocol to support one-way authentication. So the
> question of whether it is secure in this setting has not been investigated.
> Moreover, I see that the draft uses shared-key fields for theanonymous side
> of the communication and, I imagine, the other can use signature-based
> One likely misuse of this technique is that people will use
> unauthenticated (or one-way) IKE and will run some other authentication on
> top of it (say, password based or whatever). Well, protocols do not
> necessarily compose securely. TLS had many failures like that (BEAST,
> re-negotiation, triple handshake, ...) and IPsec saw examples of that in
> the combinations of unauthenticated ESP and AH. IKE's cryptographic design
> has endured the test of time but these variations (or improvisations)
> endanger it.
>
> Finally, since Bellovin's attack was mentioned, I want to make sure that
> no one is thinking of not using the MAC authentication at the IP packet
> level, right?
>
> Absolutely.
>
> Hugo
>
> Regards,
> Valery Smyslov.
>
>  ------------------------------
>

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 11 Sep 2014 10:23:58 +0300

Hi Hugo,

We know what to expect from IKEv2 with mutual certificate or PSK 
authentication.

I *think* we also know what IKEv2 provides when both sides are NOT 
authenticated. To summarize my own understanding: the IKE exchange and 
any resulting Child SAs are confidential (only encrypted payloads of 
course) and integrity protected, provided there was no MITM attacker at 
the time of the initial IKE exchange. If there was one, all bets are off.

The document is unclear about the security properties of the proposed 
1-way auth, but from the discussion, many people believe it is similar 
to TLS. I agree that a serious analysis of this option is called for.

The document's introduction does give the impression that the main point 
of this document is one-way auth, but I think most of the people who 
support this document are more interested in fully anonymous key 
exchange. So I would like to focus the WG adoption discussion right now 
on the anonymous use case, and then, if the WG decides to adopt the 
document, go back to the question you raised.

Thanks,
	Yaron

On 09/11/2014 07:01 AM, Hugo Krawczyk wrote:
> On Tue, Sep 9, 2014 at 7:58 AM, Valery Smyslov <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     __
>     Hi Hugo,
>
>         The subject line (and the comment on Bellovin attack) caught my
>         eye. I don't follow the discussions in this list so I don't know
>         how much the need and dangers of unauthenticated methods were
>         discussed here. I want to point out that (and probably many did
>         before me) that un-authentication is a very tricky option
>         especially in a protocol that was created with mutual
>         authentication as a core requirement and assumption. I can see
>         potential benefits and uses but I can also see it abused and
>         misused (the internet draft doesn't do too good a job warning
>         about it but even if it did, people will misuse it).
>
>         But requirements aside, I cannot vow for the security of IKE's
>         key exchange in a one-way authentication mode. No one (that I
>         know, definitely not me) designed this protocol to support
>         one-way authentication. So the question of whether it is secure
>         in this setting has not been investigated. Moreover, I see that
>         the draft uses shared-key fields for theanonymous side of the
>         communication and, I imagine, the other can use signature-based
>         authentication. What security properties do you get from that
>         mix-and-match authentication methods?
>
>         unauthenticated (or one-way) IKE and will run some other
>         authentication on top of it (say, password based or whatever).
>         Well, protocols do not necessarily compose securely. TLS had
>         many failures like that (BEAST, re-negotiation, triple
>         handshake, ...) and IPsec saw examples of that in the
>         combinations of unauthenticated ESP and AH. IKE's cryptographic
>         design has endured the test of time but these variations (or
>         improvisations) endanger it.
>
>         Finally, since Bellovin's attack was mentioned, I want to make
>         sure that no one is thinking of not using the MAC authentication
>         at the IP packet level, right?
>
>     Absolutely.
>
>         Hugo
>
>     Regards,
>     Valery Smyslov.
>
>         On Mon, Sep 8, 2014 at 10:54 AM, <[email-masked]
>         <mailto:[email-masked]>> wrote:
>
>
>             On Sep 7, 2014, at 2:53 PM, Yaron Sheffer
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>             > Dear working group,
>             >
>             > This is a call foradopting draft-smyslov-ipsecme-ikev2-null-auth as a WG
>             document. Please respond to this mail with a Yes or No and a
>             short rationale, at latest by Friday Sep. 12.
>
>             Maybe.
>
>             The Security Considerations seems to be inadequate.
>             Whenever possible, real authentication should be used.  So
>             the Security Considerations should explicitly and strongly
>             emphasize that, and recommend that products that incorporate
>             Null authentication should strive to avoid its use whenever
>             A related question: does the use of Null authentication open
>             up the Bellovin attack?  It seems that it would.  If so, my
>             answer changes to “NO”.
>
>                  paul
>
>             [email-masked] <mailto:[email-masked]>
>         ------------------------------------------------------------------------
>
>         [email-masked] <mailto:[email-masked]>

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Sep 2014 14:06:10 +0300

> rationale, at latest by Friday Sep. 12.

I have not really had time to concentrate on this topic yet, but I
think this kind of extension would be useful, and I especially think
one way authentication would be useful in the IoT contexts. I am not
that convinced that no authentication at all is that useful, but I
might be wrong (there are complicated policy issues with that, which
might require more work).

I support taking this document as WG document (i.e. as first version,
that can then be worked on later). 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 11 Sep 2014 11:53:26 -0400

> one way authentication would be useful in the IoT contexts. 

I *do* think that no authentication will become useful for some things.

I wonder if we will see protocols where is the a cycle of null-auth IKEv2,
followed by some non-null-auth once the two parties decide that they might
want to do something more interesting.  (I liken this to two dogs sniffing
each other's butts... and then.. well. that might be safe-for-work)

I don't think IoT will be one of the situations.

Adopt the document.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Fri, 12 Sep 2014 08:43:27 -0400 (EDT)

On Thu, 11 Sep 2014, Yaron Sheffer wrote:

> The document's introduction does give the impression that the main point of 
> this document is one-way auth, but I think most of the people who support 
> this document are more interested in fully anonymous key exchange.

Both are definately within the scope of what we are thinking about,
although we would really prefer one-way sees wide adoption and
deployment.

Another use case that has come up is cloud instance deployments, where
images are part of a group, and individual hosts booted from the same
image don't really have a unique identity. These cases don't fall
clearly within mutual or one-sided auth.

Paul