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

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 3 Mar 2014 14:50:20 +0400

Hi all,

I've posted new version of the NULL Auth Method draft.
It addresses comments received from Yaron Sheffer and Paul Wouters.

Regards,
Valery Smyslov.

----- Original Message ----- 
From: <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; "Valery Smyslov" <[email-masked]>
Sent: Monday, March 03, 2014 2:41 PM
Subject: New Version Notification for 
draft-smyslov-ipsecme-ikev2-null-auth-01.txt

>
> A new version of I-D, draft-smyslov-ipsecme-ikev2-null-auth-01.txt
> has been successfully submitted by Valery Smyslov and posted to the
> IETF repository.
>
> Name: draft-smyslov-ipsecme-ikev2-null-auth
> Revision: 01
> Title: The NULL Authentication Method in IKEv2 Protocol
> Document date: 2014-03-03
> Group: Individual Submission
> Pages: 9
> URL: 
> http://www.ietf.org/internet-drafts/draft-smyslov-ipsecme-ikev2-null-auth-01.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-01
> Diff: 
> http://www.ietf.org/rfcdiff?url2=draft-smyslov-ipsecme-ikev2-null-auth-01
>
> Abstract:
>   This document defines the NULL Authentication Method for the 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: Tero Kivinen <[email-masked]>
Date: Mon, 3 Mar 2014 17:04:04 +0200

> It addresses comments received from Yaron Sheffer and Paul Wouters.

Ah, I just managed to read the -00 version... Oh well, reading diffs
next...

Anyways I think the document is in quite good shape, I think the
section 2.2 needs to be more specific about how to send the empty ID
payload. I think the idea of sending ID_IPV4_ADDR with 0 bytes of
data is very bad idea. The current text says you can omit data, and
that the type can be anything. The problem is that in most cases the
implementation has code that will parse the ID payload using standard
rules and now if the ID payload has type of ID_IPV4_ADDR and 0 bytes
of data, the parsing will fail.

It would be better to say that if you are sending empty ID payload,
you msut use ID_KEY_ID type which already allows any data, including
empty.

Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
ignored", and I think that is again bad idea. I think logging and
auditing the ID for problem solving purposes is good idea even if it
does not have any meaning for the authentication. I.e. at least then I
can contact helpdesk and say that my NULL authentication connection to
server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
from your logs... 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Mar 2014 17:57:33 -0500 (EST)

> you msut use ID_KEY_ID type which already allows any data, including

That could work, if we really don't want to allow this document to
change the ID payload from mandatory to optional (which I would prefer)

> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it

I disagree strongly. The point here is that the client is anonymous. We
should not add things that can be traced to a user. Someone will badly
abuse this "feature" like you are suggesting for "diagnostics" and
inadvertly compromise the client's anonimity.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 04 Mar 2014 01:04:39 +0200

Hi Paul,

Quoting from the abstract: "This method may be used to preserve 
anonymity or in situations, where no trust relationship exists between 
the parties." You seem to assume that all clients want to be anonymous. 
IMHO "unauthenticated" does not necessarily imply "anonymous". When I 
talk to someone on the plane and they tell me their name, they are not 
authenticated and they may well be lying. But in general, they are not 
anonymous either.

Thanks,
	Yaron

On 03/04/2014 12:57 AM, Paul Wouters wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 10:36:44 +0400

Hi Tero, 

> of data, the parsing will fail.

I agree this may chocke some implementations. The idea was that
if implementation notice that Auth Method is NULL, it must
not parse ID Payload at all. But I understand that depending
on the order in which payloads are processed by particular
implementation, this may be inconvinient for implementers.

> you msut use ID_KEY_ID type which already allows any data, including

Actually, even with ID_KEY_ID it is a bit of hack.
I'd rather define the entity "Empty ID Payload" as
ID Payload with ID Type of zero and zero-length content
(so that even ID Type be undefined) and require
implementations to use it if they want to keep anonimity.

> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it

Actually, I tried to address Paul Wouters' concern that without
strong "MUST" here implementations may use ID even if it is
not authenticated. But, from my understanding of the wording,
"MUST be ignored by IKE" doesn't mean that implementation
is not allowed to log the ID, that is always useful ror auditing
and troubleshooting. I probably should make this more clear.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Mar 2014 04:54:56 -0500 (EST)

> implementation, this may be inconvinient for implementers.

I have actually thought about a mode where we scramble the order or
payloads just to see which implementations would die :P

No implementation should depend on the order of payloads for anything.

> and require implementations to use it if they want to keep anonimity.

I feel someone wants to give an implementation the freedom to make an
unwise decision :P I really want to insist that anonymous means
anonymous - no methods for sending along an ID.

> and troubleshooting. I probably should make this more clear.

And I feel that I need to reject anonymous connections that have an ID
to protect the anonymity of the user.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Mar 2014 05:06:17 -0500 (EST)

On Tue, 4 Mar 2014, Yaron Sheffer wrote:

> Quoting from the abstract: "This method may be used to preserve anonymity or 
> in situations, where no trust relationship exists between the parties." You 
> seem to assume that all clients want to be anonymous. IMHO "unauthenticated" 
> does not necessarily imply "anonymous". When I talk to someone on the plane 
> and they tell me their name, they are not authenticated and they may well be 
> lying. But in general, they are not anonymous either.

I'm really afraid of accidental leakage by implementors or administrators.
In this era, I think we should really make an effort to protect against that.

I really think it is a fundemantal problem if we allow an IPsec entity
to lie about its identity. Right now, an identity is always proven by an
authentication, and I think if there is no authentication, there should
be no identity.

If you want debugging, you can send some kind of implementation specific
custom payload - don't piggyback on auth-none.

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Mar 2014 12:06:17 +0200

> inadvertly compromise the client's anonimity.

I guess you have never done any helpdesk support trying to help people
who complain that something that does not work? Having something there
that would help support to find your items in the logs is always
useful.

The client does not have to put anything there if they do not like it,
and the default setting should be that there is nothing, but allowing
such things will make things easier for those poor souls doing
helpdesk.

I myself need to sometimes help people complaining about email
problems in the iki.fi (email forwarder), and it is really hard to try
to find specific email from the logs, especially as there is problems
with timezones, and delays and so on, so exact time when the email was
sent does not really help. Sometimes they are able to find message-id
of the problematic email or the queue id in our end, and then it is so
easy to find the entries in the logs and pinpoint the problem.

I think the most important point of this feature is that the client is
UNAUTHENTICATED, not that it is ANONYMOUS. If you want to have
anonymity then you need to use TOR or similar, this is not enough.
Your IP address etc will give your identity out in most cases anyways.
Even if your IP address is not same than normally, your browser using
the same IP address at same time will give out browser fingerprint
that will most likely uniquely identify you when used with combination
that you are also using null authentication in IPsec and connecting to
the host X.

We should understand what this feature offers, and what it can be used
for. Anonymity is not offered by this feature.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Mar 2014 12:40:48 +0200

> payloads just to see which implementations would die :P

That only works for RFC5996 version, RFC4306 version are allowed to
reject packets which have payloads in "wrong" order:

>From RFC4306:
----------------------------------------------------------------------
2.5.  Version Numbers and Forward Compatibility
...
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations MUST send the payloads defined in this specification
   in the order shown in the figures in section 2 and implementations
   SHOULD reject as invalid a message with those payloads in any other
   order.
----------------------------------------------------------------------

RFC5996:
----------------------------------------------------------------------
2.5.  Version Numbers and Forward Compatibility
...
   Although new payload types may be added in the future and may appear
   interleaved with the fields defined in this specification,
   implementations SHOULD send the payloads defined in this
   specification in the order shown in the figures in Sections 1 and 2;
   implementations MUST NOT reject as invalid a message with those
   payloads in any other order.
----------------------------------------------------------------------

> No implementation should depend on the order of payloads for anything.

True, but for example my implementation do parse all payloads first,
and then start processing them by first checking certain payload, then
checking the payloads in suitable order (i.e check that all require
payloads are there, then check whether payloads have suitable values
etc).

This is done just this way so it does not matter in which order the
payloads in the incoming packets are. I will find the ID payload
regardless where it is, when I need it.

And for example my ID parsing code already checks that there must be 4
bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return
error immediately there if that is not true. This is way before I even
start checking what is the authentication type etc.

Of course I could move that checking to later, i.e when actually using
the ID payload, but that would have its own issues. 

> anonymous - no methods for sending along an ID.

This is not anonymous method, this is unauthenticated method. We
cannot really provide anonymity with this method. 

> to protect the anonymity of the user.

But should you reject unauthenticated connections just because they
have ID which you are not authenticating anyways. Note, that we are
talking about unauthenticated connections, not really anonymous
connections.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 15:02:34 +0400

Hi Paul,

> No implementation should depend on the order of payloads for anything.

The order payloads are processed is not necessary the order payloads 
appear in the message. Nobody (at least not me) tells that payloads
must be processed in the order they appear in the message,
but you still process payloads in some order. For example,
you first try fo collect all VID payloads too understand what
non-standard things you may expect from the message,
before you start processing other payloads, don't you?

So, I just meant, that if ID Payload is processed before
AUTH Payload (a very natural behaviour, isn't it?), that implementation
may not be prepared to get "scrambled" ID and it may choke it.

But actually, it doesn't matter, because if implementation supports
NULL Auth, it must be prepared to get any ID,
and if it doesn't, then exchange will fail anyway.

> anonymous - no methods for sending along an ID.

I just want to allow user to keep his anonimity to the extent
he wishes himself. From my understanding the peer, who uses
NULL Auth, must have freedom to decide whether to
put something in ID (for any reason), or leave it empty. And note, 
that the draft encourages users (by SHOULD) to do the latter.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Mar 2014 06:08:43 -0500 (EST)

> reject packets which have payloads in "wrong" order:

I did not realise IKEv1 did not allow that. How quaint....

> start checking what is the authentication type etc.

That's exactly how we do it. Parse each payload and store it, throw an
immediate error if any of these are wrong. Then lookup the SPIs, find
the right state and check if all required payloads are there and all
other payloads are valid optional payloads, and only then proceed with
processing.

> cannot really provide anonymity with this method.

Okay, I guess we disagree.

> have ID which you are not authenticating anyways.

Yes I think so. You are changing the meaning of ID from implicitely
"verified ID" to potentially "unverified ID". I think that is wrong.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 15:23:46 +0400

> "verified ID" to potentially "unverified ID". I think that is wrong.

But what prevent you from throwing away ID content in this case,
as you know that it is unauthenticated (you may even not to log it), 
and allow user to connect? User has already exposed the
content of ID, the damage (if any) has already occured,
so what you will you protect by rejecting the connection?

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Mar 2014 13:27:46 +0200

> I did not realise IKEv1 did not allow that. How quaint....

IKEv1 did allow sending payloads in any order, if I remember right.
RFC4306 is original IKEv2, not IKEv1...

> "verified ID" to potentially "unverified ID". I think that is wrong.

The draft name is null-auth, and for me that means there is
no authentication. The abstract says it "may be used to preserve
anonymity" (one use case, it does not say it do provide anonymity),
and another use case is "in situations, where there no
trustrelationship exists between the parties.". This second use case
does not have anything to do with anonymity just unauthenticated
connections.

And the whole idea is to "omit peer authentication".

Hmm... funny typo in section 1:

   o  User wants to get anonymous access to some resource.  In this
      situation he/she should be able to authenticate server, but to
      leave out his/her own authentication to prevent anonymity.  In
      this case one-way authentication is desirable.

user will leave out authentication to PREVENT anonymity... I assume
preserve is the one word that was meant...

The second use case does not require any anonymity:

   o  Two peers without any trust relationship want to get some level of
      security in their communications.  Without trust relationship they
      cannot prevent active Man-in-the-Middle attacks, but it is still
      possible to prevent passive eavesdropping with opportunistic
      encryption.  In this case they have to perform unauthenticated key
      exchange.

Actually even the first use case, having non-authenticated identity
would still be useful in some cases. For example if I will protect my
home server with null-authenticated IPsec, people most likely will
still want to verify my servers authentication, and they might want to
provide meaningful unauthenticated ID, even when it is not needed. The
meaningful ID might be something that is not meaningful in global
context, but it might be meaningful for me, i.e. just nickname or
similar.

If they want to do something where I would require them to do
authentication then I would most likely still use my (self signed)
certificate based authentication for server (with certificate pinning
and TLSA records in DNSSEC signed zone), and they would use similar
locally meaningful ID and raw public key to authenticate themselves to
my server.

I.e. I will see the upgrade path from null-auth -> raw public keys
very logical in small private use setups.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 15:46:59 +0400

Hi Tero,

> IKEv1 did allow sending payloads in any order, if I remember right.

Right, but with some restrictions (e.g. HASH Payload in QM must go before 
other Payloads).

> preserve is the one word that was meant...

Yes, of course. Thanks for catching.

And in -01 draft I've added one more use case:

   o  User wants to get some simple action from remote device.  Consider
      garage door opener: it must authenticate user to open the door,
      but it is not necessary for the user to authenticate the door
      opener.  In this case one-way authentication is sufficient.

In this example there is no harm if garage door opener
fills in its ID Payload - it need not be anonymous.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Mar 2014 08:04:05 -0500 (EST)

> fills in its ID Payload - it need not be anonymous.

There is harm. An observer could figure out if it is me that's opening
the door, or my wife or my kids.

If the server (door) does not need it, don't send it.

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Mar 2014 08:04:59 -0500 (EST)

On Tue, 4 Mar 2014, Valery Smyslov wrote:

> as you know that it is unauthenticated (you may even not to log it), and 
> allow user to connect? User has already exposed the

Making the problem visible to it will not happen in the future.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 17:37:02 +0400

> If the server (door) does not need it, don't send it.

Sorry, you missed the point. In this example user must sent
his identity and must authenticate to the door opener 
(otherwise it will open the door to any stranger).
But door opener (responder) need not authenticate
itself to the user and may use NULL Auth. It is a reverse
situation to the first example in the draft, when
initiator uses NULL Auth.

What is the harm if door opener sends its unauthenticated identity to you?
And what will you do in this case? Reject connection?
But remember, that it was you who initiated this connection,
and moreover, you are already authenticated and 
the action you requested (opening the door) has probably
already occured, so rejecting connection in this case
looks like stupid action.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 17:46:45 +0400

> Making the problem visible to it will not happen in the future.

If you consider it as a problem, than there ara other
means to make it visible, e.g. audit that something is
probably wrong.

>> to protect the anonymity of the user.

And I just wonder how you are going to protect
user's anonimity if user himself has already exposed
his identity.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 04 Mar 2014 23:15:14 +0200

> very logical in small private use setups.

And once we start using raw public keys (or self signed certs), we can 
use out-of-band means to upgrade the identity from "claimed but 
unauthenticated" to "authenticated". This is what we're proposing in 
AutoVPN.

Thanks,
	Yaron