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

[Tero Kivinen <[e-mail]>]

Paul Wouters writes:
> On Tue, 4 Mar 2014, Tero Kivinen wrote:
> 
> >> I have actually thought about a mode where we scramble the order or
> >> 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:
> 
> 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...

> > But should you reject unauthenticated connections just because they
> > 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.

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.
-- 
[e-mail]