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

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Nov 2015 01:13:56 -0700

> I did a review of crypto usage of lisp-crypto (-02), and found the
> following issues (some I have noticed before, some were new to me):

Thanks for doing that Ilari. See my responses inline.

> - 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. 

> - Instead of "homecooked" encryption, use AEAD modes. AES-GCM is a lot
>  faster than AES-CBC + HMAC-SHA1-96.

I didn’t realize we were home cooking this. We can certainly go with AES-GCM. Do you think we should add a new cipher suite for it or just change the existing ones that refer to AES-CBC to AES-GCM?

> - AEAD_CHACHA20_POLY1305 is not composition of CHACHA20 and POLY1305,
>  it is a single AEAD algorithm (as is AES128-GCM).

Did we imply that? Can you point to the text? I for one, am not expert enough to know the difference so if text implies that, please point that out.

> - How to encode Diffie-Hellman public keys? I presume big-endian
>  integer encoding.

I will make that more clear in the spec. Thanks.

> - Don't truncate Diffie-Hellman secret, just feed the entiere thing
>  to the KDF

I want Brian to comment on this. I have no opinion about the matter.

> - 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.

> - 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.

> - 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.

>  separate keys for ITR and ETR operation, or including the public
>  keys in the context in fixed order (e.g. first ITR, then 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.

If you are okay with padding, I can make that more clear in the spec.

>  preferred generation method that takes long time to cycle (counter,
>  96-bit LFSR, etc...).
> - 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.

> - 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).

The diagram in Section 6:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  / |       Source Port = xxxx      |       Dest Port = 4341        |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  \ |           UDP Length          |        UDP Checksum           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L / |N|L|E|V|I|P|K|K|            Nonce/Map-Version                  | \
I   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
S \ |                 Instance ID/Locator-Status-Bits               |  |
P   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  |
    |                   Initialization Vector (IV)                  |  I
E   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  C
n / |                                                               |  V
c   |                                                               |  |
r   |                Packet Payload with EID Header ...             |  |
y   |                                                               |  |
p \ |                                                               | /
t   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Integrity Check Value (ICV)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Is the same for any cipher suite.

> - 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.

> - I don't see requirement that ITR nonces must be distinct for the
>  same ITR DH key (otherwise encryption keys will be the same if
>  the ETR DH key is the same)?

Well in RFC 6830, we state that nonces are distinct for each Map-Request. So we inherit that information for DH.

> - The CHACHA-POLY reference should presumably point to RFC7539?
> - Maybe use the CFRG-CURVES draft (in RFC-EDITOR queue) for
>  Curve25519/X25519.

I will fix. Thanks for comments and please clarify some of my questions above.

Cheers,
Dino

> 
> 
> -Ilari
> 
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Ilari Liusvaara <[email-masked]>
Date: Sun, 1 Nov 2015 11:53:25 +0200

On Sun, Nov 01, 2015 at 01:13:56AM -0700, Dino Farinacci wrote:
> 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.

> I didn’t realize we were home cooking this. We can certainly go with
>  AES-GCM. Do you think we should add a new cipher suite for it or
> just change the existing ones that refer to AES-CBC to AES-GCM?

I think just change them.

> Did we imply that? Can you point to the text? I for one, am not
> expert enough to know the difference so if text implies that,
> please point that out.

IIRC, the text says something like:

Encryption: Chacha20
Integerity: Poly1305  (i.e. AEAD_CHACHA20_POLY1305)

Which would imply some sort of composition (and the encryption and
decryption procedures also seem to imply it is composition, as
those handle encryption and authentication seperatedly).

> 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).

> 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.

> 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)?

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

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.

> 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.

(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...

> 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.
 
> >  IVs are bad (AEAD algorithms do deal with predictable IVs, but not

I mean, the document seems to say both IVs are randomly generated and
incremented for every packet (which seem to be mutually
contradictionary).
 
> 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.

(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.

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.

(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.

3) Strip IV from the packet.

4) Forward the packet to destination EID.

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.

-Ilari

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 1 Nov 2015 20:42:44 -0800

> 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.

> Section 5 in -02. The listing for "Context" (meaning the fields

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

> endpoints for authentication.

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

> implementations are going to do)?

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

> 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?

> looks to be only 24 bits!) the keys will collide, with bad

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

> is just that such padding needs to be specified.

We will make that change to the spec.

> 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).

> unique IVs and that the keying material is direction-dependent.

Right.

> incremented for every packet (which seem to be mutually

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

> - Plaintext set to the packet payload.

Yes, that is what we do.

> and send to destination RLOC.

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

> - 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.

> optionally issue a log message.

We do that with the ICV check.

> 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.

> similarly to AEAD_CHACHA20_POLY1305. The above algorithms work with

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

Dino

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 2 Nov 2015 12:39:46 +0200

>      Integrity:            HMAC-SHA1-96 [RFC2404]

AES-GCM is AEAD algorithm, so it also covers the integerity.
 
> I think we are saying we are building a context similar to the NIST
> standard but not using it. Brian needs to comment here.

What I'm saying is that you seem to be duplicating steps NIST KDF does
internally.

> unidirectionally from ITR to ETR.

I haven't found the security consideration (that if the same router
is ITR and ETR, it MUST NOT reuse DH keys for both purposes).

And I'd rather not leave such things implicit.

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

No the problem is:
- CBC IVs MUST be random.
- 12-octet-nonce AEAD IVs MUST NOT be random.

The reason for latter is that 96 bit randoms repeat too soon, and
AEAD algorithms usually break in catastrophic ways if the nonce
ever repeats (basically all security lost in this case).

> > - Plaintext set to the packet payload.

If you have IV size be algorithm-dependent, just set the nonce to the
IV (no padding, no truncation).
 
> 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.

No, this nonce is the nonce for crypto algorithm and is per-packet.
The LISP packets transport it in "IV" field.

> your chacha20-poloy1305 comment?

Yes, it means that. AES-GCM internally does the equivalent of the ICV
(called "tag" there).

-Ilari

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 2 Nov 2015 18:18:08 -0800

Understand your comemnts. I’ll create a -03 with changes that reflect your comments and turn it around ASAP so you can make sure I addressed your comments.

Expect it in the next few days but not before today’s working group meets.

Dino

> On Nov 2, 2015, at 2:39 AM, Ilari Liusvaara <[email-masked]> wrote:
>