Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt

From: [email-masked]
Date: Fri, 01 May 2015 15:59:38 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Locator/ID Separation Protocol Working Group of the IETF.

        Title           : LISP Data-Plane Confidentiality
        Authors         : Dino Farinacci
                          Brian Weis
	Filename        : draft-ietf-lisp-crypto-01.txt
	Pages           : 16
	Date            : 2015-05-01

Abstract:
   This document describes a mechanism for encrypting LISP encapsulated
   traffic.  The design describes how key exchange is achieved using
   existing LISP control-plane mechanisms as well as how to secure the
   LISP data-plane from third-party surveillance attacks.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lisp-crypto/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-lisp-crypto-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lisp-crypto-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 1 May 2015 16:04:03 -0700

Folks, this draft contains the following changes:

B.1.  Changes to draft-ietf-lisp-crypto-01.txt

   o  Posted May 2015.

   o  Create cipher suites and encode them in the Security LCAF.

   o  Add IV to beginning of packet header and ICV to end of packet.

   o  AEAD procedures are now part of encryption process.

And are based on detail security expert comments from Watson Ladd and Ilari Liusvaara. Not to mention a new co-author Brian Weis, who has been working on security standards in the IETF and building security products for well over a decade.

I have done a prototype to test out IV and ICVs and tend to do a full xTR implementation starting next week. I have also experimented with different Elliptic-Curve Diffie-Hellman groups and will do CPU utilization comparisons.

Thanks,
Dino

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: [lisp] I-D Action: draft-ietf-lisp-crypto-01.txt
> Date: May 1, 2015 at 3:59:38 PM PDT
> To: <[email-masked]>
> Cc: [email-masked]
> 
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 2 May 2015 10:22:54 +0300

>    o  AEAD procedures are now part of encryption process.

At least I can follow how the algorithms work. Remaining issues/notes:
- It composes AEAD mode instaed of using ready-made one. The composed
  mode is if nothing else slow (SHA-1 is already slower than some
  ready-made AEAD modes).
- Key derivation looks to be missing hashing in important parameters
  (like group and exchange keys) into secrets.
- Some NIST-spec KDF? I think there are RFCs that describe KDFs.
- 1024-bit DH is regarded as quite weak nowadays.
- Two new ECDH functions from CFRG were recently annouced[1].
  Should be faster than DH1024/DH2048 with way smaller keys.

[1]

The lower security one (Curve25519, as is):

v^2 = u^3 + 486662u^2 + u (mod 2^255-19)

Secret key size: 255 bits.
Secret key masking: Bits 0, 1, 2 off, bit 254 on.
Point encoding: u as 32-octet little-endian base-256 integer.
Base point: u=9.

The higher security one:

v^2 = u^3 + 156326u^2 + u (mod 2^448-2^224-1)

Secret key size: 448 bits.
Secret key masking: Bits 0, 1 off, bit 447 on.
Point encoding: u as 56-octet little-endian base-256 integer.
Base point: u=5.

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 5 May 2015 06:46:57 +0000

Hi Ilari,

Thanks for your comments.

>  mode is if nothing else slow (SHA-1 is already slower than some

These are the algorithms we’re comfortable with for now. We could
have specified the combined AEAD mode cipher modes, but they add
complexity in the form of maintaining a counter for the nonce.

>  (like group and exchange keys) into secrets.

Not sure which parameters you mean? The DH shared secret is the
key for the KDF, I’m not sure why we’d provide any other keys as input 
to the KDF.

> - Some NIST-spec KDF? I think there are RFCs that describe KDFs.

Yes, there’s RFC 5869 but the NIST KDFs are also widely used.

>  Should be faster than DH1024/DH2048 with way smaller keys.

We do need less computationally demanding ciphers for deices that do
crypto in ARM based platforms, which explains the 1024-bit DH (and yes,
we realize it is weak). As stated in the Future Work section we will
be looking at these ECDH functions and should have some results
before the Prague meeting. If we can replace the 1024-bit DH we will.

Thanks,
Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]