Re: [lisp] Let's review crypto in lisp-crypto

[Dino Farinacci <[e-mail]>]

> On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote:
>> 
>>> - Ciphersuite 1 uses 1024-bit Diffie-Hellman, which is too weak
>>> (after you have cracked one key (and it doesn't take that much,
>>> especially if you can throw ASICs at the problem), you can crack
>>> each subsequent one in a few CPU minutes. With 2048-bit DH, at
>>> least the first key tends to be too hard, and with ECDH, tricks
>>> like this don't work).
>> 
>> Yes, both Brian and I replied that we were using this more for
>> experimentation on low-powered or CPU challenged devices. We will
>> not recommend its use. It’s just there for implementations to start
>> with something. But havind said that, I would like to recommend
>> the smaller keys that come along with chacha20/poly1305 so maybe
>> the subject is moot. 
> 
> I think that even having low-security options is a problem.

How about we change the Cipher Suite definitions TO this (and address multiple of your comments):

   Cipher Suite 0:
     Reserved

   Cipher Suite 1:
     Diffie-Hellman Group: 2048-bit MODP [RFC3526]
     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
     Integrity:            HMAC-SHA1-96 [RFC2404]

   Cipher Suite 2:
     Diffie-Hellman Group: 3072-bit MODP [RFC3526]
     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
     Integrity:            HMAC-SHA1-96 [RFC2404]

   Cipher Suite 3:
     Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
     Encryption:           AES with 128-bit keys in GCM mode [AES-GCM]
     Integrity:            HMAC-SHA1-96 [RFC2404]

   Cipher Suite 4:
     Diffie-Hellman Group: 256-bit Elliptic-Curve 25519 [CURVE25519]
     Encryption:           Chacha20-Poly1305 [CHACHA-POLY]
     Integrity:            Covered under Encryption Algorithm

Please ack before we take action. And would like Brian (or anyone else in the WG) to weigh in on this as well.

> 
>>> - The NIST SP800-108 KDF handles the counter and length internally,
>>> those are not part of the context input.
>> 
>> You should point to text so we know where in the spec you are
>> commenting against. It is hard to get context from your comments.
> 
> Section 5 in -02. The listing for "Context" (meaning the fields
> in context).

I think we are saying we are building a context similar to the NIST standard but not using it. Brian needs to comment here.

> - If you need identifier for association (e.g. for displaying to
>>> admin for authentication purposes), you must hash in the (EC)DH
>>> public keys used into the identifier. Otherwise MITM attacker can
>>> defeat the authentication.
>> 
>> We use the source RLOC and the Map-Request nonce to identify the association.
> 
> That's does not create identifier suitable for comparing between
> endpoints for authentication.

LISP-SEC is used as well. See the Security Considerations section. I think we have this covered.

>> - If the same system can be ITR and ETR at once, how one ensures that
>>> if two such systems establish associations to each other, the keys
>>> won't wind up being the same? This could be solved by requiring
>> 
>> Because the key-pair is unidirectional. If router A is an ITR and sends
>> a Map-Request to router B, that key-pair is for data traffic encapsulated
>> from A to B. If B is an ITR encapsulating to A an ETR, a differne
>> key-pair is used. A new random number generator, nonce, and key
>> exchange is performed for each direction.
> 
> You mean that A (and B) is supposed to use different DH keys for
> their roles as ITR and ETR (if reusing keys, like at least some
> implementations are going to do)?

Yes, that is the way we described it by talking about encryption unidirectionally from ITR to ETR.

> I didn't see that explicitly required anywhere (this is kind of
> thing one wants to document).

It is implied and is rather clear I think. Wondering why you didn’t see that. Maybe your unfamiliarity with LISP?

> The problem if routers share keys between roles is that if two
> such routers connect to each other and pick the same nonces (nonce
> looks to be only 24 bits!) the keys will collide, with bad
> results.

They DO NOT do this. The DH keys and nonces are WITHIN the functionality of ITR versus ETR.

> 
>>> - AEAD_CHACHA20_POLY1305 IVs are 12 octets, right? That's too short
>>> to randomly generate. Instead, the encryptor should just use its
>> 
>> Yes, you are right. I padded to 16-bytes in my implementation. Do
>> you see harm in that. That way the packet length/format doesn’t have
>> to change for different cipher suites.
> 
> Well, no harm to have padding bits (if those are authenticated!). It
> is just that such padding needs to be specified.

We will make that change to the spec.

> (Assuming AD for AEAD algorithms is ICV\Encrypt, those are
> authenticated)
> 
> If you have some AEAD algo with N_MIN > 16 (I don't think any are
> currently defined) you could even zero-pad the IV…

Right now we don’t. But the spec says the IV size is based on the cipher suite negotiated. So we really don’t have to pad for chacha, we can just have an IV of 12 bytes. So written, it is correct. It is just my implementation that is padding. I can change the implementation (much easier than changing specs LOL).

>>> - Are the associations unidirectional (data is only ever sent one
>>> way) or how is uniqueness of IVs between directions handled?
>> 
>> Yes, unidirectional. IVs are per packet, any packet, in any direction.
> 
> Okay. That reduces IV uniqueness to ensuring each side generates
> unique IVs and that the keying material is direction-dependent.

Right.

> - IV is incremented for every packet? If using CBC mode, predictable
>>> IVs are bad (AEAD algorithms do deal with predictable IVs, but not
>>> repeating IVs).
> 
> I mean, the document seems to say both IVs are randomly generated and
> incremented for every packet (which seem to be mutually
> contradictionary).

I see. We can do one versus the other. That is, use random IVs. Is that okay?

>> - AEAD_CHACHA20_POLY1305 decryption both checks the ICV and if the
>>> check passes, decrypts the data. So performing step 2 also performs
>>> step 5.
>> 
>> Hmm. So are you saying that if the cipher suite negotiated is chacha20,
>> we should not add a ICV? That would be great, beacuse we can make cipher
>> suite 4 go even faster.
> 
> The encryption with AEAD algorithm presumably goes as follows:
> 
> 1) The encapsulator generates IV by some method that takes very long
> time to repeat (counters, LFSRs, etc...) and appends it to the LISP
> header.
> 
> 2) Invoke the AEAD encryption with:
> - Key set to encryption-key
> - Nonce set to the IV (truncated to N_MAX octets if N_MAX<16, padded
>  with zeroes in the end to N_MIN octets if N_MIN>16).
> - AD set to LISP header plus added IV field (the parts of packet marked
>  as ICV but not encrypt).
> - Plaintext set to the packet payload.

Yes, that is what we do.

> (Any possible tag output is appended to the ciphertext)
> 
> 3) Prepend the LISP header, together with the IV field into ciphertext.
> 
> 4) Lastly, prepend the UDP and IP headers into the encrypted packet
> and send to destination RLOC.

Yep, exactly what I think we stated. Thanks for clarification.

> And decryption:
> 
> 1) Strip the outer IP and UDP headers.
> 
> 2) Strip tag encryption concatenated  from packet payload (if any).
> 
> 3) Invoke the AEAD decryption with:
> - Key set to encryption-key (from local key-cache)
> - Nonce set to the IV field contents (truncated to N_MAX octets if
>  N_MAX<16, padded with zeroes in the end to N_MIN octets if N_MIN>16).
> - AD set to LISP header plus added IV field (the parts of packet marked
>  as ICV but not encrypt).
> - Ciphertext set to the packet payload.

But we don’t use the data-plane nonce for this. Because it may be used for other LISP data-plane features. We use the control-plane nonce which doesn’t show up on the network very often (only when Map-Requests and returning Map-Replies are sent). So this is better for security.

> (If the algorithm has tag input, the tag is split off from the
> ciphertext).
> 
> If the result is FAIL, drop the packet (it is tampered with) and
> optionally issue a log message.

We do that with the ICV check.

> 3) Strip IV from the packet.
> 
> 4) Forward the packet to destination EID.

I don’t think we are not doing what you say, but you are just using different language. Please confirm.

> The nonce truncation/padding rules are to handle AEAD algorithms
> that don't accept 16 octet nonces but still keep the IV on
> wire at constant 16 octets.
> 
> There is also AEAD_AES_128_GCM, which being AEAD algorithm, is used
> similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with
> it too.

Does that mean we don’t need an ICV if we used AES-GCM? Similar to your chacha20-poloy1305 comment?

Dino