Subject: Re: [IPsec] draft-smyslov-ipsecme-ikev2-null-auth-01

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Jun 2014 10:00:39 -0400 (EDT)

On Wed, 4 Jun 2014, Valery Smyslov wrote:

> I've already asked co-chairs for a slot to present null-auth
> in a private e-mail.

Great :)

We should probably add a comment about rekeying. If the responder
becomes the initiator, it might run into issues. Possibly an entity
that did not authenticate the peer should not initiate a rekey.

There is also the case where A uses null auth to an authenticated B,
and B then gets independantly triggered to setup a null auth connection
to A. We haven't fully figured out how to deal with this other than
"if we see our own IPSECKEY record, don't initiate null auth", but I'm
not sure if that covers everyone's use case.

Paul
ps. i also still prefer AUTH_NONE over "NULL AUTH", as to me NULL looks
more like an error while "none" conveys intent.

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 4 Jun 2014 18:23:49 +0400

> that did not authenticate the peer should not initiate a rekey.

Rekeying or reauthentication? I don't think rekeying might
cause a problem as it doesn't include any authentication.
Or do you refer to some different issue?

> not sure if that covers everyone's use case.

I think it is more relevant to a specific use case than
to the method itself. Some text could be added that 
if entity is authenticated using some mechanism other than 
NULL, then NULL SHOULD not be used for the same entity.

> more like an error while "none" conveys intent.

I remember it. However I'm still waiting for other's opinions on this.
Naming is not a problem.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Jun 2014 12:20:30 -0400

Valery Smyslov <[email-masked]> wrote:
    >> Paul ps. i also still prefer AUTH_NONE over "NULL AUTH", as to me NULL
    >> looks more like an error while "none" conveys intent.

    > I remember it. However I'm still waiting for other's opinions on this.

I prefer AUTH_NONE over "NULL AUTH".
Still, that doesn't convey enough intent;  AUTH_DIDNTWANTTO, or something
like that might say it better, but that's a mouthful, so I can live with
AUTH_NONE if we can't do better.

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

---

From: Paul Wouters <[email-masked]>
Date: Wed, 4 Jun 2014 12:47:27 -0400 (EDT)

> AUTH_NONE if we can't do better.

AUTH_ANON ? Although I think AUTH_NONE is more in line with how we name
things.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Wed, 04 Jun 2014 16:03:28 -0400

Paul Wouters <[email-masked]> wrote:
    >> Valery Smyslov <[email-masked]> wrote: >> Paul ps. i also still
    >> prefer AUTH_NONE over "NULL AUTH", as to me NULL >> looks more like an
    >> error while "none" conveys intent.
    >>
    >> > I remember it. However I'm still waiting for other's opinions on
    >> this.  > Naming is not a problem.
    >>
    >> I prefer AUTH_NONE over "NULL AUTH".  Still, that doesn't convey
    >> enough intent; AUTH_DIDNTWANTTO, or something like that might say it
    >> better, but that's a mouthful, so I can live with AUTH_NONE if we
    >> can't do better.

    > AUTH_ANON ? Although I think AUTH_NONE is more in line with how we name

I don't agree that it is anonymous.  It says that the identity was not
authenticated, it didn't say that no identity was provided.

Clearly: the identity can't be trusted and can't be used in anyway.
So, given that, how does one look up acceptable TSx in the PAD?

I think that the opportunistic encryption use case given can not make any
sense without reference to the PAD.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 5 Jun 2014 00:55:01 +0300

> authenticated, it didn't say that no identity was provided.

Section 2.2 says that “As peer identity is meaningless in this case, Identification Data SHOULD be omited from ID Payload”([1]), and even if sent, it MUST be ignored by IKE. So it’s really not provided.

> So, given that, how does one look up acceptable TSx in the PAD?

That’s a good question. What prevents a random attacker from sending a TSr covering IP address 8.8.8.8, and getting a whole bunch of DNS queries. That’s easier than bugging the ISP or break the wifi password.

> sense without reference to the PAD.

I think that’s the hard part of any opportunistic IPsec. It’s not always better than nothing, because you might be making it easier for Eve. 

Yoav

[1] sic - “omitted” should have two t's

---

From: Paul <[email-masked]>
Date: Wed, 4 Jun 2014 23:05:34 -0400

The connections are host to host only, all ports, no gateways. You can call it no PAD, or call this policy the PAD. I don't see a problem with mapping auth none to this policy?

Sent from my iPhone

> On Jun 4, 2014, at 16:03, Michael Richardson <[email-masked]> wrote:
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul <[email-masked]>
Date: Wed, 4 Jun 2014 23:12:15 -0400

Sent from my iPhone

> On Jun 4, 2014, at 17:55, Yoav Nir <[email-masked]> wrote:
> 
> 
> 

There wasn't consensus on that but I'm clearly if that opinion as well.

> That’s a good question. What prevents a random attacker from sending a TSr covering IP address 8.8.8.8, and getting a whole bunch of DNS queries. That’s easier than bugging the ISP or break the wif…

Our implementation has a global option that allows only rfc1918 and related (eg 25/8) for NATT. We might be able to not need it with the Linux VTI hooks and NAT, but that's still a work in progress. For the protocol work I'd say that is all local implementation.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 5 Jun 2014 17:36:42 +0400

Hi Yoav,

> Section 2.2 says that “As peer identity is meaningless in this case, 
> Identification Data SHOULD
> be omited from ID Payload”([1]), and even if sent, it MUST be ignored by 
> IKE. So it’s really not provided.

True.

> That’s a good question. What prevents a random attacker from sending a TSr 
> covering IP address 8.8.8.8,
> and getting a whole bunch of DNS queries. That’s easier than bugging the 
> ISP or break the wifi password.

I think it depends on use case. If unauthenticated peer performs remote 
access
to RAS then the server will most likely assign him/her an IP address from 
internal
space and the situation you have describe won't happen. And if the peer
didn't request the address, the server should probably reject the 
connection.

> [1] sic - “omitted” should have two t's

Thanks, fixed.

Regards,
Valery.