Ilari, thanks for your comments. I agree with all of them you are providing th expert crypto comments we need in this working group.
Brian Weis and I are working on a draft update that should reflect your comments. We will post it in short-term. Thanks a lot, Dino > On Mar 23, 2015, at 1:05 PM, Ilari Liusvaara <[email protected]> > wrote: > > > >> 4. Encoding and Transmitting Key Material >> >> The Diffie-Hellman key material is transmitted in Map-Request and >> Map-Reply messages. Diffie-Hellman parameters are encoded in the >> LISP Security Type LCAF [LCAF]. >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI = 16387 | Rsvd1 | Flags | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Type = 11 | Rsvd2 | 6 + n | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Key Count | Rsvd3 | Key Algorithm | Rsvd4 |R| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Key Length | Key Material ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | ... Key Material | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | AFI = x | Locator Address ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Diffie-Hellman parameters encoded in Key Material field >> >> The 'Key Count' field encodes the number of {'Key-Length', 'Key- >> Material'} fields included in the encoded LCAF. A maximum number of >> keys that can be encoded are 3 keys, each identified by key-id 1, >> followed by key-id 2, an finally key-id 3. >> >> The 'R' bit is not used for this use-case of the Security Type LCAF >> but is reserved for [LISP-DDT] security. >> >> The 'Key Algorithm' encodes the cryptographic algorithm used. The >> following values are defined: >> >> >> >> >> >> Farinacci Expires July 16, 2015 [Page 4] >> >> Internet-Draft LISP Data-Plane Confidentiality January 2015 >> >> >> Null: 0 >> Group-ID: 1 >> AES: 2 >> 3DES: 3 >> SHA-256: 4 > > These don't look to be of the same type? And 3DES in 2015? If you want > serious backup for AES, there is Chacha20. > > Also, one can't encrypt data with AES, one also needs mode for it. > > Basically, for encryption strapped on top of DH, you need: > > - (EC)DH group (or monoid) > - Hash function to use for key derivation. > - AEAD cipher. > >> When the 'Key Algorithm' value is 1 (Group-ID), the 'Key Material' >> field is encoded as: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Group ID | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Public Key ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Points to Key Material values from IANA Registry >> >> The Group-ID values are defined in [RFC2409] and [RFC3526] which >> describe the Diffie Hellman parameters used for key exchange. > > All the groups from RFC 2409 and the lowest from RFC 3526 look too > weak for modern use. > > This might also be a good place to stick ECDH groups. Those would do > really nice things to the MTU: > > - CFRG basic ECDH: 32 bytes/key > - CFRG high-security ECDH: 56 bytes/key > - ECDH "stratospheric" level: 66 bytes/key > - DH basic: 256 bytes/key. > > And that "high-security ECDH" is considered stronger than even > IKE group 18 (1024 bytes/key!). And "stratospheric" is so big that > finding bigger curves is pretty difficult. > > > Also, if this one is selected, what will be the symmetric cipher? > >> When the 'Key Algorithm' value is not 1 (Group-ID), the 'Key >> Material' field is encoded as: >> >> 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 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | g-length | g-value ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | p-length | p-value ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Public Key ... | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Key Length describes the length of the Key Material field > > What is the difference of AES vs. 3DES vs SHA256 here? > > >> 7. Future Work > > <this seems to be about crypto improvements> > > What I think should be done about crypto: > - Actually specify how algorithm negotiation is supposed to work (I > can't make heads or tails about that) > - Always use authenticated encryption (algorithms like AES-GCM and > Chacha20-Poly1305), and also authenticate at least some of the LISP > headers (those that aren't supposed to change)[1]. > - Swap out 3DES for something more serious. > - Support ECDH, including modern Montgomery-curve ECDH (for stronger > key exchange & smaller keys). > - Hash the map-request/map-reply packets into the encryption key > computation[2], along with the DH result. > > > > [1] IPSec ESP can be broken if no authentication is used. > > [2] TLS didn't use to do this. Caused security issues. > > > -Ilari > > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
