Subject: [Lwip] Call for adoption of draft-kivinen-ipsecme-ikev2-minimal-01

From: "Cao Zhen \(CZ\)" <[email-masked]>
Date: Wed, 3 Oct 2012 22:34:01 +0800

Dear All, 

The draft has been updated and now there is a new version of it:
http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-01.txt. 

This email starts a call for adoption of the draft. Please feedback in one
week from now. 

Thanks and regards,
Zhen & Robert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cao Zhen (CZ)
> Sent: Monday, September 17, 2012 9:43 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Lwip] Call for adoption of
draft-kivinen-ipsecme-ikev2-minimal-00
> 
> Dear All,
> 
> During IETF84th meeting at Vancouver, several people spoke for the
adoption of
> draft-kivinen-ipsecme-ikev2-minimal-00
> (http://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00). This
draft is related
> to the LWIG working group and covered by the charter, and was presented as
once in the
> working group.
> 
> This email is to confirm the consensus of adoption of this document.
Please feedback in one
> week from now, i.e., before Sept 24, 2012, 5PM PDT,
> 
> Thanks and regards,
> Zhen & Robert
> 
> _______________________________________________
> Lwip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lwip

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Oct 2012 16:57:42 +0200

On Oct 3, 2012, at 16:34, "Cao Zhen \(CZ\)" <[email-masked]> wrote:

> This email starts a call for adoption of the draft.

I am interested in this work and support going forward with this as a working group document.

Grüße, Carsten

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 3 Oct 2012 10:38:25 -0500

Hi Tero, Zhen,

This document defines a stripped-down IPSec IKEv2, could such a
document be informational?

Why has RSA been kept?

Regards,

Behcet

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 3 Oct 2012 18:20:51 +0200

> document be informational?

I understand this as a minimal profile of IPsec, not as a "stripped-down" (which I would read as "non-conforming") protocol.
The intention is to show implementers how IPsec can be made to work on constrained platforms, not to define a new protocol.
This is a typical LWIG style document.
(If there is a bug in how this was done and the result indeed is not interoperable, we certainly can fix this in the WG process.
If we need to spin off some standards-track work to make an interoperable constrained implementation worthwhile, we can also spin it off.)

> Why has RSA been kept?

Good question, but maybe again something we can discuss in the WG process.

Grüße, Carsten

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 Oct 2012 10:33:56 -0500

On Thu, Oct 4, 2012 at 7:57 AM, Tero Kivinen <[email-masked]> wrote:
> Behcet Sarikaya writes:
> This is just summary of the minimal features of the IKEv2. Only thing
> we do change from the actual IKEv2 specification is that we do remove
> the requirement for support for certificates.

So there is some normative change.

> I think this document
> should be informational, as the RFC5996 is going to be the authorative
> description anyways and we are compliant with the RFC5996 (when using
> one of the mandatory required authentication method in there). This is
> more like a profile document.

I am with you on this.

>
>> Why has RSA been kept?
>
> Raw RSA keys is listed in the Appendix B. Useful Optional Features
> because I do think that is going to be the most commonly used
> authentication method. When my raw public keys draft is going forward
> in the ipsecme wg, I think that will also be included in the appendix.
>

Support.

> Pre-shared keys has the problem that they do not scale, and in most of
> the internet of things like setups you cannot really use pre-shared
> keys. Using raw public keys solves the scalability problem, but does
> not involve the certificate validation issues.

What about ECC instead of RSA?

Regards,

Behcet

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 4 Oct 2012 18:42:17 +0300

>> not involve the certificate validation issues.

I hear this all the time and still it is wrong. 

The "magic" to scale a shared secrets-based authentication system is to move from a two party to a three party system. 

An example of a successfully deployed shared secret based authentication infrastructure can be found with the cellular communication infrastructure. 

In context of this document this means that you have to use IKEv2 with EAP and combine it with the AAA infrastructure. 

Isn't it easy?

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 4 Oct 2012 15:57:10 +0300

the requirement for support for certificates. I think this document

-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Oct 2012 12:48:24 +0300

> What about ECC instead of RSA?

That has to wait for my draft-kivinen-ipsecme-oob-pubkey to go
forward. When I get that one ready I can update the minimal document
to refer to that in addition to raw rsa public keys. Current IKEv2
only supports raw RSA keys, so raw ECC keys do require more
specification. 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 5 Oct 2012 13:02:00 +0300

Hannes Tschofenig writes:
> The "magic" to scale a shared secrets-based authentication system is
> to move from a two party to a three party system.

Which is what is NOT done in the IKEv2, so that does not help. I was
not talking about the generic Pre-shared keys, I was talking about the
pre-shared keys as defined by IKEv2, which does not involve 3rd party.

> An example of a successfully deployed shared secret based
> authentication infrastructure can be found with the cellular
> communication infrastructure.

Which in IKEv2 context would not mean pre-shared keys authentication.
If you want to use that kind of shared secrets in cellular
communiations in IKEv2, you need to use EAP authentication in IKEv2.

> In context of this document this means that you have to use IKEv2
> with EAP and combine it with the AAA infrastructure.  
> Isn't it easy?

I would not classify EAP as easy, but that is besides the point, EAP
authentication is different authentication method than pre-shared keys
authentication in IKEv2.

In IKEv2 there are currently 5 (somewhat) different authentication
methods. They are in the order of easiest to implement to most
complicated to implement as follows:

  1) Pre-shared keys (i.e. shared key)
  2) Raw RSA keys
  3) Certificate based authentication methods
  4) EAP
  5) Secure password protocols

The EAP could also be before certificates, but that depends completely
what EAP method is used. For example some EAP methods do require
certificate support, which makes implementing them more complicated
than authentication based on certificates in IKEv2. Some EAP methods
are much simplier than certificates, going to be about the same as Raw
RSA keys in IKEv2.

Secure password methods could actually be also be betwen raw RSA keys
and Certificates, but that again depends which secure password method
you implement, and there is not yet enough implementation experience
for them to really specify how complex they will be to implement. 
-- 
[email-masked]

---

From: "Cao Zhen \(CZ\)" <[email-masked]>
Date: Fri, 12 Oct 2012 17:42:36 +0800

> So there is some normative change.
Put it another way, that it is recommended in the document that lightweight
implementation of Ikev2 SHOULD not use the certification based
authentication. That's informational. 

So I believe the document fits into information overall.